C++ is a horrible language. It's made more horrible by the fact that a lot
of substandard programmers use it, to the point where it's much much
easier to generate total and utter crap with it. Quite frankly, even if
the choice of C were to do *nothing* but keep the C++ programmers out,
that in itself would be a huge reason to use C.
In other words: the choice of C is the only sane choice. I know Miles
Bader jokingly said "to piss you off", but it's actually true. I've come
to the conclusion that any programmer that would prefer the project to be
in C++ over C is likely a programmer that I really *would* prefer to piss
off, so that he doesn't come and screw up any project I'm involved with.
C++ leads to really really bad design choices. You invariably start using
the "nice" library features of the language like STL and Boost and other
total and utter crap, that may "help" you program, but causes:
- infinite amounts of pain when they don't work (and anybody who tells me
that STL and especially Boost are stable and portable is just so full
of BS that it's not even funny)
- inefficient abstracted programming models where two years down the road
you notice that some abstraction wasn't very efficient, but now all
your code depends on all the nice object models around it, and you
cannot fix it without rewriting your app.
In other words, the only way to do good, efficient, and system-level and
portable C++ ends up to limit yourself to all the things that are
basically available in C. And limiting your project to C means that people
don't screw that up, and also means that you get a lot of programmers that
do actually understand low-level issues and don't screw things up with any
idiotic "object model" crap.
So I'm sorry, but for something like git, where efficiency was a primary
objective, the "advantages" of C++ is just a huge mistake. The fact that
we also piss off people who cannot see that is just a big additional
advantage.
If you want a VCS that is written in C++, go play with Monotone. Really.
They use a "real database". They use "nice object-oriented libraries".
They use "nice C++ abstractions". And quite frankly, as a result of all
these design decisions that sound so appealing to some CS people, the end
result is a horrible and unmaintainable mess.
before you start talking about one VCS being faster than another, you should ask yourself, "is it faster than CVS?". in this case, the answer is no. feel free to continue comparing one slow as fuck VCS with another slow as fuck VCS, while the rest of us get real work done.
Name:
Anonymous2009-07-06 11:37
I agree Linux, C++ programmers are mostly substandard and the language just sucks.
Name:
FrozenVoid2009-07-06 12:44
I agree with with him completely. Also C++ template/class abstraction is worst OOP approach ever.
C >= C++
Yes, the post-increment operator does work like that.
Given this, is C++ only greater than C after it's been evaluated (i.e. run)? Is this a joke by the developers of C++ that it actually isn't better than C?
Name:
Anonymous2009-07-06 12:55
//`'''```,
o // LISP `.,
,....OOo. .c;.',,,.'``.,,.`
.' ____.,'.//
/ _____ \___/.'
| / || \\---\|
|| || \\ ||
co co co co
Name:
FrozenVoid2009-07-06 12:56
>>9 C=1
C++ post-increment, value of C=1
++C pre-increment,Value of C=2
___________________________________________ http://xs135.xs.to/xs135/09042/av922.jpg
A government big enough to give you everything you want, is big enough to take away everything you have
Name:
Anonymous2009-07-06 12:58
>>10
Haven't seen you around for a while, you suave fellow.
>>11
I had to SEE YOUR POSTS to see what >>13 was on about. There's no wonder you haven't managed your amazingINFINITE COMPRESSION if you can't properly evaluate simple expressions in your head.
Name:
Anonymous2009-07-06 14:42
Linus must be the biggest troll ever. Linux has made him so arrogant, and he's to dumb to see that the success of it was mostly luck.
Name:
Anonymous2009-07-06 14:50
>>17
It was not luck. It was successful because it was free and actually available unlike Gnu/HURD.
Linus is not arrogant at all. You are ignorant because you obviously didn't read his whole posting but just that snippet. He didn't say C++ sucks in general, he said it sucks in terms of (linux) kernel development. Also Linus is a hacker so obviously he'll know better than your average C++ fags, who like to throw buzzwords at each other all day long instead of getting the work done.
[5:29] I am new
1 Name: Anonymous : 2009-07-05 13:23
hey /prog/ i am really new to programming and was hoping you guys could give me somewhere to start out like a really good beginners guide or maybe even just a basic programming language for starters.
In my experience with C, well-written C code tends to look like C++. Properly modularized code tends to be object-oriented by design. You have structures that maintain state, and lists of functions that operate on those structures which always take the structure as the first parameter. It looks like C++ with different method syntax.
Take any number of open pure C libraries, e.g. libpng, sqlite, etc. They all look the same way; they are all object-oriented. Libpng goes even further: it uses C++ style catch/throw. It maintains its state in its structure and longjmps to signal error, then cleans up when you destroy it.
The features that are good in C++ are the features that simplify this process: constructors/destructors, method syntax, operator overloads, and catch/throw with stack unwinding. A very small set of extensions to C.
In my experience with C++, well-written and well-behaved low-level libraries (e.g. hardware abstraction libraries) use only these features; they use very little STL and almost none of the other language features. There is really a direct translation to object-oriented C code this way (not counting stack unwinding). Compare:
Using C++ features like constructors/destructors for RAII and operator overloading just cuts down on the boilerplate and makes code easier to read. Indeed, C++ originally started as just a preprocessor for this very reason. Personally, I would write any low-level library this way (and do in my day-to-day job, like the above File class). If you really need it, a pure C wrapper can easily be generated automatically from the resulting class definitions.
I have a completely different opinion on desktop applications though. When writing a big desktop app, you ALWAYS have a need for a dynamic array for example. For these applications I really don't give a damn how fast varying implementations of std::vector<> might be; the stability and featureset always tops rolling your own container. It just makes no sense to rewrite STL since you inevitably need to use it. Besides, since it's your own application, there's no reason not to just stick to the same implementation of STL on all platforms (e.g. libstdc++).
Same goes for most of STL, e.g. std::string versus traditional char*. Adding strings together is just *really fucking easy*, so I don't care how inefficient it is. The complexity and danger of optimizing it is just not worth it.
Name:
Anonymous2009-07-07 1:40
>>34
As an addendum, I want to say that I approve of some smart pointers as well. I say some because I believe reference counted pointers should *almost never* be used. boost::shared_ptr is currently widely used to overcome limitations in std::auto_ptr (e.g. use in stl containers), and the remaining uses are usually bad design decisions (especially wrt threading). I am looking forward to std::unique_ptr in the new C++ standard to fix a lot of these problems.
The reason why I think they're important is because the above code comparison becomes much more pronounced with heap-allocated objects (which is of course almost always the real use). Compare:
The other main use for them is stack unwinding. Cleaning up the stack after a failure in C is a real pain in the ass no matter how you do it. Lots of factory functions give you a hierarchy of objects that you need to clean up when you're done (one that springs immediately to mind is opening http connections in any API since the dawn of time). With RAII and smart pointers you can just return anywhere without ugly cleanup code. Compare:
Java syntax is obviously not high-level; the VM is. It's this big honkin' monstrosity that does tons of questionable stuff behind the scenes, without actually making the programmer's job any easier. This is the same problem I have with D. Like Java it's barely higher level than C++ but it runs almost as interpreted language.
I was not implying low-level programming is generally good; in fact quite the opposite. I don't understand why Java exists at all when scripting languages take the overhead of a VM and actually trade off something good for it. I'm a mobile developer and I fucking hate Java phones because they aren't low-level enough; but anything that doesn't go on a device, I write in Python.
Name:
FrozenVoid2009-07-07 3:29
>>35 Extensions to C which allow catch/throw/exception/new/delete (without C++ )etc have been available since the mid-90's
>>39
OOP is natural if you started off with C and see (no pun intended) how objects are basically structures and methods operate on them. All the hate that OOP gets these days is because of those who don't really understand it, just memorize some stupid facts that sound like the marketing department made them, and believe it's object oriented, so it must be a good thing! This leads to the proliferation of objects and code that would feel like satori to an OOPfag, but is a horrible horrible thing to read for those who actually understand. It's worse than GOTO-filled C when the code has objects which have objects which have objects and so forth, so that you really have to jump all over the place to follow the flow (just like goto), except that the target of those jumps is even less clearly defined.
Not sure but beating an fleet with only one ship usually makes all your ships sparkle assuming the fatigue is at default value (at least it does for me).
Name:
Anonymous2013-08-31 21:37
14) マリー・ポッターと秘密の地下室II. This was added in patch 1.54. The real hard version of マリー・ポッターと秘密の地下室. Now without partners and you only stay half the turns on each floor.