4 ms·
The conclusion I get from the article, the comments, and the other threads, is this: C++ is not a better C. This was a really common attitude about a decade a
by bcoates 13y ago
The conclusion I get from the article, the comments, and the other threads, is this:
C++ is not a better C.
This was a really common attitude about a decade ago: don't use C for anything, just point cpp at your C code and use whatever random collection of C++ features you think make your life easier. We've learned since then that that's a recipe for disaster, and you should either write a C program in C (and save yourself the heartache) or embrace the fact that C++ is an entirely different language.
The author is clearly committed to writing a C program and doing that in any language other than C is a mistake.
- rdtsc 13y agoThat certainly been Microsoft's approach to its dev suite. They refused to support C99 and just tell people to use C++ instead. Had to use it for a project and had to sift through code and roll back valid C99 code to make it compatible with their braindead compiler. C++ has its place and its strong point but it is not a strict superset of C in terms of features and improvement.
- aa0 13y agoMicrosoft pretty much let their c compiler rot. It doesn't support dynamic allocation, ie, int arr[numElts];, it doesn't even support var declaration anywhere but at the beginning of a function. Making code I've been writing compatible with msvc has been a pure headache.
- pjmlp 13y agoIt is a C++ compiler, just use C++ and you will be fine.
- rdtsc 13y agoNo. I am using C and specifically some C99 features. They claim C++ is just C and ++ but it isn't. (There is an Intel compiler that does support C99 btw if anyone is interested but you have to pay for it). http://software.intel.com/en-us/articles/c99-support-in-intel-c-compiler http://software.intel.com/en-us/articles/c99-support-in-inte...
- pjmlp 13y ago> They claim C++ is just C and ++ but it isn't. Who says this? Citing Andrew Koenig 's 1989 statement: "As Close as Possible to C, but no Closer". Thankfully I would add, as C++ has more strong typing than C. As for doing pure C99 development on Windows, there are other options as you point out. Personally as a software developer I don't have issues to pay for the work of others.
- rdtsc 13y agoMicrosoft's mentioned that in their forums in replies to people complaining about lack of C99 -- "just use C++". > Thankfully I would add, as C++ has more strong typing than C. Doesn't matter. My project was large, already written in C99, was not in C++. I do not like C++, I don't care for learning virtual destructors mixed with mutliple inheritance, templates stl and friend methods. I am not the only one on the project. So just "don't use it" is easy to say for one person project, when multiple people work on it everyone start to use their favorite subset from C++ huge specification and I don't like that. > As for doing pure C99 development on Windows, there are other options as you point out. It was annoying but we just rolled back C99 specific features.
- pjmlp 13y ago> Microsoft's mentioned that in their forums in replies to people complaining about lack of C99 -- "just use C++". Yes, this is true. For Microsoft C is a legacy language that can well be replaced by C++ for what they care. But I think I never saw them stating "... C++ is just C and ++ ...", even of the official communication done by Herb Sutter. I am on the opposite field, I only touch C if really obliged to do so, which does not happen since 2001. So I am a bit biased regarding Microsoft's decision, but I do understand some developers would rather stay on C land.
- chacham15 13y agoI mostly agree, but there are some exceptions. The principal one is function overloading. This makes code soooo much more readable and easy to use. So, basically, I compile my C code with g++ just for function overloading (which technically makes it not C code, but w/e).
- Someone 13y agoIn C11, Type-generic expressions give you something that looks just like overloading (http://www.robertgamble.net/2012/01/c11-generic-selections.html http://www.robertgamble.net/2012/01/c11-generic-selections.h...) The declarations do not look nice (I don't think that is a matter of taste in this case, compared to overloading in C++), but for the principled who want to use C or for those who have to use C, there is a solution.
- CamperBob2 13y agojust point cpp at your C code and use whatever random collection of C++ features you think make your life easier. We've learned since then that that's a recipe for disaster How so?
- gilgoomesh 13y agoUnfortunately, you can't draw any conclusions about C++ from the article. a. The article isn't really about C++ in any general sense. b. The author fails to learn the solutions that are commonly used in C++ to solve his problems so auhtor fails to teach the reader anything The article is about a couple specific design pitfalls that occur when using C++ exceptions and how the author never solved them. The only conclusion is avoid the design anti-patterns the author used. So what anti-patterns did he use? The author used exceptions (an optional language feature best used for abort handling of RAII operations) to handle return codes from paths inside a function (which is usually handled with error codes, not exceptions). Not a real problem except that the author failed to carry sufficient context through to the catch location and therefore couldn't clean up (although clean up should have been handled by RAII destructors, catch should only ever need to clean up "this", which should know its own state). Author also failed to catch with sufficient locality and hence made his code confusing. Instead of realising that exceptions weren't well suited to error code handling and he wasn't throwing enough context information and he should have been using RAII anyway, the author wrote off exceptions for all tasks – including constructors (which is a poor choice since it eliminates all possibility of RAII from the program). This can still work but then the author couldn't work out how to write a factory method that potentially returns an error code instead of an object and instead juggled the ugly state problem of extant but invalid objects. Author could simply have returned a boost::optional<my_class_which_can_fail_construction> from a factory method instead of requiring all that nasty state stuff inside his class. Instead of learning from many mistakes, author blames entire language.