41–50 of 55 posts
Out of intellectual curiosity, what resources (books, sites, etc.) would be recommended for modern, best practices C++?
Yea, let's write all of our higher level object juggling in C++! Such a nice language, isn't it? And there aren't much alternatives either, right? Let's be honest: if you find yourself complaining about C++ syntax and error messages while coding your higher level logic, chances are you either like the pain or you have lived under a rock for the last 15 years. In the latter case, go open your browser and type "Python"…
Yea, let's write all of our higher level object juggling in C++! Such a nice language, isn't it? And there aren't much alternatives either, right? Let's be honest: if you find yourself complaining about C++ syntax and error messages while coding your higher level logic, chances are you either like the pain or you have lived under a rock for the last 15 years. In the latter case, go open your browser and type "Python"…
Yeah, because you can write hard real time code in Python or JavaScript.
Earlier quoted context omitted.
Yeah, because you can write hard real time code in Python or JavaScript.
Better stated, there are applications where you can't use JavaScript or Python due to timing requirements - software defined radios for instance.
Earlier quoted context omitted.
Most people just miss the common C++ idioms that solve many of the exception issues in very elegant ways (and give a lot of benefits at the same time). E.g. the example with file open + close in the presentation is laughable. Every C++ programmer knows that this is something that should be done with RAII. I.e. instead of manual close calls you let the destructor handle it. This is both exception-safe and spares you r…
"I.e. instead of manual close calls you let the destructor handle it. This is both exception-safe and spares you remembering to add a close call on every possible exit-path." Unless closing the handle causes an exception to be thrown. Either you never see the exception or your program aborts, and neither one is particularly good if you want to write reliable code.
That is a straw-man argument. If the underlying file-closing API can throw exceptions, they must be caught from the destructor. If that means that they get ignored, then that is what it will have to be (much the same as most C programs ignore the return call from `printf`). Also in this case, the RAII wrapper should provide a member function which can execute the underlying close call early and expose the failure, for users who may be interested in guaranteed reliability.
In any case, provide RAII _safety_ does not intrinsically reduce reliability. If your destructor is executing code which _must_ succeed or be handled at a higher level, then a good developer will not put it in the destructor. No language feature can solve the question of "where should the program stop caring about failure?"
Hmm, I found some of the criticism unfair. E.g. the example with "baz = foo->bar(3);". Yes, "bar" could be a number of things here, but that's why variable naming conventions help. The point about operator overloading is accepted, but this is not too different from what happens with metaprogramming in Ruby or say macros in lisp. Even python has some quirks. See: http://stackoverflow.com/questions/1132941/least-astoni…
> Hmm, I found some of the criticism unfair. E.g. the example with "baz = foo->bar(3);". Yes, "bar" could be a number of things here, but that's why variable naming conventions help. Then why must variables have static types?
Hmm, I found some of the criticism unfair. E.g. the example with "baz = foo->bar(3);". Yes, "bar" could be a number of things here, but that's why variable naming conventions help. The point about operator overloading is accepted, but this is not too different from what happens with metaprogramming in Ruby or say macros in lisp. Even python has some quirks. See: http://stackoverflow.com/questions/1132941/least-astoni…
> Hmm, I found some of the criticism unfair. E.g. the example with "baz = foo->bar(3);". Yes, "bar" could be a number of things here, but that's why variable naming conventions help. Then why must variables have static types?
Naming conventions (in c++) exist for the programmer to aid the programmer in recovering the semantics of a given expression (which the compiler already understands).
Blergh. This stuff is why I use Python (with snippets of C for speed): when I do something stupid, I get an error message and line numbers, not a faceless segfault (+even when I get a C segfault, I can still get the python stack back with faulthandler..)
Ugh. These C++ bashing articles, although being highly popular, are extremely grating. All languages have issues. The End.