5 ms·

I completely agree. While C++ certainly isn't perfect, those of us that write real code that is used and maintained day to day can be very productive. While I

• jacquesm 17y ago
  If you code in a 'safe' way and you stay away from nifty tricks then you are in good shape. I'm sure you have a little list of stuff that you should stay away from or that you would at least discourage. The problems usually come when people start to use all those nifty features in combinations, especially 'newbie' programmers going wild on all that high level sugar. C/C++ is performance wise also as good as unbeatable, if you know what you're doing, which is another reason why it has such staying power.
  • rpledge 17y ago
    I have a list of things to stay away from indeed, but it's due to my own sanity of being. For example, without GC exceptions are almost always going to cause leaks without the team being all C++ experts. If I was designing in Java exceptions are wonderful, in C++, asking for issues
    • jacquesm 17y ago
      > but it's due to my own sanity of being. I think that is what such lists have in common :) > For example, without GC exceptions are almost always going to cause leaks without the team being all C++ experts. That is something I rarely have had trouble with, but I never worked much in teams. I did notice that the double-free and never-freed pointers are a good portion of the problems you encounter in live code though. And every time firefox goes EWOL I'm fairly sure that somewhere deep down someones code just tried to reference a stale pointer or something like that. Even in Java exceptions are not all that wonderful, I think they are just a way to say "I don't feel like coding the stuff required to handle this situation properly, let's thrown an exception". You end up with more exception handling code sometimes than functional code and that isn't the right balance either.
      • rpledge 17y ago
        Throwing an exception isn't saying "I don't feel like dealing with this", but rather, "A problem has occurred". In C++ (ignoring exceptions), you typically (or hopefully!) return an error code and rely on the caller to handle the issue. In Java, with checked exceptions, a catch or declaration that the current method can throw the same exception is needed for compilation. Now, this doesn't stop empty catch blocks or other horrible coding practices, but professional software engineers should never let that happen in their code (and there are lots of people who do, and they shouldn't be getting paid to write code!) Checked exceptions wouldn't fix the memory leak issues in C++, I routinely use the shared_ptr template to fix that, but it would be a good step forward.
        • jacquesm 17y ago
          Aye, I hear you. But the problem is not that people use stuff the way it is intended, but they will use it in ways that it is not intended! > Now, this doesn't stop empty catch blocks or other horrible coding practices, Exactly... > professional software engineers should never let that happen in their code I could show you some horror stuff I'm dealing with right now that does exactly that. The bigger problem is that it works and that I'm having a hard time convincing other people that that is not how it is done.
    • dkarl 17y ago
      exceptions are almost always going to cause leaks without the team being all C++ experts Don't give up exceptions; give up naked pointers. Use shared_ptr and scoped_ptr, and you won't have memory leaks due to exceptions. Use RAII consistently, and you'll find it's actually easier to handle resource management in C++ than in Java. Java's resource management is superior for memory but inferior for every other resource.
  • coliveira 17y ago
    But think about open source code. Anyone can contribute code, so if you're using C++ you will get code from people from all levels of understanding of C++. This is a reason why some open source people prefer to use C, because they won't spend time saying what can or cannot be used in the project. An example is Google. They had to create a huge document to describe what part of the language their developers can use: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml http://google-styleguide.googlecode.com/svn/trunk/cppguide.x...
    • jacquesm 17y ago
      Most of that is 'plain good sense' in any environment, here are a couple that target specific C++ pitfalls: - Only very rarely is multiple implementation inheritance actually useful. We allow multiple inheritance only when at most one of the base classes has an implementation; all other base classes must be pure interface classes tagged with the Interface suffix. - Do not overload operators except in rare, special circumstances. - Make all data members private, and provide access to them through accessor functions as needed. Typically a variable would be called foo_ and the accessor function foo(). You may also want a mutator function set_foo(). - All parameters passed by reference must be labeled const. - Do not use function overloading to simulate default function parameters. - We do not allow variable-length arrays or alloca(). - Be very cautious with macros. Prefer inline functions, enums, and const variables to macros. The only thing that struck me when reading this that I do different is the use of ++p, I would avoid that at all costs. Pre-increment is a great way to confuse people. I can see why they would use it though, another similar source of confusion (stemming from C really) is the difference between *p++ and (*p)++;
      • coliveira 17y ago
        When working with objects you should always do ++p instead of p++. The later one creates a temporary, so you have to work extra hard for nothing.
        • jacquesm 17y ago
          That's an interesting one, I never even thought of that! Thanks.