The problem very often is that when you use qsort you call a precompiled library, only one copy of it exists, but when you use std::sort you may end up with many copies of the sort algorithm in memory. Not only is this a a lot of extra memory it also hurts run time because more memory means less locality of reference for caches and more likelihood of having to swap.

How should I address such a huge amount of bullshit? Let me start:

First, qsort only works on array types whereas std::sort works on anything that resembles a random input/output iterator;

Second, in the best case scenario, qsort has to resolve a function pointer and call a function for every comparison whereas std::sort needs neither, which is a monstrous performance loss for qsort;

Third, in the worst case scenario, qsort still has to resolve a function for every comparison whereas qsort doesn't, which is a huge performance loss for qsort;

Fourth, for all cases covered by qsort where the comparison is simply a return b > a;, only a single instance of std::sort is needed since only pointers are involved;

Fifth, if multiple instances of the template bother you more than the performance loss that you'd have with qsort, then providing std::sort with function pointers (as opposed to actual functions or functors) will ensure that only only one instance of the template is generated.

So, as you can see, std::sort is as bad as qsort in the worst case scenario (if you try really hard) and beats qsort to the ground in every other scenario.

In this case C++ hides too much of the details; if you want to write efficient code then you do not want details to be hidden. When you just want a rapid prototype then you don't need to worry about details. C++ can work well with both styles, however when you want efficiency you usually have to give up the ease of programming that high level generics and generic algorithms gives you.

Complete nonsense! Efficiency can be determined by the complexity of the underlying algorithm, which is usually known. For example, you know for a fact that accessing an std::map is O(log n) and that accessing an std::unordered_map is as close as possible to O(1). For further explanations as to why this paragraph is utter nonsense and you should feel incompetent at this point, read what I said about qsort vs std::sort above.

You CAN have type safe code with qsort. Either put a function wrapper around all uses of qsort that verifies all parameters are of the right type, or automatic this with a template wrapper around it. Then the sort routine itself remains efficient and precompiled in a library while still giving you the type safety that you want. It's only slightly more work than just using std::sort.

Your ignorance drives you to ridiculousness.

And using qsort as a "classic example" seems fishy. This is not a common source of errors and of all the places where type checking can mess up in C this is probably the least of the worries.

What qsort is an example of is a case where C code is A LOT SLOWER than C++ code, and there is no real workaround for this that doesn't involve losing even more functionality (you'd have to implement a non-generic solution in order to match the performance of the C++ generic implementation). Writing wrappers doesn't really solve anything, it only adds bloat to your code, which should be a concern to you were so worried about std::sort's multiple instances, and you aren't allowed to talk about templates because those don't exist in C.

TLDR: If you are a software engineer, you are an incompetent buffoon.

You are an idiot and have absolutely no clue about the subject you're attempting to debate.

No, I hope they don't discover STL containers. That will bloat up the size of the compiler because those containers are templated generics, and the compiler/linker today essentially compile those as duplicated code. STL code is also too generic and optimized for a generic case; they're not optimized for specific cases (especially the algorithms).

Make up your mind! Either you're against specialized ("duplicated") code or you are against generic (unoptimized) code! You can't be against both at the same time! Also, code-size stopped being a concern a long time ago. Code is usually very small and shared compared to data these days, it no longer makes sense to sacrifice performance for code size on modern systems, and this includes even some embedded systems!

Now I do like a good container library, but C++ as a static language isn't set up to use this idea well. Smalltalk does wonders with it because it can reuse a class without making a complete duplicate of the class. Generics are great for rapid prototyping if you don't care how much big or slow it is, but once the prototype is done then you should logically want to use something more efficient.

And that's what C++ does for you. You prototype in the template and the compiler outputs efficient and specialized code! That little speed remark was also quite amusing, you're claiming that a radically dynamic language where no generic code really is optimized for anything is faster than a static language that optimizes everything at compile-time...

The biggest problem here I think stems from the C++ style of using objects directly instead of type-checked pointers to objects (value-based instead of pointer-based). Ie, a linked list of objects using STL style generics will have difficulty sharing code between the two instantiations (bloat) and will also have to deal with copy constructors getting objects into and out of the container (bloat and speed). But you can have a template that enforces type correctness of pointers to objects that then uses a container of void* for example, code gets shared, objects don't get copied, and it's very efficient. Yes you're back to having to worrying about who owns objects but really that's a problem that can be solved without resorting to STL style.

Templates of two distinct pointer types usually evaluate to exactly the same code since the pointers are usually represented the same way (though this is not a requirement), and nothing stops you from storing pointers rather than the actual elements in your containers. If you have ownership issues, use smart pointers instead, that's what they exist for, and unlike C, void * and char * are not universal pointers in C++, so never use those (void * is particularly useless in C++).

There is very little a dynamic language can offer better than C++ in terms of features and absolutely nothing a dynamic language can offer better than C++ in terms of performance or reliability.

Actually I think anonymous namespaces don't help much because the semantics means those names are out there at link time, slowing down an already slow link. Static functions remain hidden from the linker even though the C++ purists won't like it.

There is absolutely no reason for anonymous namespaces to be implemented any differently from static functions and objects. The reason why some people discouraged the use of static objects and functions in C++ to make stuff only visible to its own translation unit is because C++03 deprecated them, but C++11 has un-deprecated it again. Still, the choice between static or anonymous namespaces should have no impact on the final code (personally I choose static for esthetic reasons).

The lack of designated initializers makes C++ a hand-down loser to me. You want a sparse 4 kB array that will be shared between multiple program instances (i.e. in .rodata)? Decide between writing a code generator for it or typing a few thousand zeros.

Standard C++ doesn't know what 'rodata' is, neither does standard C (by the way). Now that we've addressed this issue, could you please name the "winner" language in that scenario? Don't even try to mention an assembler, because that's a "code generator" and you've already ruled those out...

It's true: C++ exceptions are broken. Don't use them.

How are they broken?

I've gone the opposite direction. Moving more of my C++ code into C by using my own OOP system. Before you say "That's crazy talk", consider that it makes inter-operating with my game's scripting language so much more buttery smooth than in C++ -- It's so nice to just create a new object in either script or C and have them talk to each other without going through a few layers of APIs, passing off dynamically allocated instances and having C free it, or the script GC it automatically.

Ever heard of Objective-C? If you're going to use something stupid, at least use something that anyone else can pick up...

Don't get me wrong, I love C++, but they have rules that are conflicting when you get "deep" into the language. Try using multiple inheritance and polymorphism... It almost works, but not if you have two base classes with the same virtual function names -- That's just one of many edge cases I ran into... Theres several corners we're forbidden to go where templates, type safety, and inheritance don't play well with each other...

You know there's virtual inheritance to solve that diamond-problem, right? It's not rocket science!

After a while I just scratched my head, "Really C++? Really?!" Why would you have features that are incompatible? So long as I only use some of C++'s features some of the time, then everything is fine, but when I needed to use MOST of the language in the implementation of my scripting language, then shit hit the fan. Many experience people I look up to have told me if I need to use the WHOLE C++ language then I'm doing it wrong. To them I say: If you can't use the entire language at once then the Language is "doing it wrong".

Versatility isn't wrong.

C++ is great if you're only using C++, and C++ constructs. That you have to use extern "C" { ... } to make shared libs that will actually work with other compilers or languages is a serious show-stopper for me. Protip: method names are munged into unique C function names so you can actually compile "C++", ergo they need to standardize name munging rules but to do that would be to admit that C++ is mostly implemented as a fancy pre-processor for C...

Bullshit, name mangling is not part of the standard, the only reason why you see it is because YOUR implementation implements C++'s function signatures that way. Unlike C, functions in C++ are resolved not only by their names but also by the types of their arguments, meaning you can have multiple functions with the same name so long as their argument types vary (which is called function overloading). Since most other languages lack support for this, they had to define a way to tell the compiler that a specific set of functions should be resolvable by name alone, hence extern "C", which tells the C++ compiler to follow C's rules (and historically also extern "Pascal").

Most of my C++ code was contained in extern "C" blocks, and I had abandoned most of the C++ features for my own language's simpler implementations, so one day I woke up and realized I should stop fighting C++ and just use C.

If most of your code requires C linkage, you are either doing it wrong (not hiding the ugly bits inside proper classes that can be reused) or you're writing extremely modular code, in which case you should consider switching the modules to C++ rather than the C++ core to C.

My problem was that I needed a language that let me closely express the construct of another language within it -- embedability was a prime factor. Sure I could write the VM in C++, and have a ton of interfaces and abstraction and overloaded operators, etc, but with C I didn't need to do that.

Or maybe you made the wrong design decision to develop the same layer in two languages. Why didn't you write all the scripting code in the scripting layer and all the core code in the core layer? Why does there have to be scripting logic in core code?

Some of the reasons I left C++ for are being fixed / added in C++2012, but it's too late for me. I'm not going back. I'll use C++ for my C++ only projects, but for anything that needs to work with other languages (most of my code), then I'll use C. Bonus: Instead of 15 minutes to compile the C++ implementation, it takes just seconds as C.

You don't use Makefiles or any other building tools that determine whether dependencies need recompilation? Oh by the way, there is not and there won't be a C++2012.

C has many pitfalls, but at least they're out in plain sight; Unlike the C++ pitfalls, which are hidden in corners, shrouded in "advanced feature" mystery, and blanketed by the fog of denialism -- When things that should work according to spec don't (because of the implementation details), then you do you really have a language, or is it just part of a language?

Care to name one of those things? I'd be surprised if you had actually read a single line of any C++ standard...

C++ has the same problem with C that I experienced with C++ -- When you try to implement a language in a way that's really close to another language, so you can use its underlying tool-chain, you run into a point where you must be shackled by the base language's implementation details... You can either build around the limitations (what C++ does), or you can embrace them (what I've done). Unfortunately I couldn't embrace the C++ implementation -- a complete one doesn't exist.

Both gcc and clang are full-featured C++03 compilers, and they're both on their way to become full-featured C++11 compilers, too. In the case of clang I actually doubt you'd notice the missing stuff since most of it has to do with the new memory model.

On the other hand, a lot of real-world C++ code is as crappy as it is exactly because people write it as if it were C with a few extensions, rather than taking advantage of other C++ features that would make it actually nice to read.

Usually I stand for C++ in these debates, but here I have to draw the line, because as an experienced developer I can tell you that writing clean C++ code requires a huge investment of time. For example: a container implementation that can be written in 6 lines of C macros can extend for thousands of lines of C++ code just to make it compliant with the standard library's containers of the same kind so that it can be used in generic programming as well as with C++'s algorithms, and it's not the container alone, the main container (collection) may require a secondary container (bucket) to store individual elements in cases of non-linear access time (such as B-trees, lists, and graphs), and depending on the type of container, also an iterator with input, output, forward, sequential, and random access capabilities, all of this for const and non-const qualified access, with appropriate template specializations for specific algorithms, and if you really care about performance, a specialized atomic version. Oh and don't even get me started about streambufs or stream manipulators! Iostreams alone make me glad that the C standard library is part of the C++ standard -- iostreams are extremely slow and seem to have been designed by idiots.

As an example of this, it helped me a lot when I finally realized that, in C++, you can use almost any well-implemented type as if it were a primitive type like int. Memory management in C++ is a bitch and leads to lots of ugliness, but, in most cases, it simplifies to having your object created at declaration time and destroyed when it goes out of scope, much like an int would.

Memory management in C is even worse since it doesn't implement RAII (stuff getting properly destroyed when its duration time expires or an exception is thrown).

On the gripping hand, you can't use the approach that makes C++ nice to read in all cases. Because you have to call an object's destructor exactly once, after the last time the object is used and before the last reference to the object is lost, you need some way to keep track of this. This is where a lot of the complexity in C++ programs comes from, and a lot of the bugs, as well.

That's why the Reference Counting paradigm was invented, so you don't have to keep track of ownership and can implement libraries that take ownership of objects provided by their users without being concerned with those objects being unexpectedly deleted. C++ implements that through unique_ptr (takes exclusive ownership of its pointee until the end of the pointer's life, at which point its pointee is destroyed), shared_ptr (takes shared ownership of its pointee and destroys it at the end of the pointer's life but only if no other shared_ptr is pointing to the same pointee), and weak_ptr (doesn't take ownership, allows access to the pointee as long as there is at least one shared_ptr pointing to it -- this is used to mitigate the potential for memory leaks caused by circular references when two objects could otherwise claim to own each other without being owned by anyone else).

C++ compilers are big, complicated and slow, and statistically more likely to contain bugs.

Agreed, they should have stuck to BrainFuck! With only 7 instructions, the likelihood for bugs is pretty small, and since there's absolutely no way the compiler could make an attempt to guess what you're doing, you don't even have to deal with optimization bugs!

I still prefer to use OO in C or assembler.

The most agreed-on component of OOP is self-awareness, i.e.: objects are aware of themselves and the language provides a this / self pointer that always refers to the instance a function7 was called as. If the language does not provide such a facility, then it's not OOP by any stretch of reality. C does not provide such a facility, and neither does assembly on any architecture that I'm aware of, including intermediate languages such as Java's bytecode (which actually does support other OOP concepts such as polymorphism).

It seems to me as if the languages are designed to hide functionality from the programmer.

Here you demonstrate total lack of knowledge of C++. C++ does not hide anything from you, bottom line it's as low level as C. It does, however, provide the ability to enforce encapsulation, which is one of the pillars of all Simula-style OOP languages, but so does C with its static keyword...

For some reason some programmers think that "readable" code is when you write as many abstraction levels and help functions that it's pretty much impossible to figure out if code is efficient or if it is going to deadlock on you if you as much as look at it.

And what does any of that have to do with the language at all? If you use someone else's libraries you're bound to have the same problems in C, too...

My hostility is definitely not aimed at OOP. I'm very sure that I just have a hostility towards a small set of programming languages. (Just be glad that TFA didn't mention PERL.)

It's Perl, not PERL, it's not an acronym, you idiot! I'm pretty sure your hate is entirely motivated by your ignorance and fear of the unknown as perfectly demonstrated by your post! You should be ashamed of calling yourself a software engineer!

First, what's the STL?

Second, a struct and a class differ in that all class members are private by default whereas struct members are public. While you can obviously be explicit about making struct members private or protected (just like you can be explicit about making class members public or protected), it's best to have encapsulation turned on and hiding your internals by default than having them exposed by having encapsulation turned off.

That would never stick and would most likely backfire horribly for several reasons:

1 - I'm a nomad, so you'd have to track me down, and chances are you'd not find me where you think I am because I rent PO Boxes -- This would complicate your life attempting to find a plausible location for the murder.

2 - I make sure to find roommates to live with wherever I go for personal protection -- This means it would be extremely hard to find me in a situation in which I wouldn't have an alibi.

3 - I take note of all strange occurrences (I would be taking note of your post if I felt like there was a chance of you tracking me down) with timestamps and have those notes signed at and authenticated by a notary, because I never know what my roommates (who are usually people I don't know from anywhere) may do and don't wish to be involved in it -- This would make it extremely hard for you to frame me without me recording strange events.

4 - I resort to electronic transactions as much as I can -- This means that even when I am not with others I can still be traced by the places where I use my cards.

5 - I carry an iPhone and am permanently logged in to location-tracking apps -- This means that even when I'm not making transactions there is still information about my location being submitted to some place.

6 - My record is sparkling clean, at 30 I am yet to receive a single fine -- This would greatly reduce the plausibility of successfully accusing me of murder.

7 - I have no enemies and no conflicts of interest with anyone, in addition to having already opted myself out of inheritance (my sister kept the goods) -- This would make it extremely hard to find a motive for me to kill.

I would never go to court knowing that I was being accused of murder without gathering as much evidence as I could to demonstrate, without a shadow of doubt, that it could never possibly have happened, regardless of your own evidence. This is where Samsung failed.

PS: I know you all want answers, but I've hit my post limit or whatever (apparently one can't post more than 30 times within 4 hours) and thus won't be responding to any more posts for a while (if at all).

You don't see any difference in the meanings? One involves, well, direct attempts to influence jury, other one:

Of course I see the difference, what I don't see is the relevance in this case...

Really? Just hearing description of evidence is enough to influence jury? You're quite dismissive of legal system here, assuming jury's not only gonna break obligation not to read media coverage of process, but also going to be influenced solely by description of evidence explicitly dismissed by the judge and not even meant for consideration by juror.

Yes, really. Whether it influences the jury or not doesn't really matter, what matters is the fact that Quinn brought it up in the courtroom thus showing intent, with the communication to the press after being repeatedly told that the evidence wouldn't be considered demonstrating his contempt of court.

Seriously, read the fucking article, I see you still didn't do that. Even Apple's lawyers refer only to publication as attempts to influence jury, not about jury hearing his description.

Since when is my opinion required to be in agreement with Apple's or anyone else's?

Explicit (adj.) Very specific, clear, or detailed.

They were clear about the subject of the evidence...

So, "reconsider her earlier decision that Samsung not be allowed to present evidence showing that Apple's iPhone was inspired by "Sony style."" is very specific, clear and detailed influence?

It is not required to be all of those, only any of those. Notice the OR. Are you so desperate for an argument that arguing (incorrectly) about semantics is the only way you can reply? It's OK to admit you're wrong!

Also, you're again doing your thing with renaming "inspired by "Sony style"" to "Apple copied SONY". Hyperboles much?

Why is this relevant?

Samsing wasn't allowed to introduce it because they missed the deadline. Apple introduced it. Grab a law book.

The burden of proof is on your side. You need to offer either a logical or a factual argument, so go ahead and quote that law book. I'm sure you can do it, otherwise you wouldn't be telling me to grab one, right?

And now you go from "tried to influence the jury with inadmissible evidence" to "tried to force inadmissible evidence".

What's the problem with that?

Did he present the said evidence to the jury against orders? Are reporters on the jury now?

Yes, by explicitly stating that the evidence was about Apple copying SONY in the courtroom.

Your definition of "Samsung explicitly tried to influence the jury in the courtroom using excluded evidence" is rather stretched.

I am yet to see how...

How is Samsung supposed to know what Apple 's going to talk about before they talk about it? And also pre-introduce evidence to refute what Apple's going to say before they say it?

That's what the pretrial was for... Samsung was probably counting on the Judge accepting their "evidence" after the deadline so that Apple wouldn't have a chance to file counter-evidence, a strategy that has obviously failed.