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.

So you're saying the F700 is admissable evidence?

Or are you saying that it's inadmissable for Samsung but admissable for Apple?

Neither, the F700 is a phone. The references to the F700, however, are admissible in the case of Apple (because they were submitted before the deadline) but inadmissible in the case of Samsung (because they were not submitted before the deadline). If, after this, you can still not understand what I'm talking about without resorting to even more straw man fallacies (what you did here), I have no option but to consider you a troll.

Would you please stop this sh*t? In every single f*cking discussion regarding Apple vs Samsung, here comes Deorus droning ad nauseam in favor of his beloved Apple! No matter what argument was made by the one you're replying to, you keep spouting the same canned responses over and over.

Hint: this behavior does not make you look informed, it just pollutes the discussion and shows what a rabid fanboi you truly are.

I'm sure you can refute me, then...

The rest of your rebuttals are moot since you failed to read any of TFAs

Then I'm sure you can demonstrate how I failed and I will provide you with counter evidence to refute both you and TFA. ;)

Contempt requires an order. There was no order NOT to release the information, which was publicly available anyway.

Since when?

Source.