Why do people use C when there's C++ anyway? C is so... unorganised.
Name:
Anonymous2006-10-14 5:52
To each his own.
Some people might have learned C, and never bothered with C++.
Also, there are fanboys.
Also, some stuff, like Ethereal plugins (last I checked) has to be written in plain C.
Happy-kai?
Name:
Anonymous2006-10-14 7:29
Saying C is unorganised when comparing with C++ is risible.
C++ is an unorganised mess (now). C's problem is that it's too low-level. C++ started off as a set of goodies and improvements on C, but it got a bit out of control after a while...
Name:
Anonymous2006-10-14 7:59
>>1
Because C++ is overcomplicated and disgusting for OO, and provides really nothing over C. I'm not the "There's nothing you can do in Python you can't do in C" guy, of course higher level languages are more productive and nicer to work in, but in the case of C++, you get a similarly complex, low-level language without any real advantages other than perhaps namespaces, at the cost of a lot of complexity and a huge set of features you have to remember, unless what you're writing is C++--.
Name:
Anonymous2006-10-14 9:02
>>4
C++ has the speed of C and the OO part, there is absolutely no other language on this planet that can do this right now.
Name:
Anonymous2006-10-14 10:36
>>4
Overcomplicated? How? I'm doing just fine with my multiple inheritance, <vector> and things like that.. not to mention the memory handling more straightforward
Name:
Anonymous2006-10-14 12:00
>>5 C++ has the speed of C and the OO part
Who said you want that done that way?
>>6
Multiple inheritance is fine, but nested templates and the memory management hell is not my idea of fun.
Name:
Anonymous2006-10-14 12:31
Overcomplicated? How?
H-o-l-y shit. Use a dynamic OO language. Any dynamic language. Yeah, we all know they're not as fast, but you're fucking insane if you think C++ isn't overcomplicated.
Hell, if you just HAVE to have it static, try Ocaml. Ocaml's already pretty ugly, but it's many times cleaner than C++, which is really saying something. Or poke a bit at Objective-C, which is a hybrid.
I do. I decide what I want to do and the tools I'll use. No one else does.
| but nested templates and the memory management hell is not my idea of fun.
Pussies fail at managing memory. And what managment? Object o; -> created and automatically destroyed for you.
Name:
Anonymous2006-10-14 13:10
>>9 I do. I decide what I want to do and the tools I'll use. No one else does.
Hint: Use assembly. C++ is making many decisions for you.
And the fact you think memory management is trivial or unnecessary shows you've never written anything over 200 lines of code.
Name:
Anonymous2006-10-14 13:18
>>10
| Use assembly. C++ is making many decisions for you.
Not when you can deduce the assembly code generated by the compiler.
| you've never written anything over 200 lines of code.
No one count lines of code anymore, noob. And YES, memory management is trivial.
Name:
Anonymous2006-10-14 15:15
This thread makes my head hurt.
C++ does have tangible benefits over C, and anyone who says otherwise simply hasn't written any applications of reasonable size. Language-level OO and forms of generic programming are incredible productivity boosts all around, and are, frankly, far safer than C's methods of managing data.
But, even then, to say that it's a clean design is a joke. It's a language where the standard library basically evolved out of "hey, this template stuff is kinda neat and it can all do this." All the way until the specifications for how templates work exploded into a horrible, horrible mess. And don't even get me started on the compiler error messages.
Memory management is easy peasy in C++ right up until you start dealing with references to data, or multiple things referencing something, or objects having to reference ach other. Then you get to make nightmarish messes of handles or have to resort to things like reference counting/garbage collection libraries, which can be a pain to implement and both have their drawbacks. Not to mention it has a tendency of making a mess of C++'s safe data management. While these can be pretty easy to maintain for a single-person project, as soon as you start adding other people to the mix it quickly becomes a nightmarish headache.
There's a reason most of my development these days avoids both C and C++ unless performance intensive code is absolutely mandatory.
Name:
Anonymous2006-10-14 16:54
"High thoughts must have high language" --Aristophanes
Oh, and here's a mind-bender for the few ignorant wankers who still believe GC is evil: GC is necessary for type safety. Why do you think all functional languages have it?
Enjoy your dangling pointer AIDS.
Name:
Anonymous2006-10-15 3:50
| GC is necessary for type safety.
Where are you pulling this shitty quote from? Uranus I guess...
Name:
Anonymous2006-10-15 13:51
>>16
Basically he's stating that if you explicitly deallocate memory and then create another chunk at the same location while references to the original memory block still exist(aka dangling pointers), you've broken safety and created a memory error. "Type safety" isn't quite the correct term here but it is what Wikipedia uses, and that's about as accurate as ever.
GC handily gets around that by not having any explicit deallocation whatsoever, ensuring that all references are valid at all times. Of course, this also causes fragmentation and cache misses as the program ends up allocating new memory like crazy until the GC kicks in.
Read comp.lang.c++.moderated a bit more often, okay? I'm not even a C++ programmer fer fuck's sake!
Name:
Anonymous2006-10-16 19:21
if you do explicit object creation and destruction you don't need a GC to ensure type safety. You're thinking too low level. You can use references like java where it doesn't matter how memory is allocated, a reference to an object is always typesafe.
Name:
Anonymous2006-10-16 20:50
Pah. Stale pointers lead to undefined behaviour, instead of broken type safety. It's true though that allowing memory to be collected exclusively through GC results in never having a pointer to a block that has been reassigned, however the benefits (and indeed the typesafety argument itself) are purely academic.
Name:
Anonymous2006-10-16 22:02
however the benefits (and indeed the typesafety argument itself) are purely academic.
Segfaults are purely academic?
>>22
Your view was widely accepted 20 years ago. Reality has since caught up with academia. Enjoy being mocked by your peers for your outdated views. Loser.
Name:
Anonymous2006-10-17 16:03
>>20
loooooooool, more shitty material from university teachers who never used C++ in the real world...
Name:
Anonymous2006-10-17 16:17
>>26
loooooooool, more shitty replies from highschool students who never used C++ in the real world...
Name:
Anonymous2006-10-17 17:40
After hearing so many horror stories about C++ (and dabbling a bit with the Half-Life code when I was younger), I was pleasantly surprised when I finally got around to learning C++. The more "late" aspects of C++ are actually quite good to work with, and Boost is just awesome =D
>>28
Indeed, most C programmers here are just K&R fanboys that can't accept any authority other than ANSI (lol) because that would make them unamerikan.
Name:
Anonymous2006-10-18 6:04
>>29
I know /prog/ doesn't exactly attract the most intelligent of posters, but you don't need to be _that_ stupid.
>>29
I'm European and I use ISO C99. I'm also a K&R fanboy and want to kill Stroustrup.
Name:
Anonymous2006-10-19 9:28
So in what way could C actually be considered better than C++ these days? It doesnt have a speed issue anymore, and C++ allows for better structure within the code?
Some embedded systems don't have C++ compilers, only C
Name:
Anonymous2006-10-19 14:15
>>37
stdio sucks, I only printf with OpenGL, I'm l33t.
>>38
what are you waiting to write one? sitting on your lazy ass won't help you...
Name:
Anonymous2006-10-19 15:50
>>39
No I'm not wanting to write one. Look at the comment I was replying to, I was explaining where C can be considered better than C++, i.e. where C++ is not available because it's too complicated for the platform being programmed.