111–120 of 120 posts
Earlier quoted context omitted.
Doesn't using C++ RAII eliminate some of that? Or you use raw pointers often?
Anything in C++ generally comes with its very own footgun. The one for RAII looks like this: { mutex_guard(some_mutex); foo(); } What does this do? It locks some_mutex, then immediately unlocks it, then calls foo().
New languages always are trap. Programmers always waste too much time on new languages or some tricky language syntax. They should focus on the business. I will never try Rust.
Well, we first spent six months on 'cannot call function undefined of undefined'. We could have spent the last three on 'segfault' instead. Rust let us spend that time on actually experimenting instead of just fighting the computer all the time.
Earlier quoted context omitted.
Anything in C++ generally comes with its very own footgun. The one for RAII looks like this: { mutex_guard(some_mutex); foo(); } What does this do? It locks some_mutex, then immediately unlocks it, then calls foo().
I don't understand the example. Why would it do that and not unlock after foo()?
{
mutex_guard guard(some_mutex);
foo();
}Earlier quoted context omitted.
That will result in very poorly-performing code. I liked DannyBee's quote (paraphrased): "Most applications have flat profiles. They have flat profiles because people have spent a lot of time optimizing them."
There are times squeezing every last bit of performance is great. I am saying is in general there is no need to run -O3 on a 500 line function which is run once at initialization compared to a compute kernel. Our compilers and languages don't have the granularity to specify this currently. I do want more specialized optimization tools however. Things like automatic super optimizers [1] which can be targeted by progra…
Earlier quoted context omitted.
There are times squeezing every last bit of performance is great. I am saying is in general there is no need to run -O3 on a 500 line function which is run once at initialization compared to a compute kernel. Our compilers and languages don't have the granularity to specify this currently. I do want more specialized optimization tools however. Things like automatic super optimizers [1] which can be targeted by progra…
According to a quick google search, both gcc, clang and msvc allow turning off/on optimizations at a function level, via #pragma/attributes?
Earlier quoted context omitted.
I don't understand the example. Why would it do that and not unlock after foo()?
The following code would do the right thing; see if you can spot the difference, and think about whether you would catch that in code review (g++/clang++/visualc++ won't warn about it). { mutex_guard guard(some_mutex); foo(); }
Anyway, the first example creates a temporary object which doesn't lock anything since it will be destroyed right away because it's an rvalue (not sure why would anyone do that for locking, unless not knowingly). The second example creates a proper guard which lives until the end of the scope.
Earlier quoted context omitted.
I don't understand the example. Why would it do that and not unlock after foo()?
The following code would do the right thing; see if you can spot the difference, and think about whether you would catch that in code review (g++/clang++/visualc++ won't warn about it). { mutex_guard guard(some_mutex); foo(); }
The answer to the code review question is obvious. I didn't see the error even though I was told what happens.
Earlier quoted context omitted.
C++ is still mostly what I use, but I need neither speed nor bare metal. Maybe add C) people doing UI and applications? There aren't many other good options: Java: UI looks terrible; it's annoying living in Noun-land when CPUs are, if anything, more about verbs than nouns; and running properly on Windows is not trivial. C#: Up until recently, not cross-platform unless you're ok with Mono. (But, might be worth looking…
Most GUI toolkits for Rust are in their infancy, but I hear that Gnome will be working on integrating Rust with GObject this year, which should allow Rust to leverage Gtk: https://wiki.gnome.org/GUADEC/2015/BOFs/Rust Some preliminary work towards this: https://github.com/gi-rust/glib-sys
This disappoints me greatly.
The idea of an object hierarchical GUI is not a guaranteed given. It causes things like "primary UI thread" which doesn't need to exist anymore. It is a reflection of a time when memory and CPU was more scarce.
In the face of massively parallel CPU's and huge memory, a tile-based, constraint GUI with publish-subscribe is probably a much better choice. This is especially true with a language that promotes concurrent programming.
I suspect, sadly, that we're simply going to continue down the same broken, single-threaded UI path because of the installed codebases.
Earlier quoted context omitted.
Well, we first spent six months on 'cannot call function undefined of undefined'. We could have spent the last three on 'segfault' instead. Rust let us spend that time on actually experimenting instead of just fighting the computer all the time.
Spending 3 months on a segfault? In any language even a mediocre programmer you can usually resolve a null reference exception / segfault in a couple of hours at the most. With a complex program and a debugger it could be a minute or so. Maybe if it only happens in production and you don't capture stack traces or core dump files... but this happens once and then you learn your lesson.