7 Commits

Author	SHA1	Message	Date
Allan Odgaard	c2397484b8	Use C++11 for loop ... Majority of the edits done using the following ruby script: def update_loops(src) dst, cnt = '', 0 block_indent, variable = nil, nil src.each_line do |line| if block_indent if line =~ /^#{block_indent}([{}\t])|^\t*$/ block_indent = nil if $1 == '}' line = line.gsub(%r{ ([^a-z>]) \(\*#{variable}\) | \*#{variable}\b | \b#{variable}(->) }x) do $1.to_s + variable + ($2 == "->" ? "." : "") end else block_indent = nil end elsif line =~ /^(\t*)c?iterate\((\w+), (?!diacritics::make_range)(.*\))$/ block_indent, variable = $1, $2 line = "#$1for(auto const& #$2 : #$3\n" cnt += 1 end dst << line end return dst, cnt end paths.each do |path| src = IO.read(path) cnt = 1 while cnt != 0 src, cnt = update_loops(src) STDERR << "#{path}: #{cnt}\n" end File.open(path, "w") { |io| io << src } end	2014-03-03 10:34:13 +07:00
Allan Odgaard	1c308c810d	Use map::emplace instead of inserting std::pair (C++11)	2013-09-05 20:59:11 +02:00
Allan Odgaard	12067e806a	Don’t keep mutex locked when calling client code ... The mutex was locked to ensure that the client object did not go away, but the client’s code may terminate the program which destroys the server_t instance and thereby the mutex itself, which would previously cause an assertion to trigger, since the mutex was locked during destruction. In practice there is no issue with the mutex not being locked while accessing the client object, as “unregister_client” and “master_run” are both called from the main thread, except for tests, but here we do not unregister client objects before their requests have been handled.	2013-08-12 19:32:23 +02:00
Allan Odgaard	2ad42430c4	Make client API for oak::server_t thread safe	2013-08-05 11:17:04 +02:00
Allan Odgaard	b2acb02a7f	Use std::function with cf::callback_t	2012-09-09 16:22:19 +02:00
Jacob Bandes-Storch	c5520a6919	Use libc++: replace typeof with decltype	2012-08-28 13:30:21 +02:00
Allan Odgaard	9894969e67	Initial commit	2012-08-09 16:25:56 +02:00