In C++ I am writing a bubble-sorting algorithm to sort a list of strings alphabetically ... If each string is 10,000 characters in size, and there are 40,000 strings your looking at a huge overhead implementing it this way.

If there are 40,000 strings, why have you decided to bubble sort them? This is under a bullet point talking about efficiency.
[/quote]

A better question would be why have you decided to sort them yourself at all in fact, rather than just using std::qsort()?
Another reason i prefer C++ over C is because i don't have to invent the wheel every time i want a linked list, R/B tree or sort function, or have my own libraries of code built up when STL does most of it for me and is very extensible.

In fact this is something one can observe in almost all C vs C++ discussions. The most rabid C defenders (explicitly including Linus Torvalds) have actually very little knowledge of C++, sometimes leading to almost absurd arguments.

The two most important sentences in the entire thread, summarizing it all.

This concept easily extends to other fields too, such for example revision control software.

CVS is total shit. The Subversion authors initially said they'd try to do right what CVS did wrong, and they aren't gits. So, without looking at Subversion, it is obvious that it's total shit, too. Clearly. Sending tarballs via email is better than Subversion.
Having said that, my Windows Subversion install is 3.5% the size of the side-by-side Git install, performs better in every respect, and has a much superior Explorer integration. Yes, committing over the internet is slower than committing to a local copy on the hard drive (which SVN does just fine too). What a surprise.

I won't even mention BSD

[quote name='Yann L' timestamp='1311049289' post='4837198']In fact this is something one can observe in almost all C vs C++ discussions. The most rabid C defenders (explicitly including Linus Torvalds) have actually very little knowledge of C++, sometimes leading to almost absurd arguments.

The two most important sentences in the entire thread, summarizing it all.

This concept easily extends to other fields too, such for example revision control software.[/quote]

Why don't Linux developers use Visual Studio? It's the best IDE, it's so much better, has better debugging, team deployment, it integrates with reporting systems and makes it easy to work with off-shore teams via Visio diagrams.


Is it perhaps because it simply doesn't work? Or because Linux developers have little knowledge of MVS?


C++ doesn't work for Linux kernel development. Simple as that. The assumptions C++ memory and OO model make *do not work* in kernel. The syntax features C++ introduces, such as scoping *do not work* with grep (there is no IDE for kernel development). The C++ ABI or lack thereof *does not work* with much of POSIX. That said, POSIX systems are C, so bringing in C++ doesn't really make sense. C and C++ are not compatible. At POSIX level they have some fundamental incompatibilities, but most developers will never run into them, since their work would have been much more suitable for something like Java or C# in the first place.


Why does one choose CVS or SVN? Management and regulation. In many if not most companies, developers are end of the line. They have no decision making power and when they write code they do so as instructed and when instructed. Just like engineering. On-site construction worker can't suddenly start experimenting with different support beams, because the choice was made after months of design and load testing work before it was cleared by regulatory process. So "performance" of SVN vs. git is irrelevant. The seconds/minutes/hours difference is factored in the whole 1 year process.

Distributed VCS are many, git is just blindly accepted because Linus does it and he has to be right. What they often forget is that they are not C kernel developers. There are other DVCS, but the biggest and about only advantage is departure of merging style and benefits it brings, not performance or anything else. They are considerably better suited for highly contested code and experimentation, which is the pinnacle of agile web development. If your development doesn't have such problem (single developer or share-twice-a-week), then DropBox might work just as well.

Or, if you work with Ruby, you use git. Not because it's good, but because everyone uses github. It's always about process, or better yet, people. Tools evolve around that.But at minimum, they need to work. No matter how good, they simply must not lack even one required feature. A tool may be best in everything, but if there is just one single thing it lacks, it will not be used.

Err.... why all the git hate? It's actually quite good. I prefer mercurial, but there really is nothing wrong with git except the slightly larger learning curve compared to traditional central version control. Despite what people are saying, DVCS ARE faster than using a central repo. Local commits are practically instant, which encourages people to commit more often which creates a much better history of development which in turn makes merging much, much easier. We have been using mercurial for around six months and SVN for three years before that. Mercurial is much more effective if you have more than one developer working in the same project at the same time.

C++ doesn't work for Linux kernel development. Simple as that.

Well unfortunately it's not that simple. C++, OO and even garbage collection work perfectly fine for a kernel, they just don't work for the Linux kernel. The reason being historical design decisions, but in no way technical or conceptual limitations of C++. The Linux kernel memory model was a design decision, not a necessity. Source compatibility with grep was a (very awkward) design decision. POSIX and its ABI are historical artifacts that should have been nuked ages ago.

At the bottom line, there is absolutely no technical reasons C++ wouldn't work on a Linux like kernel. The use of C was an explicit choice by the kernel developers. It was historically motivated and is fanatically upheld despite it being completely irrational nowadays. In fact the open source world, especially the Linux kernel developers, is a special corner case. Decisions are mainly driven by ideology and idolization (Linus, RMS, etc) rather than by technical or efficiency-based analysis. Due to the unfortunate fact that some of these popular idols are very far from being C++ experts, yet very vocal about their technically unfounded opinions, C-itis is still strong there.

Why don't Linux developers use Visual Studio? [...]C++ doesn't work for Linux kernel development. Simple as that.

No doubt about that as far as all the IDE things go, and I agree at least partly with other things. It's not what I'm saying though. I'm neither claiming that C++ would just work for the Linux kernel or that it would be equally or better suited. Obviously you can't just plug C++ in there and expect it to work, but I don't doubt that it would be possible to use C++ in kernel development (most issues that you pointed out are true, but solvable).
But that's not my point, my point is that because Mr. Torvalds says C++ is shit, that isn't necessarily so, and repeating the old mantras about how C is so much better and more efficient when it isn't is just silly.

I'm against claims such as "C is more portable than C++" too. From the specification, C++ is more portable, because a lot fewer things are undefined.
In fact, it's funny to speak of C and portability in the context of Linux, since nothing is as non-portable as the (entirely written in C) Linux or any program running under it. All those "portable" programs depend on ./configure fixing their non-portability issues via macros, and hardly one program compiled under one Linux distribution runs under another distribution, with the same kernel version on the same processor. Let's not even talk about a different version or processor.
I'm not saying that this would necessarily be any different with C++, but I object to the "ah... C++ is shit because C is soooooo much more portable". The claim just isn't real, especially not with software that needs stuff like [font="Courier New"]#define SIZEOF_INT 4[/font] to compile and that works on raw pointers depening on hardcoded offsets and such.

I'm also against the "good C programmer, shit C++ programmer" comparison. This one pisses me off in particular. There are as many bad C programmers as there are bad C++ programmers (and as there are C programmers who think they are C++ programmers, and Java programmers, Ruby programmers, and <insert any other language> programmers). You just can't compare a "good C programmer" to a "bad C++ programmer" and say: "see, C is much superior, because C++ programmers are shit".
Except that C++ with its much stricter rules and much better type checking might indeed be able to catch a lot more stupid errors. The compiler catches 1-2 really stupid errors of mine per day, and I don't consider myself a particularly stupid programmer (not more stupid than anyone else, anyway). And guess what, I'm happy that the compiler finds these things early, it makes my life much happier.
Also, C++ with its much bigger standard library requires a "shit programmer" to implement a lot less boilerplate code, which means there is a lot less room for serious mistakes. Among the major reasons why Java and C# are successful is not so much that they are superior in some way, but the fact that they have very complete standard libraries that "just work".

Of course nobody can prevent someone from using a standard library in the most stupid way possible, but that applies to every language and every library, and isn't the fault of C++ in particular. I can write a hell of a stupid, inefficient program in C or in Java too, if you give me a few minutes.

Distributed VCS are many, git is just blindly accepted because Linus does it and he has to be right.[/quote]Yep, thats exactly it, and that's what I don't agree with. That, and the author's attitude.

Err.... why all the git hate?

It's not Git hate, you got that wrong, it's about the attitude, I only used Git as an example because its history contains a very "bloomy" description of said attitude.
Git performs kind of ok, there is little doubt about that, and if someone likes to use it, no objections. But it is not much superior to all other revision control systems for the average user, and certainly not the best thing since the invention of the wheel. It's not for everyone, either.
But most importantly, it's not like everything else is shit, just because Mr. Torvalds thinks so, and because he knows everything. The nasty things that I wrote in my previous post about Subversion are an almost word by word Torvalds quote. I didn't make those up, you can find them on the internet.

Granted, Mr. Torvalds started a Unix-like kernel project, and I didn't, so you could say that's 1:0 for him. But that does not make him God, or the supreme ruler of programming. If you're being honest, the Linux kernel in the early 1990s as conceived by Mr. Torvalds had mostly one truly good property, and that was that it didn't cost anything. The (so-called) contributions (which in reality are the major, important part!) from people like Mr. Anvin, Miller, Molnar, Card, or Ts'o (incomplete list) are what actually made and makes Linux competitive today. Without these people, it would be nothing. Also, it is the hundreds (thousands?) of GNU programs and millions of man hours provided by GNU supporters which actually kept Linux running for two decades. We would not even be able to boot Linux without the GNU people.

So in one word, what I don't agree with is idolizing a person in such a way and justifying every stupid and nasty thing he says which is of course automatically true, because it's him.

The reason why C is more portable than C++ is that to have a proper C++ implementation, you first need to have a proper C implementation. Implementing C is easier. Simpler. As such, there exists more C compilers for embedded systems than there are C++ compilers. Though, I am not aware of how standards compliant these compilers are, as I mainly work with GCC myself anyway, which often does the trick for most developers but not always, that's when the developer has to rely on the (often proprietary) implementation of the hardware manufacturer, which may be complete mess with all the undocumented/unsolved bugs and quirks.

n fact, it's funny to speak of C and portability in the context of Linux, since nothing is as non-portable as the (entirely written in C) Linux or any program running under it. All those "portable" programs depend on ./configure fixing their non-portability issues via macros, and hardly one program compiled under one Linux distribution runs under another distribution, with the same kernel version on the same processor. Let's not even talk about a different version or processor.
I'm not saying that this would necessarily be any different with C++, but I object to the "ah... C++ is shit because C is soooooo much more portable". The claim just isn't real, especially not with software that needs stuff like #define SIZEOF_INT 4 to compile and that works on raw pointers depening on hardcoded offsets and such.


[/quote]

Examples please. And explanations as to what makes you think that binaries wouldn't work on different distros or kernel versions. And how is this related to C and C++ anyway? I recommend you to take a look at Single Unix Specification standards which define pretty much everything related to portability within Unix-like systems. The corner cases(e.g. distribution specific) are often handled individually. This is more about the scatteredness of the Linux distributions and the lack of (need to have) proper guidelines. This is both a strength and a weakness and is not related to this topic.




To my understanding there hasn't been any kind of glorifying towards Torvalds in this thread, so why the hate?

How about autoconf as an example, the actual program used by 99% of linux programs to adjust their own code to be portable?

Very few open source developers distribute binaries that work on different linux systems either, they distribute source, simply because everybody has different versions of libraries, and trying to randomly run binary A from distro B on distro C just results in undefined external or missing shared object errors, unless you statically compile the lot.
Statically compiling a binary for the sake of portability is a dangerous proposition, as you are then left 'holding the baby' when it comes to all security updates for any libraries your application uses, not to mention your whole idea of a C program being 'small' then goes out of the window as you linked several libraries to it.

As for the kernel, drivers dont work across different versions quite simply because there is a constant compiled into each driver which must exactly match that of the kernel proper. Again, these are recompiled, not distributed as binarym unless you refer to binaries packaged for a particular distribution, which are designed to be compatible, but only with that particular distribution and version.

Case in point: The nvidia binary blob drivers. There is a binary blob that is compatible with the whole 2.6 range, and then there is a stub it attaches to that must be rebuilt for every kernel version.

The reason why C is more portable than C++ is that to have a proper C++ implementation, you first need to have a proper C implementation.

Really? Why?

[quote name='Calmatory' timestamp='1311100358' post='4837550']
The reason why C is more portable than C++ is that to have a proper C++ implementation, you first need to have a proper C implementation.

Really? Why?
[/quote]

Well, (without taking in the fact that standard C library is also part of the standard C++ library, though they are hardly used in most embedded development) not strictly, and actually not at all with the upcoming C1x and C++0x standards, since they just depart the languages even further. But for example C++98 is pretty much compatible with C89 apart from few type-safety differences as mentioned before. As such, the logical step is to make a C(89) compiler and extend it to a full C++(98) compiler from there. Though most(if not all?) proprietary(and some open even) C compilers are not C89 compliant anyway, let alone C99.


As it is right now, there exists more C compilers for embedded devices than there exists C++ compilers. I'd claim that the main reason is that it is easier to implement a C compiler than it is to implement a C++ compiler. I guess today GCC takes care of cross compiling though, except for some rarer hardware.

Motivated by this thread, I decided to grab the good ol' The C++ Programming Language by BS and give it a go.. ..after I've got it collect dust for almost 3 years without ever really taking a deeper look at it.. .. UNITL NOW!