Talk:C++

Removed Criticism

Mthinkcpp has removed almost all criticism. Since he has contributed much good things I don't think he made this in bad faith. But also C++ seems for HIM to be the best programming language as it is. There can be valid criticism. So I would like to redo his changes. --Fabiwanne (talk)

The lack of a proper criticism section and the general fanboyism of this article is extremely unfortunate. The reader is left with the impression that C++ can't "take the heat". It'd be much better to list the problems of C++ and let the readers decide. Mkcmkc (talk) 00:35, 10 August 2013 (UTC)

The criticism section in any article and specially in this one is indispensable. All programming languages are subject to criticism in real life. I think the reader at least should know that there are many things/facts such as the list mentioned here: http://yosefk.com/c++fqa/defective.html in which C++ has been challenged/criticised. And those are some of the reasons why there are a plethora of other languages out there (Java, C#, D, Go, etc) which were born trying to address some/all of that concerns, and the reason why the C++ standard is still evolving. Alcides fp (talk) 02:44, 16 September 2013 (UTC)

Criticism sections are not indispensable, it's actually quite the opposite and discouraged by WP policy. WP:CSECTION. Also that link (yosefk) is opinions an original research and has no place here. Criticism should be used throughout or not at all. Splitting the point of view into a section is generally a bad idea. Beakermeep (talk) —Preceding undated comment added 02:14, 20 October 2013 (UTC)

I never said the list here was authoritative I only mentioned it as an example of some topics that could/should be included in a serious Criticism section in *this* article. By the way, articles on languages such as Pascal, Java and even Haskell all of them have a Criticism section, in fact Java has a whole article on it. So I can't see the reason why this article shouldn't have one.AlcidesFP (talk) 19:11, 1 April 2014 (UTC)

While a criticism of C++ has been re-added, it really seems self-serving. Flexibility in mixing paradigms is NOT why C++ is generally criticized (other languages which do so, such as Python, are celebrated for it). Inconsistency (i.e. the static keyword) due to organic growth from C, difficulty in parsing the grammar (and therefore creating compilers/tools), flaws in the standard library (i.e. std::string intended but not suitable for COW), verbosity of high-level patterns (implementing an container can be quite a feat), are all examples of legitimate criticisms. I'd think the section should be made more robust or removed - right now it's a mockery of the word "criticism." — Preceding unsigned comment added by 68.33.220.238 (talk) 14:09, 20 October 2013 (UTC)

Mixing paradigms was an attribute in C++ which was explicitly chosen. So many people love it for that. But this has bad sides too. In fact it's one of the things that you recognize at first when you learn C++. Since there are many paradigms you have to learn all and find out the right ones if you want to understand C++-Code. So there are other languages (like Java) which explicitly prevent you from using "the wrong" paradigms. In fact the most programming languages do this. Other languages which explicitly allow many paradigms are criticized for this too. (See perl.) --Fabiwanne (talk) 11:23, 18 January 2014 (UTC)

There are a lot of criticisms you can make about C++, and a lot you can make about any language. If you're going to make a list of criticisms about C++, then you should about every programming language; and while maybe feasible, would not be useful if only because a normal reader of wikipedia article could not be expected to judge the relevance of the criticisms. For example, I'm a C++ programmer and the "std::string intended but not suitable for COW" criticism is perhaps true, but doesn't affect the software I write in any meaningful way. Furthermore, the article as it was said that C++ was "compared unfavorably" for reasons that I would consider one of C++'s best qualities njaard (talk) 18:05, 22 October 2013 (UTC)

Side note: the link has appeared before in a previous criticisms discussion Talk:C++/Archive_10#Criticism - and been marked as no use/biased/inaccurate Talk:C++/Archive_10#Do_we_need_this_retarded_criticism_page.3F, several times. mthinkcpp (talk) 13:13, 2 November 2013 (UTC)

Still no mentioning of C++ Exception Handling -- embarrassing

After nearly 20 years (18 to be correct) of working implementations of C++ Exception Handling this "encyclopedia" does not mention anything regarding it. Embarrassing. If you look in the history of the page, you'll find the paragraph I added some time ago (http://en.wikipedia.org/w/index.php?title=C%2B%2B&oldid=521857592), which was removed, as I did not provide any references (I'm not aware of any). — Preceding unsigned comment added by 192.73.228.23 (talk) 18:50, 5 February 2014 (UTC)

Exception handling is a feature present in many languages at this point. With that in mind, is there any particular reason why the page on C++ needs a section about it? Novusuna ^talk 19:27, 5 February 2014 (UTC)

The same reason why other major features of C++ are being mentioned in this article. — Preceding unsigned comment added by 192.73.228.23 (talk) 20:30, 5 February 2014 (UTC)

I agree with 192.xxx. C++ exceptions are significant enough to warrant a section under "Language", if not an article on its own. decltype (talk) 09:40, 7 February 2014 (UTC)

Finally somebody started. And maybe it does not get deleted by some exception phobic person. I added a one clarification (regarding handler -- which many people (including me) confuse with something being called from the place of error (like signal handler) -- but exception handling is about stack/scope unrolling). Feel free to change this to express it better. I think what also needs to be here:

• only using C++ Exception Handling one can abort a constructor. Thus fallible resource allocations can now be put into a constructor AND any following code (another constructor) can rely on that the previous one was successful. Potentially compare to two-step-construction which was used before C++ Exception Handling.
• if-less programming -- code is written for the everything-until-now-worked case
• real word scenarios -- don't deal with programming mistakes like range overflow but system errors returned by system calls
• example scenario of an object, which needs 10 different types of resources to be allocated in the constructor(s). Reporting any failed allocation to the caller. Deallocation in the constructors. With and without C++ Exception Handling.
• compare to eating up/ignoring error codes. Example could be some C code using printf() and not reporting the error from printf() to the caller of the code resulting in developers having to use a debugger to find out what is failing and where. — Preceding unsigned comment added by ExcessPhase (talk • contribs) 02:37, 10 February 2014 (UTC)

The demonstration of exception handling to catch programming bugs like index-out-of-bounds error, is not helping people to appreciate exception handling. At least one could mention, that the constructor of the vector could also throw AND that the code after the constructor will only be executed, if the constructor was successful. The if-less programming style enabled by exception handling needs to be demonstrated. Better would be to show a series of system calls, which depend on each other, with every one potentially failing. Including RAII:

• open file
• mmap (only done if preceding open was successful)
• close file (only done if preceding open was successful)
• count number of newlines (only done if preceding mmap was successful)
• munmap (only done if preceding mmap was successful)

(lifetime of open-close object shortened by using an boost::optional) — Preceding unsigned comment added by 192.73.228.23 (talk) 23:21, 9 May 2014 (UTC)

compatibility to C

There is no need to have a paragraph regarding compatibility with other languages (including C) here. C++ is meanwhile a separate language. That it once was a superset of the then existing C is only of historical importance.ExcessPhase (talk) 22:07, 25 May 2014 (UTC)

Bjarne Stroustrup considers it worth mentioning, he devotes a chapter to it in The C++ Programming Language (advanced) and Programming Principles and Practice (Beginners). I have removed the C++11 list though, and transferred it to the C++11 page (as it is better suited there). mthinkcpp (talk) 13:34, 26 May 2014 (UTC)

"Unknown errors can be caught"...

Wrong. Errors cannot be caught. Unknown types of exceptions can be caught... — Preceding unsigned comment added by ExcessPhase (talk • contribs) 22:15, 25 May 2014 (UTC)

Fixed. mthinkcpp (talk) 13:22, 26 May 2014 (UTC)

Turing complete

Why does it say "turing complete" in the description of templates. A template cannot run any expression a computer can compute at compile time. Who the hell has got turing complete in their head that side and keeps typing "turing complete" on anything to do with software. So what, who cares? move it to a philosophy page about the topic instead. It is nonsensical garbage. — Preceding unsigned comment added by 41.8.216.58 (talk) 18:55, 3 July 2014 (UTC)