The refusal to compile does not make the program behave differently. It does not change the behaviour of the program; in other words, it does not crash in places that it did not before.
Are you kidding?
Read the rest of my post. It most certainly crashes in places it did not before. Refusing to compile/run, means it acts differently. Either metric you chose, you're still wrong.
I did what you mentioned before and both MSVC 8.0 and Mingw32(i.e. gcc on windows) say sizeof('a') == 1.
Then according to Bjarne, MSVC 8.0 isn't a C compiler. Regarding MingW32, I have no idea what you did wrong. Perhaps mingw was setup to emulate MSVC for compatability purposes.
Then MSVC isn't a C compiler. Have a good day. GCC compiles hapily.
I don't claim I know all of C, but I have used a large part of it, nevertheless.
Or you have to compile it with '#ifdef __cplusplus extern "c". It is not that difficult.
But these are changes! How can something be a superset if it requires changes to be compatible?
I accept Objective-C as a superset as it doesn't require changes. There is no extern "C" in objective-C, there is no new casts, all C code is valid Objective-C code.
If you REALLY THINK C++ is a superset of C go ahead and compile something big like the Linux kernel with a C++ compiler and see how far you get.
use an allocator pool. There are several available. Or write your own; it is trivial. And if you use a statically allocated block of memory, then Windows will allocate the pages for you on start up. I have actually used this on the copying garbage collector I wrote once.
It's not the same thing. You cannot allocate multiple objects out of a static pool in C++ and still get initialization. All of your constructors would need to shadow their allocations against the static buffer, which means uglier code.
So in that light, you don't know sockets, either. See previous discussion which you conventiently avoided to continue.
So let me get this straight. You'd rather not know C or C++, just so I don't know Winsock?
I wasn't going to argue with you on it because this wasn't my point, and it wasn't your point. Your point is that C is a subset of C++, so I wanted to focus on those elements. But if you insist: Winsock most certainly responds to ioctlsocket(h,FIONBIO,...). Yes Virginia, you most certainly are wrong.
You also don't know Java, since the benchmark you presented is ridiculus (to say the least).
Boo hoo. You said you had never seen a benchmark demonstrating Java as being faster than C++ at some things. You never said a valid one, nor gave a criteria of what a valid one would look like.
You wanted to say "Visual Basic Classic" maybe. Because Visual Basic.NET does not have it. And since Visual Basic Classic is obsolete, there goes your argument.
Why? Because you say so without justification?
Fine. I accept that you're wrong.
I will say it again: for all practical purposes, C can be considered a subset of C++. Please note the bold part. Maybe it gets in your head this time.
Can be considered a subset by you, a person who admittedly "doesn't know C all that well."
So who appointed you to speak for customers? I'm a customer and I own plenty of non-free software that I consider a win for me. Or is this one of those cases where you think you know more about what other people need than they do?
It's a case where if you take part of a quote out of context, it helps you build your case.
Or maybe you didn't understand it.
Eiter way, the original quote is:
Microsoft has the development resources to compete with GCC and Linux. A lot of people forget that if you ever produce a valuable piece of software, Microsoft can, and may compete with you. Unless you're built on Free Software, Microsoft will probably win. And unless you're built on Free Software, your customers will definately lose.
Now, those "non-free softwares" that you buy that are a win for you- are they non-free softwares that Microsoft directly competes with?
Because if not, you're arguing apples to oranges. I said if Microsoft decides to compete with non-free software, Microsoft will probably win, and the customers will lose. I say this because in the past, Microsoft competes with non-free software and wins. And where they win, the customers lose. Ask anyone who has "upgraded" from a now defunct company to Microsoft Great Plains to get a good handle on what I'm talking about.
You said "raise the bar" but you apparently don't understand what it means.
Check again. That was GPP, not me.
There are probably $30 photo editing programs that are no better than Gimp and still turn a profit. The success of a product isn't entirely due to technical merit, marketing plays a role as well. For many people if Gimp isn't in a box sitting on the shelf next to the other photo-editing software at Best Buy it doesn't exist.
Fair enough.
GCC can compile C,C++,Objective-C, Objective-C++,Java, and Fortran. The current VS can compile C,C++,VB.NET,C#, and J#. This is a significantly less diverse set of languages.
GCC can also compile ADA. The Visual line can also compile J++, VB[6], VBA, and JScript.
If we're talking about overlap, however, OBJC overlaps very nicely with C, and OBJC++ overlaps C++- both being strict supersets of their pairs. That means there's really two less "real" parsers and gode generators, in GCC.
It doesn't really matter though. What does matter is that there's never going to be another Turbo-C simply because it'll either have to do more than GCC does, or be Free Software.
And that's what makes Free Software so much better than proprietary software. Someone needed 48-bit floating-point per-component editing at extremely high resolutions, and so someone could extend the Gimp to do so (and has!). Without the Gimp, that feature would have to be important to Adobe.
I agree that it's useful for those with niche needs that don't represent a market large enough for a commercial company to invest in.
Oh, but it's so much more useful than that.
Microsoft has the development resources to compete with GCC and Linux. A lot of people forget that if you ever produce a valuable piece of software, Microsoft can, and may compete with you. Unless you're built on Free Software, Microsoft will probably win. And unless you're built on Free Software, your customers will definately lose.
That does not change the meaning of a C program used in C++.
You say this alot, but if the program refuses to compile, or compiles but crashes in new and exciting ways, you're wrong.
No, it does not. sizeof('a') is 1. At least that what MSVC 8.0 and MingW32 give me.
sizeof('a') == sizeof(int) in C. Code compiles, but acts differently, and as a result: You're wrong.
Verify just how wrong you are if you like:
#include <stdio.h>
int main(int argc, char *argv[]) { printf("%d\n",sizeof('a')); }
Prints "1" when compiled with g++, and prints "4" when compiled with gcc (on my system).
"C++ requires I define variables only once."
Watch this program compile in any C compiler:
int i;
int i=5;
Look, you're wrong again!
"Structures are scoped in C++ and not in C."
Watch this program compile in any C compiler:
struct foo { struct bar { int x }; }; struct bar y;
Look, you're wrong again!
"Function pointers can't be used unless they're surrounded with extern "C"."
Here, they'll compile on many systems, but they'll crash! You either have to compile all the code with C++ (including the bits that you only have binary-only blobs for), or edit the source.
"So what? Did I ever say there was no software written in C++ that was good? Did I say all C++ software is terrible? That it's always slow? That it's not fast? That C++ can write many different things?"
Yes, you implied that.
And you implied that you know C, you don't.
You might know C++, but since you don't know C, you're left with only two options: (a) You don't know C++ either, or (b) C++ isn't a superset of C. I'd hope it were easier for you to believe the latter, because it's much easier to not know something you don't use every day.
I declared it from the beginning: I am using the term 'real-time' in a wider sense. Are you too stupid to understand that?
Unfortunately, mathematicians and computer scientists aren't allowed to coopt definitions just because they feel like it. I rejected your wider sense because you haven't given me any reason to believe your definition is more useful than the ones I suggested, i.e. "quickly" or "interactively".
You may contend that as long as you like, but reality is different.
Reality is demonstrated.
You don't know C.
Can other languages do RAII?
Visual Basic.
Can other languages do as finegrained allocation as C++?
More so. I frequently use a big char[] or double[] buf, and allocate smaller chunks out of it. By using.bss in this way, I get a speed boost on startup (something very useful on UNIX) because the pages my program needs are already available, and my program never has to call brk()
But since allocation is performed by the object (especially in RAII), this performance-boosting method is completely unavailable when using C++.
Can other languages allow the programmer to use machine code so easily, as needed?
Err, unless your machine code is in a char*, that's assembly, and C++ has nothing to do with it. In any event, C is easier in this situation because objdump doesn't have to deal with demangling names.
But a language that is good at most tasks is preferrable from a language that is the best in less tasks. It allows the programmer to do more things with less trouble.
I disagree with your assertion, and this is probably why we're arguing in the first place. Languages are tools. I restrict my C programming to security barriers- where I have to write code that I, and others on my team must audit. 100% secure is what we need. I
But for the most part these non-free applications were already better years ago than the latest "free" software versions are today. The "free" alternatives might eliminate the low-end customers, but they can't "raise the bar" if they can't even reach it.
You're missing the point.
In order for a software company to enter the photo-manipulation business, they need to produce something better than the Gimp- not better than Photoshop. Whether Gimp is better or worse than Photoshop doesn't matter- the Gimp is available freely (both in the capital Free and the lowercase free sense), so there is no room for a 5$ photo-editor unless it's 5$-better than the Gimp.
GCC is a special case because no commerical company would build a single compiler that supported so many different languages.
Microsoft's Visual line of development support more languages than GCC (while there's some overlap, there are different languages here). What's really good about GCC is that because someone found it valuable for GCC to target architecture foo, GCC targets architecture foo. In order for Microsoft's Visual C to target architecture foo, Microsoft would have to find it valuable.
And that's what makes Free Software so much better than proprietary software. Someone needed 48-bit floating-point per-component editing at extremely high resolutions, and so someone could extend the Gimp to do so (and has!). Without the Gimp, that feature would have to be important to Adobe. Who knows, maybe it is now (I stopped tracking Photoshop a long time ago).
I said that the overhead for context switching is noticable only when there are 100s of threads.
And I said you don't get anything for free. "Not noticable" sounds highly suggestive.
The BSD socket API is BLOCKING, and therefore you need THREADS to take advantage of it.
Someone needs to tell that O_NONBLOCK then. BSD sockets support nonblocking just like every other fd.
Wrong. Vtables is an implementation of message passing. Message passing does not require a level of knowledge of the target.
Close: Message passing requires that there not be knowledge of the target. If you take away forwarding and the ability to handle unknown messages, it's no longer message passing. vtables can't do either, ergo, vtables are not message passing.
Wrong again, about Java. If the type of the receiver does not support the message, the compiler does not accept it.
java.lang.reflection says you're wrong.
Wow, don't say that to Trolltech, unless you want to be passed as an alien from outer space:-). Qt is totally C++, and the MOC simply compiles the macros to C++ files.
I don't disagree that MOC compiles to C++, I'm saying that MOC works around problems with C++ and so therefore cannot be counted as C++.
The fact that many C++ programmers don't know the difference is discouraging.
Repeat after me: the MOC DOES NOT ADD OBJECTIVE-C FEATURES TO C++. THE MOC SIMPLY COMPILES MACROS TO LEGAL C++. IT IS A FREAKING PREPROCESSOR!
MOC adds message passing to C++. You may treat it as a "fraking preprocessor", but since the input looks like a normal method, and the output is a much more costly hashtable lookup, and two method calls, I call it hiding complexity.
Fortunately, that MOC does add those two objective-C features that C++ lacks: the ability to dynamically create and send messages, and the ability to receive and handle unknown messages.
Nope. Vtable lookup is one instruction in 80x86.
Check again. That's not a vtable lookup, that's an indirect function call you're thinking of. Vtable lookup is used solely for virtual method dispatch- i.e. the caller knows that the method is supported, but doesn't know where the implementation is.
So? operators are just another way to invoke a function. It is only syntactic sugar, and nothing else.
So you're telling me that when you see: a++ you immediately think oh shit, there's yet another line that can generate an exception, open/write to a file, etc? How can C++ ever be audited if you have to check every single operation that occurs.
Operator overloading is dangerous voodoo that makes any language supporting it, unsuitable for secure or bulletproof programs.
1) C is a subset of C++
No it's not. C++ is syntacitically similar to, but largely incompatible with C. int new; is completely valid C, but completely invalid C++.
2) you forgot SQLServer and Oracle.
No I didn't. This is about what is a language best at. If the best databases aren't written in C++, then what does it matter if there exists a database that is written in C++?
For what it's worth, the actual storage operations in Oracle happen to be written in C.
You are nitpicking. There are very few C features that C++ does not compile.
No I'm not. C++ treats a (void*) cast very differently than C treats it- I have to explicitly label all void* cast types before and after C++ use. C++ can't call C symbols unless they are surrounded with extern "C" {...}. C++ has a large number of reserved words that aren't reserved in C. C++ assumes all struct{}s are also typedef'd into
potential issues from mad cow disease, bird flu and whatever the next media induced panic is."
I'm not so sure about that.
Consider that the dangerous bacteria and viruses you're talking about, would only have a single organism to target, and we'd run the risk of a single lucky virus taking out the world's entire meat supply.
Unless of course, they are right, and there is no evolution- and every organism is the same as it was when the planet was summoned into existence over the course of a particularly shady six day run. In which case, we have nothing to fear, because new viruses are not mutating into existance, and we only need to protect this meat from the dangers that exist right now and just wait until all the mad-cow viruses go extinct.
I'm not sure I want to live in either world, so excuse me while I go take a chew on this helpless animal here.
Nope. Games do not have 100s of threads; the problem of context switching comes in only when the threads are many. Games have threads for I/O, for AI computations etc.
Wrong. Context switching on x86-based systems is about a hundread times more expensive than a PUSHALL/JMP operation.
[Networking] Oh yes they do. All multiplayer games do that.
No they don't. They use the BSD socket API (or a derivative) where the actual network communication occurs in kernel-space, a block of code, written in C.
The highest-throughput network applications are not written in C++. Consider the Net100 and the Web100 projects for details.
Joystick, mouse, keyboard.
These are examples of extremely low bandwidth devices. On x86 systems, they generate interrupts- and do not have to be polled. As a result, they aren't "realtime" on any system.
I never said "hard realtime". But it is real-time nevertheless, unless you want your game to frequently pause.
Stop using realtime to mean something other than what it is. It's not hard-realtime, it's not soft-realtime.
It does. Virtual methods is message passing.
No it isn't. It's a vtable lookup. Message passing is about the receiver knowing what to do with the message, whereas vtables require the function calling the virtual method know which methods are available (at least to the base class).
Consider Java or Objective-C message forwarding, or mach primitives to know what message passing is.
KDE is based on Qt. Full C++. And the BeOS? Full C++ as well.
Did I say you couldn't find an example of something written in C++? You can find entire operating systems written in Oberon. That doesn't mean that it's the "best" at it, or even particularly "well suited".
Nevertheless, QT is not written in C++. It's written in MOC because C++ doesn't (or at least G++ didn't implement at the time) have a message passing facility.
No, it won't. A perfect hash, i.e. array indexing, will always be slower, because the target has to be calculated from an array's base, whereas with vtables there is no calculation.
That's what I'm talking about. You think you get something for free. Use objdump to see what a vtable lookup actually looks like in assembly. Compare to the movl/addl/movl[] operation that a perfect hash can (usually) use.
What a lame argument. And what 'form.show()' does? what code does it evaluate? do you know?
It calls a routine called "form.show". It may or may not block. If I'm debugging code near a form.show() routine, I know to look at or near the source to the show() routine. If I see a line that says if (a<<b) I'd either have the choice of guessing that meant they're checking if the lower (32-b) bits of a are clear, or I'd have to check every single line of code in C++, hopefully with some really awesome crossreferencing tools.
I don't trust any human being to audit C++ in that manner: but at least with C, you know exactly where control can be transferred and where it cannot.
Also note: Java doesn't support overloading operators.
I've seen this so called "benchmark" which benchmarks whole programs
You've already contradicted yourself. You said you had never seen any benchmark.
So you've never programmed in C++ then?
I never said that. I just said I never want to use the wrong tool. I never said I never use the wrong tool.
Go to Bjarne Stroustrup's site and read the testimonies.
Bjarne is a second-rate programmer with a first-rate ego. At least, even He admits that C++ isn't best at anything, but good at lots of things (see his point in FAQ on "multi-paradigm")
Seems like encrypting twice with a 64-bit key just means that instead of breaking a 64-bit key once, you have to do it twice. That's like using a 65-bit key, instead of a 64-bit key. Every bit doubles your keyspace.
Ideally, yes, but it depends on the cipher, and the implementation.
The cipher may form a group, where a single 64-bit key will decode the double-encrypted ciphertext to the original plaintext, so instead of having one key twice, you really have two keys that will decrypt.
The implementation may leak information about encrypted data- lots of "pluggable" crypto systems leave a header that describes what cipher, keylength, and perhaps a magic string used for quickly checking valid keys, which- while they may not reduce the complexity by much, knowing that they are in the ciphertext itself may help launch an attack.
You don't get it, do you? typechecking is always done statically at compile time, unless you use dynamic_cast; virtual overloading is not avoidable, if you want message passing. C++'s mentality is that you can avoid the cost of what you are not using; so if you don't need virtual methods, you don't use them. If you only need stack allocation, then you don't pay the cost of allocating everything on the heap.
That's a lie. C++ most certainly does do type-checking at run-time.
modern video games have incredibly tight loops,
No they don't. They have an event-pump and a timer. Tight loops are done in hardware these days.
multiple threads of execution,
Only to work around API problems. Threads make for slower execution because the cost of context switching is high (esp. on x86).
network I/O,
No they don't. That's the operating system. Usually it's kernel. On most systems, that's written in C. Note that NDIS is written in C.
controller I/O,
What controller are you talking about?
real-time file I/O (if they are using disk spooling),
Ah, no. Real-time doesn't mean what you think it means. Furthermore, Windows doesn't have any Real-time File I/O interfaces. Nor should it, it's not a real-time operating system.
It supports asynchronous I/O operations, but then, the AIO interface is written in C.
Realtime does not mean "fast".
fully fledged guis (especially PRGs),
Ah no. GDI is written in C. GTK/GNOME is written in C. These things do not require C++.
The Unreal engine alone is over 1 million lines of code.
So what? Do you have the source code? Is it really all C++? What about the code for the GPUs actually drawing things? You know, the parts that have "tight loops"?
but there has never been a conclusive benchmark that proves it. Especially the 'much' faster part.
C is not more deterministic than C++. For the tasks C++ does, C would have to implement them at least in the same way, albeit with much uglier syntax.
But that syntax is explicit.
Take message passing,
C++ doesn't support message passing. Objective-C does.
you can't get faster than vtables.
Ah no. A perfect hash will always beat vtables.
The only difference is that C++ does it in a better way, whereas in C it is more difficult and error-prone.
No, that's wrong. What does if (a << b) do? What code does it evaluate? Do you know?
C++ hides these things, ergo, without knowing what a is, and having it's source code, you cannot tell what the C++ is doing.
I am still waiting for the benchmark that proves that. Guess what? there is not such a beast. Even if the Java hotspot compiler can optimize a series of instructions better on a specific machine, overall Java has enough 'hotspots' to make it slower, overall, than C++.
Here's one you can try at home: Compile this program:
#include <stdio.h>
int main(int argc, char *argv[]) {
puts("Hello World!");
}
Compiled with gcc, this produces a file 4695 bytes long. Compiled with g++, this produces a file 5104 bytes long. To make sure this actually changes the code, main() starts at 0x8048384 and ends at 0x80483ab in C++, but only runs from 0x8048434 and ends at 0x804845f. Clearly, that dynamic type checking you were talking about, not only exists, but has a cost.
I have never seen a benchmark proving Haskell faster than C++. When Haskell can sort 100,000 records in a database as quickly a
In C++, you don't have to pay for what you don't use.... but how can you blame C++, the language, because one vendor screwed it up?
This sounds like Bjarne's FGA on the subject. The fact is that there is no perfect C++ compiler- Typechecking, virtual overloading, and so on, all come with a cost. But consider this, nonbeliever: If you avoid every C++ feature, how is it you're programming in C++?
You have no idea about modern game development, do you? Writing a modern video game is way more difficult than any other kind of application.
I doubt that. Do you have any facts to back that up?
No. You can't rely on Java, because video games are real time applications, and garbage collection does not play nicely. In Java, you pay for what you don't use.
Beware, "real time" means something very different to computer scientists than you're presently using it to mean. Java most certainly can deliver realtime performance- that is, deliver results within a hard and fixed time limit. Nearly all languages can be architectured in this manner.
But you still have collision detection, AI, the various game scripts, game input, driving sound, real-time hard disk loading, network communications, etc. And you have to drive OpenGL and DirectX, and all those data going in out of these libraries are certainly faster to pump using C++ rather than Java.
Again you use the term real-time, and I don't think it means what you think it means. Most video games are not realtime applications. They aren't, because they don't need to be. Not these days. Most hard disks and controllers don't deliver realtime results, and won't unless you do things like disable the cache, and use a realtime operating system- things that generally make the game slower, not faster.
But next time, if you ever decide to find out what it is you're talking about, I'll still be here.
You may as well reject it as much as you like, but you can't shadow the fact that C++ is one of the most successful programming languages around. And don't say anything about how other languages are much better, 'cause I can give you a million reasons why they are not (in many cases the reasons are not about the language, though).
Read the fucking message. "Better" is such an extremely subjective term that you're a goddamned illiterate retard if you have no idea what I'm talking about: If I have to write a program to process a logfile, and I'm only going to use it once, what fucking use is C++ going to be besides slow me down?
Perl, Awk, and Sed would all be excellent candidates for this. You want to cry about the fact that your favorite programming language sucks at something? Or do you really want to say that C++ is best at building video games because it's fast?
Guess what: Other languages are much faster. Some are faster because they're more deterministic (C), others are faster because compilers are simply more mature (Java). Others still are faster because they can cheat and solve the problem completely differently (Haskell, P/LISP).
Maybe it's because C++ is pervasive that it's good, maybe it's because C++ is as flexible as people keep pointing out that it's pervasive- after all, newcommers to computer science frequently only learn one or two languages, and I don't suggest for a minute that C++ probably isn't one of them.
But if you got this far, you've still missed the underlying philisophical problem with this: That C++ is "best at being known", instead of actually being the best tool for any particular given job.
I'll agree, unless someone can give me an example of what C++ is best suited for. I've tried every language that I can find at least twice, and I can't find anything that C++ is the best at, or even a reasonable middle-ground.
So you're a jack of all trades, but master of none?
Well, my objective is to get the project done. I've noticed that the actual language proficiency is probably the smallest barrier in a big project. Usually, it's the engineering of the project itself- something that isn't exactly language dependant.
Consider, if I have a (small) project to collect a path a set of users took through an Apache logfile, I would use a combination of sed, awk, grep, join, and bourne-shell. Would a C++ "master" really resort to C++ for such a one-time task?
Consider a different project- a temperature sensor that I want to embed into the Linux kernel. My choice for this would be C, and probably do prototyped readouts in perl. Would a C++ "master" really build a bounce layer to do as much as possible in C++?
I think that tasks demand the best tool for the job. I find it hard to believe that C++- as pervasive as it is, isn't the best tool for any job, so I solicit that query: What task is C++ the best at solving? When is C++ the right-shaped hammer?
C++ is like chess, something you can pickup relatively quickly, yet takes years to master. It's a language with extraordinary power because it's so full of features. Just because it has support for all sorts of things doesn't mean you have to use them. (Eg friggin' exceptions) It doesn't wrap you in cotton wool and shield you from the harsh reality of how computers actually work, so you get the power to do whatever you want with fast execution speed.
I can accept your statement here. It's very similar to Bjarne's statements on C++. Note that I really only have two concerns here:
1. why call it C++ if it's nothing like C? 2. what kind of applied problems solving, does C++ solve best?
I think the general consensus on #1 is to trick people into learning C++ so that they'd think they were learning C at the same time.
But nobody has come up with a single thing for #2. The closest was a sibling post to yours that suggests that because C++ is pervasive, it's good at solving problems created by its pervasiveness, which is really quite unfair, IMO.
Despite those things, I do have certain disinterests in C++: namely that it does "wrap you in cotton wool and shield you from the harsh reality of how computers really work" -- not so much as that, but it does hide the true cost of certain operations. As a result, it's performance is often quite overstated.
This doesn't affect me or most people so much because optimization is quite overstated, but in writing secure software, one needs to be able to audit every step of the code to make sure it's operating exactly as expected. However, because C++ hides the actual operations so frequently, auditing C++ is several orders of magnitude more complicated to audit than say, plain C.
Read some other parts of this thread- particularly the part of how to correctly write to a file in a crashproof manner. I annotate briefly what's necessary to do it in C, and describe (briefly) how to do it in C++ and why it's so much more complicated there.
-writing large pieces of software without sacrifizing even the slightest bit of performance.
That's not true at all. Behind-the-back memory allocations, vtable lookups, stack unwinding, and overloading all serve to hide the true cost of an otherwise seemingly innocuous operation:
x = x * 2;
If, this is using HP's vector classes, instead of the GNU vector classes, this runs at about 1/50th the speed (because it isn't taking advantage of the vector enhancements in GCC).
Nonetheless, if you were to use GCC's builtin vector extensions (instead of class-wrapped ones), you could have saved yourself the template unwinds and the typechecking done on x.
I'm not saying here that C++ is slow- I'm merely saying that you most certainly are sacrificing performance by writing in C++. Nothing is free.
It is no coincidence that video games are written in C++. The Unreal 3.0 engine is more than 1 million lines of C++ code.
Does that mean C++ is the best at making video games?
It may be so- after all, video games need a larger number of mediocre pogrammers (to assist the head developers) than a lot of other projects. Given C++'s pervasiveness this might be why C++ is used.
But if it is so, if (say) Java were more pervasive, then these games would be written in Java.
As a point on this: Most of a game isn't processor intensive, or even computationally expensive. Those operations are reserved to a small number of tightly optimized inner loops. With the general acceptance of OpenGL or DirectX, and dedicated physics processing systems, those loops no longer live inside the program, so people generally don't see them anymore. They most certainly, are not written in C++, and without them, you'd have a chunk of your code written in highly ordered C or assembly. Consider DOOM- largely written in C++, but not the fast bits!
So I reject this: Whatever language is "best" is because it's already the greatest common factor in a development group, because that doesn't really mean "best", it means "minimum acceptable".
Lots of good points, but one thing really stood out for me. You really shouldn't be wrapping statements in ifs to check for errors in C++, you should be using try/catch blocks. The exception system alone makes C++ much more comfortable for me than C.
Lots of languages have exceptions, and lots of them have it better than C++: Consider Java which explicitly names which exceptions can be thrown. As a result, it's a compile-time error if you don't catch the appropriate exceptions.
In any event, under C++, exceptions come at a dangerous price: Memory allocations may not get freed as a result of a misused pointer.
Maybe good habits help this, but good habits also help error handling in C. Here's an example:
... char *tmpf=0; do { free(tmpf); tmpf=generate_random_filename(); if ((fd=open(tmpf,O_CREAT|O_EXCL|O_RDWR))>-1)break; } while(fd==-1&&errno==EEXIST); if (fd==-1) goto FAIL; if (write(fd,...)==-1)goto FAIL; if (write(fd,...)==-1)goto FAIL; if (fsync(fd)==-1)goto FAIL; if (close(fd)==-1)goto FAIL; if (rename(tmpf,targetf)==-1)goto FAIL; return 0;/*success*/ FAIL: unlink(tmpf); (void)close(fd); free(tmpf); return -1; }
This is crashproof in POSIX.1. Whether you do this in C or Python, all these contortions are required.
So substitute write for <<, and fsync for fstream.sync(), and to perform the requisite error checking, you've needed a mix of exceptions and if checking (fstream.sync doesn't throw an exception!). Of course, you can't check fstream.close()'s error- you need to check the failbit after calling fstream.close().
The result is three different methods of error checking. It may be helpful to note that I don't look at this example as error checking in C, but really as state-tracking. I include it here because it's a good example of how terribly unlike C++ is than C, because I do it a lot, and because the C++ solution is far from obvious. I think we can agree that if C++ is the best at something, error recovery isn't it.
And regarding your complaints about overloading: yes, it's possible to write bad, confusing code in any language. I really don't think it's fair to hold that against it.
Perl supports overloading, but it's much less confusing because perl doesn't consider const-ness, readonly-ness, or signed-ness as part of the data type. As a result, the "wrong function" doesn't get called.
I never thought I'd be saying perl was less confusing than C++, but there you have it:)
Ad Hominum, and that's two. Are we sure we can actually program?
My biggest complaint about C++ is the lack of standardization for name-mangling and and v-table construction. The rest I can choose to ignore.
How big of you.
My biggest complaint about C++ is that it calls itself C++, instead of "NotAtAllCLike" or "CompletelyIncompatibleWithC" or something that at least displays knowledge of C instead of arrogance for ones own creation.
This confuses New Programmers into thinking C++ is somehow an improved (in any way) version of C, or that it will someday replace it and so, time is better spent not learning C.
It also confuses Real Programmers, because they want to know why they cannot apply good C algorithms and programming skills to C++ programs.
Let me try my hand at an answer for you, altwough we're "a bit" offtopic here:).
Agreed, but it is fun:)
C++ also fixes (or offers alternatives to) a lot of problems unresolved in C like namespaces,
It seems to me that because there's no body that gives out namespaces (like SUN turning com, net, and org over to ICANN), and no way to resolve namespaces (as in python's "as" qualifier), I'd say C++ namespaces aren't any better than C's namespaces at all.
extensible IO library,
Now I'll admit, *stream does look like a lot of fun to use, but see below... I want to get the rest of this paragraph first:)
a typesafe alternative to C macros,
I question the usefulness of type-safety, because a lot of C++ code attempts to allow for automatic type-coercion. This means that the programmer needs to know (or as it seems more likely: guess) what kind of coercion will take place if trying one of these template functions on two different types.
extensible type system.
If you are talking about operator overloading, see below.
All of these can be easily abused (so one could argue that it only adds complications) but that's more of a matter of writing good code than a C++ problem.
It seems that adding more facilities with no clear direction for their use contributes to the abuse. I'd say that's as much C++'s problem as anything else.
The four casts state intent much better than the C cast; It's also easier to grep/search through the code to locate casts.
Thank you for this. I've heard a million different answers that all sound retarded. Saying that the four casts are simply annotations instead of actual code direction makes them make a lot more sense.
I'm completely lost as to why it's a good idea making: if (a << 1) mean anything but to check if anything but the highest bit is set, or a[0] mean anything different than *a.
iostreams are a decent answer for the first example (B. Stroustrup explained in his book why the shift operator was chosen and it seemed like a good enough reason for me).
but people don't write that. They write a << 1; without checking for errors, and so on. iostream's use of the << doesn't encourage error checking, and as a result, is a bad thing.
If that's not enough reason, consider: why is it you when you saw if (a<<1), you immediately thought ostream? Maybe the next line made it clear I meant bitshift, but seriously, any C++ class in the world could've overloaded << to mean anything, so the language can completely polymorph based on the class(ification) of a variable.
That leads to some seriously incomprehensible crap when the classification is known only as "T".
I think the only reason not to see these is coming to C++ with a C/other language mind-frame and saying "I can progam C just fine in C; why would I do it in C++"?
Exactly. So because C++ was here first, why don't we call it something else? It's clearly nothing like C, so why is it so important to confuse old C programmers like myself otherwise. This only brings confusion and animosity...
Static functions allowing access to global resources? Used like this, the pointers are allocated upon first access and deallocated in reverse order.
That's what I thought, but that's not the case. Consider accessing cout<< in a constructor of a object that's instanced before libstdc++.
Actually I think C++ bent over backwards to remain (mostly) compatible with C (this is why the macros-as-functions were not completely eliminated for example).
but if anyone comes up with an example of what C++ is best at...
Pissing off academic language purists?
And for my next trick, note that C is more widely recognized and used than any other programming language, C is found in the kernels of nearly all modern operating systems, the display interface now known as Xorg, and pervasively throughout GNOME the Desktop.
Actually on the topic of C++... I think a petition for banning C++ forever is a much better idea.
I'll agree, unless someone can give me an example of what C++ is best suited for. I've tried every language that I can find at least twice, and I can't find anything that C++ is the best at, or even a reasonable middle-ground.
C is much easier to read, and if I want objects, Objective-C allows me to reuse my C code. At least then, I get an object oriented language. C++ is some weird class and template based language, that requires I either taxonimize everything, or degenerate into a slower and hard to read C.
I'm still unclear why we need four different casts, and I'm still unclear why it's a good idea to have two functions with the same name and data types (save the const or signed keywords, which aren't really supposed to modify the data type)- lest the evil C++ genies make my code call the wrong one.
I'm completely lost as to why it's a good idea making: if (a << 1) mean anything but to check if anything but the highest bit is set, or a[0] mean anything different than *a.
I can't figure out exactly how to control deallocation order when calling destructors during stack unwinds, and I can't figure out how to control allocation order before main().
I don't know why C++ insisted on being completely forwards and backwards incompatible with C, and adopt its name. It isn't a better C, it isn't even a logical extension of C.
I might be able to wrap my head around C++ better if I didn't know C, and expect C semantics, but damnit, that's awful hard to do when it's called C++.
So right now, I'll sign your petition, but if anyone comes up with an example of what C++ is best at, I'll have to retract my signature and simply sign the petition that demands C++ be called (!C)<C.
The only thing in a Postfix spool writable by other than the Postfix user is the maildrop queue, which is group-writable and owned by the group that postdrop is setgid to. So, whatever problems it may have had in the past that way, they've clearly been fixed.
``No Postfix program is set-uid. Introducing the concept was the biggest mistake made in UNIX history. Set-uid (and its weaker cousin, set-gid) causes more trouble than it is worth.'' -Wietse Venema
This just demonstrates my point- Wietse used to think, like parent thinks (and as I assume you think, by defending him), that a function q is bad, and it must never be used.
I think, and I hope Wietse now thinks (I'm taking your word on it now- he made quite a stink about this vulnerability, and TMK, never actually acknoledged its seriousness, or his wrong-edness), that it's the programmer that is stupid.
Since the programmer is stupid, the programmer must use those few bouts of lucidity where he/she is aware of this to insulate themselves from their own stupidity.... which is of course, exactly what insecure and buggy programs are: the stupidity of the programmer. Perpetuating this myth that insecure and buggy programs are somehow the fault of the language, or some set of unsafe library functions, is a good way to hide the stupidness of all programmers: It lets Microsoft pretend they're making security important, and it lets Wietse think he's unstoppable, and maybe, these things confuse the users of these software.
Unfortunately, that just makes another myth all the easier to spread: That it isn't possible to resist attacks from evildoers, and that security can never be absolute so why bother/cry about it.
In your trivial example, it's easy enough to see it's harmless, true. It's still bad practice. What is the compelling reason to use an unsafe function? To save a few characters?
Yes, it is important to know why strcpy should not be used. And then you should never use it, even when it's "safe", because it's a bad habit. Humans are much more habitual than logical, even programmers. Especially programmers at 2am after they've been on a caffiene-induced all-night coding session.
I disagree with this- that somehow just enough good habits would solve all the security problems. It's plainly not true.
Instead, I find it much better to get yourself in the habit of knowing you're going to fuck it all up sooner or later and make sure that when you fuck things up, you still haven't created a security hole.
Believe it or not, this is much easier than memorizing which system calls are reentrant, and therefore safe to use in a signal handler, or whether mkdir("/") returns EISDIR or EEXIST. By admitting you are at least at one point, going to be completely incompetant (probably at 2am), you can engineer a better design.
Love it or hate it, every person who mutters about setuid, strcpy or gets should have to read the qmail source code, beginning to end. It's an excellent design that should be used as a model for how to write secure software: by partioning the risky bits away such that you can audit them completely.
As long as people keep this function q is dangerous attitude, they're going to make the big mistakes- the design mistakes that aren't really fixable: Like postfix using a world-writable queue directory and the restriction that "important files can't look like postfix queue entries", or why window messages on Win32 automatically mean the window owner is succeptable to a buffer overrun.
But what about the precursor to html and http; Gopher?
Actually, gopher is younger than HTTP, and directly competed with it. Gopher advocates (and still do) suggest that automatic linking, reasonable automatic spidering, and a dead-simple protocol, make Gopher still better than HTTP.
To me the addition of pictures to this type of system only made it easier to find the porn! Searching FTP for porn was just too hard!!!
That's because porn was almost never on FTP. Pre-WWW porn was found on USENET.
+5 Insightful? I agree that GUI programming in C is a pain (and I speak from past experience on this), but GGP was simply asking a question. How come just because you don't want to do GUI programming in C means that someone else shouldn't be allowed to?
Actually, no, I really was just being a dick.:)
Because QT is written in a fictional programming language (called MOC) - something that makes it different from almost every other toolkit or GUI out there, it's very hard to take it seriously. Think about it: Rather than use a language that is actually good at object-oriented and event-driven programming, (like Python, or Objective-C, or Java), they chose to hang on the popularity bandwagon- they targetted C++ users for the sake of targetting popularity.
That mindset is extremely frustrating: I like to use the best tool for the job, and I've never found a job where C++ was the best tool for technical reasons- only ever because ``that's what the rest of the team is used to/trained with/proficient at'', and I'm sorry, that's a mind-blowingly stupid reason to keep those illiterate programmers around.
Targetting C (or even Objective-C) means that the toolkit or GUI actually has a real interface for programming and interoperability, and not some gross kind of preprocessor or glue code...
+3 Insightful? I'm guessing the ones who modded that aren't programmers.
Fortunately the C++ fanboys swooped in to -1 me.
GUI programming in C is a *pain*, it's awful beyond words.
Maybe you need practice. Much of GNOME is written in C. My own schism tracker is written in C. I don't know what you find intolorable about C, but Java programmers are the erotic furries of programming, and C++ programmers seem to be completely oblivious as to what's wrong with their favorite language.
I hate GUI programming,
Probably because you're not any good at it.
but python + qt (pyqt) actually works very well for that,
You are completely detached from reality, aren't you?
Qt with C++ requires that awful moc, but at least it's survivable.
Never mind that MOC isn't C++. It's a completely different (and incompatible) language designed to make up for an enormous deficiancy in C++. The fact that the QT people chose C++ for it's popularity instead of it being "a good language" should tell you something.
If the parent knew anything about Qt and C, he wouldn't have suggested it at all.
Post hoc...
For the record, yes, I have done Qt programming with C++ and python, a lot of C coding (for about 10 years), so I'm familiar with all the different aspects in this, unlike, obviously, the parent.
So you've been wasting your time because you're still a mediocre programmer living in a fantasy world. And we're supposed to take your word at it? I'm not suggesting anyone take my word for anything- I can or do back up everything I have to say on any subject, including the one about you being nearly incompetent.
Consider for a moment that GNOME is a very large, very complicated, and very strongly backed interface, set of guidelines, libraries, applications, and a desktop. Now consider that the gross majority of it is written in C. Presume all you will about my professional history, are you really saying that you're smarter than everyone at SUN, IBM, Novell, Red Hat, and all the people who have made GNOME what it is today?
QT is a piece of shit. It's a terrible user interface that has had to be completely reinvented incompatibly four times in a language with perhaps the smallest imaginable user base, and by singing its praises, you expect to be taken seriously?
On the off chance I'm completely wrong about you, take a twenty minute tour of Objective-C, Xcode, and Interface Builder, and then tell me that you still want to bear QT's children.
If the [P]olice do something wrong, they should be [P]unished just like the rest of us!
No! They should be punished far worse than the rest of us. They want the courts to "trust" their discression more than they trust criminals, so they must be more trustworthy than the criminals.
If a cop gets a misdemeanor, break his legs. If a cop commits a felony, hang him.
Slashdot Mirror
Are you kidding?
Read the rest of my post. It most certainly crashes in places it did not before. Refusing to compile/run, means it acts differently. Either metric you chose, you're still wrong.
Then according to Bjarne, MSVC 8.0 isn't a C compiler. Regarding MingW32, I have no idea what you did wrong. Perhaps mingw was setup to emulate MSVC for compatability purposes.
Then MSVC isn't a C compiler. Have a good day. GCC compiles hapily.
But these are changes! How can something be a superset if it requires changes to be compatible?
I accept Objective-C as a superset as it doesn't require changes. There is no extern "C" in objective-C, there is no new casts, all C code is valid Objective-C code.
If you REALLY THINK C++ is a superset of C go ahead and compile something big like the Linux kernel with a C++ compiler and see how far you get.
It's not the same thing. You cannot allocate multiple objects out of a static pool in C++ and still get initialization. All of your constructors would need to shadow their allocations against the static buffer, which means uglier code.
So let me get this straight. You'd rather not know C or C++, just so I don't know Winsock?
I wasn't going to argue with you on it because this wasn't my point, and it wasn't your point. Your point is that C is a subset of C++, so I wanted to focus on those elements. But if you insist: Winsock most certainly responds to ioctlsocket(h,FIONBIO,...). Yes Virginia, you most certainly are wrong.
Boo hoo. You said you had never seen a benchmark demonstrating Java as being faster than C++ at some things. You never said a valid one, nor gave a criteria of what a valid one would look like.
Why? Because you say so without justification?
Fine. I accept that you're wrong.
Can be considered a subset by you, a person who admittedly "doesn't know C all that well."
Besides, Bjarne disagrees with you.
Oh, and before you bring it up, my favorite part about that link is how he lies three times in the same answer:
``However, C++ supports every programming technique supported by C.''
-- As I've established, not true. C++ cannot mak
Or maybe you didn't understand it.
Eiter way, the original quote is:
Now, those "non-free softwares" that you buy that are a win for you- are they non-free softwares that Microsoft directly competes with?
Because if not, you're arguing apples to oranges. I said if Microsoft decides to compete with non-free software, Microsoft will probably win, and the customers will lose. I say this because in the past, Microsoft competes with non-free software and wins. And where they win, the customers lose. Ask anyone who has "upgraded" from a now defunct company to Microsoft Great Plains to get a good handle on what I'm talking about.
Fair enough.
GCC can also compile ADA. The Visual line can also compile J++, VB[6], VBA, and JScript.
If we're talking about overlap, however, OBJC overlaps very nicely with C, and OBJC++ overlaps C++- both being strict supersets of their pairs. That means there's really two less "real" parsers and gode generators, in GCC.
It doesn't really matter though. What does matter is that there's never going to be another Turbo-C simply because it'll either have to do more than GCC does, or be Free Software.
Oh, but it's so much more useful than that.
Microsoft has the development resources to compete with GCC and Linux. A lot of people forget that if you ever produce a valuable piece of software, Microsoft can, and may compete with you. Unless you're built on Free Software, Microsoft will probably win. And unless you're built on Free Software, your customers will definately lose.
You say this alot, but if the program refuses to compile, or compiles but crashes in new and exciting ways, you're wrong.
sizeof('a') == sizeof(int) in C. Code compiles, but acts differently, and as a result: You're wrong.
Verify just how wrong you are if you like:
#include <stdio.h>
int main(int argc, char *argv[]) { printf("%d\n",sizeof('a')); }
Prints "1" when compiled with g++, and prints "4" when compiled with gcc (on my system).
Watch this program compile in any C compiler:
int i;
int i=5;
Look, you're wrong again!
Watch this program compile in any C compiler:
struct foo { struct bar { int x }; }; struct bar y;
Look, you're wrong again!
Here, they'll compile on many systems, but they'll crash! You either have to compile all the code with C++ (including the bits that you only have binary-only blobs for), or edit the source.
And you implied that you know C, you don't.
You might know C++, but since you don't know C, you're left with only two options: (a) You don't know C++ either, or (b) C++ isn't a superset of C. I'd hope it were easier for you to believe the latter, because it's much easier to not know something you don't use every day.
Unfortunately, mathematicians and computer scientists aren't allowed to coopt definitions just because they feel like it. I rejected your wider sense because you haven't given me any reason to believe your definition is more useful than the ones I suggested, i.e. "quickly" or "interactively".
Reality is demonstrated.
You don't know C.
Visual Basic.
More so. I frequently use a big char[] or double[] buf, and allocate smaller chunks out of it. By using .bss in this way, I get a speed boost on startup (something very useful on UNIX) because the pages my program needs are already available, and my program never has to call brk()
But since allocation is performed by the object (especially in RAII), this performance-boosting method is completely unavailable when using C++.
Err, unless your machine code is in a char*, that's assembly, and C++ has nothing to do with it. In any event, C is easier in this situation because objdump doesn't have to deal with demangling names.
I disagree with your assertion, and this is probably why we're arguing in the first place. Languages are tools. I restrict my C programming to security barriers- where I have to write code that I, and others on my team must audit. 100% secure is what we need. I
In order for a software company to enter the photo-manipulation business, they need to produce something better than the Gimp- not better than Photoshop. Whether Gimp is better or worse than Photoshop doesn't matter- the Gimp is available freely (both in the capital Free and the lowercase free sense), so there is no room for a 5$ photo-editor unless it's 5$-better than the Gimp.
Microsoft's Visual line of development support more languages than GCC (while there's some overlap, there are different languages here). What's really good about GCC is that because someone found it valuable for GCC to target architecture foo, GCC targets architecture foo. In order for Microsoft's Visual C to target architecture foo, Microsoft would have to find it valuable.
And that's what makes Free Software so much better than proprietary software. Someone needed 48-bit floating-point per-component editing at extremely high resolutions, and so someone could extend the Gimp to do so (and has!). Without the Gimp, that feature would have to be important to Adobe. Who knows, maybe it is now (I stopped tracking Photoshop a long time ago).
And I said you don't get anything for free. "Not noticable" sounds highly suggestive.
Someone needs to tell that O_NONBLOCK then. BSD sockets support nonblocking just like every other fd.
Close: Message passing requires that there not be knowledge of the target. If you take away forwarding and the ability to handle unknown messages, it's no longer message passing. vtables can't do either, ergo, vtables are not message passing.
java.lang.reflection says you're wrong.
I don't disagree that MOC compiles to C++, I'm saying that MOC works around problems with C++ and so therefore cannot be counted as C++.
The fact that many C++ programmers don't know the difference is discouraging.
MOC adds message passing to C++. You may treat it as a "fraking preprocessor", but since the input looks like a normal method, and the output is a much more costly hashtable lookup, and two method calls, I call it hiding complexity.
Fortunately, that MOC does add those two objective-C features that C++ lacks: the ability to dynamically create and send messages, and the ability to receive and handle unknown messages.
Check again. That's not a vtable lookup, that's an indirect function call you're thinking of. Vtable lookup is used solely for virtual method dispatch- i.e. the caller knows that the method is supported, but doesn't know where the implementation is.
So you're telling me that when you see: a++ you immediately think oh shit, there's yet another line that can generate an exception, open/write to a file, etc? How can C++ ever be audited if you have to check every single operation that occurs.
Operator overloading is dangerous voodoo that makes any language supporting it, unsuitable for secure or bulletproof programs.
No it's not. C++ is syntacitically similar to, but largely incompatible with C. int new; is completely valid C, but completely invalid C++.
No I didn't. This is about what is a language best at. If the best databases aren't written in C++, then what does it matter if there exists a database that is written in C++?
For what it's worth, the actual storage operations in Oracle happen to be written in C.
No I'm not. C++ treats a (void*) cast very differently than C treats it- I have to explicitly label all void* cast types before and after C++ use. C++ can't call C symbols unless they are surrounded with extern "C" { ... }. C++ has a large number of reserved words that aren't reserved in C. C++ assumes all struct{}s are also typedef'd into
Consider that the dangerous bacteria and viruses you're talking about, would only have a single organism to target, and we'd run the risk of a single lucky virus taking out the world's entire meat supply.
Unless of course, they are right, and there is no evolution- and every organism is the same as it was when the planet was summoned into existence over the course of a particularly shady six day run. In which case, we have nothing to fear, because new viruses are not mutating into existance, and we only need to protect this meat from the dangers that exist right now and just wait until all the mad-cow viruses go extinct.
I'm not sure I want to live in either world, so excuse me while I go take a chew on this helpless animal here.
Wrong. Context switching on x86-based systems is about a hundread times more expensive than a PUSHALL/JMP operation.
No they don't. They use the BSD socket API (or a derivative) where the actual network communication occurs in kernel-space, a block of code, written in C.
The highest-throughput network applications are not written in C++. Consider the Net100 and the Web100 projects for details.
These are examples of extremely low bandwidth devices. On x86 systems, they generate interrupts- and do not have to be polled. As a result, they aren't "realtime" on any system.
Stop using realtime to mean something other than what it is. It's not hard-realtime, it's not soft-realtime.
No it isn't. It's a vtable lookup. Message passing is about the receiver knowing what to do with the message, whereas vtables require the function calling the virtual method know which methods are available (at least to the base class).
Consider Java or Objective-C message forwarding, or mach primitives to know what message passing is.
Did I say you couldn't find an example of something written in C++? You can find entire operating systems written in Oberon. That doesn't mean that it's the "best" at it, or even particularly "well suited".
Nevertheless, QT is not written in C++. It's written in MOC because C++ doesn't (or at least G++ didn't implement at the time) have a message passing facility.
That's what I'm talking about. You think you get something for free. Use objdump to see what a vtable lookup actually looks like in assembly. Compare to the movl/addl/movl[] operation that a perfect hash can (usually) use.
It calls a routine called "form.show". It may or may not block. If I'm debugging code near a form.show() routine, I know to look at or near the source to the show() routine. If I see a line that says if (a<<b) I'd either have the choice of guessing that meant they're checking if the lower (32-b) bits of a are clear, or I'd have to check every single line of code in C++, hopefully with some really awesome crossreferencing tools.
I don't trust any human being to audit C++ in that manner: but at least with C, you know exactly where control can be transferred and where it cannot.
Also note: Java doesn't support overloading operators.
You've already contradicted yourself. You said you had never seen any benchmark.
I never said that. I just said I never want to use the wrong tool. I never said I never use the wrong tool.
Bjarne is a second-rate programmer with a first-rate ego. At least, even He admits that C++ isn't best at anything, but good at lots of things (see his point in FAQ on "multi-paradigm")
The cipher may form a group, where a single 64-bit key will decode the double-encrypted ciphertext to the original plaintext, so instead of having one key twice, you really have two keys that will decrypt.
The implementation may leak information about encrypted data- lots of "pluggable" crypto systems leave a header that describes what cipher, keylength, and perhaps a magic string used for quickly checking valid keys, which- while they may not reduce the complexity by much, knowing that they are in the ciphertext itself may help launch an attack.
That's a lie. C++ most certainly does do type-checking at run-time.
No they don't. They have an event-pump and a timer. Tight loops are done in hardware these days.
Only to work around API problems. Threads make for slower execution because the cost of context switching is high (esp. on x86).
No they don't. That's the operating system. Usually it's kernel. On most systems, that's written in C. Note that NDIS is written in C.
What controller are you talking about?
Ah, no. Real-time doesn't mean what you think it means. Furthermore, Windows doesn't have any Real-time File I/O interfaces. Nor should it, it's not a real-time operating system.
It supports asynchronous I/O operations, but then, the AIO interface is written in C.
Realtime does not mean "fast".
Ah no. GDI is written in C. GTK/GNOME is written in C. These things do not require C++.
So what? Do you have the source code? Is it really all C++? What about the code for the GPUs actually drawing things? You know, the parts that have "tight loops"?
Here you go.
But that syntax is explicit.
C++ doesn't support message passing. Objective-C does.
Ah no. A perfect hash will always beat vtables.
No, that's wrong. What does if (a << b) do? What code does it evaluate? Do you know?
C++ hides these things, ergo, without knowing what a is, and having it's source code, you cannot tell what the C++ is doing.
Here's one you can try at home: Compile this program:
#include <stdio.h>
int main(int argc, char *argv[]) {
puts("Hello World!");
}
Compiled with gcc, this produces a file 4695 bytes long. Compiled with g++, this produces a file 5104 bytes long. To make sure this actually changes the code, main() starts at 0x8048384 and ends at 0x80483ab in C++, but only runs from 0x8048434 and ends at 0x804845f. Clearly, that dynamic type checking you were talking about, not only exists, but has a cost.
I doubt that. Do you have any facts to back that up?
Beware, "real time" means something very different to computer scientists than you're presently using it to mean. Java most certainly can deliver realtime performance- that is, deliver results within a hard and fixed time limit. Nearly all languages can be architectured in this manner.
Again you use the term real-time, and I don't think it means what you think it means. Most video games are not realtime applications. They aren't, because they don't need to be. Not these days. Most hard disks and controllers don't deliver realtime results, and won't unless you do things like disable the cache, and use a realtime operating system- things that generally make the game slower, not faster.
But next time, if you ever decide to find out what it is you're talking about, I'll still be here.
Read the fucking message. "Better" is such an extremely subjective term that you're a goddamned illiterate retard if you have no idea what I'm talking about: If I have to write a program to process a logfile, and I'm only going to use it once, what fucking use is C++ going to be besides slow me down?
Perl, Awk, and Sed would all be excellent candidates for this. You want to cry about the fact that your favorite programming language sucks at something? Or do you really want to say that C++ is best at building video games because it's fast?
Guess what: Other languages are much faster. Some are faster because they're more deterministic (C), others are faster because compilers are simply more mature (Java). Others still are faster because they can cheat and solve the problem completely differently (Haskell, P/LISP).
Maybe it's because C++ is pervasive that it's good, maybe it's because C++ is as flexible as people keep pointing out that it's pervasive- after all, newcommers to computer science frequently only learn one or two languages, and I don't suggest for a minute that C++ probably isn't one of them.
But if you got this far, you've still missed the underlying philisophical problem with this: That C++ is "best at being known", instead of actually being the best tool for any particular given job.
Consider, if I have a (small) project to collect a path a set of users took through an Apache logfile, I would use a combination of sed, awk, grep, join, and bourne-shell. Would a C++ "master" really resort to C++ for such a one-time task?
Consider a different project- a temperature sensor that I want to embed into the Linux kernel. My choice for this would be C, and probably do prototyped readouts in perl. Would a C++ "master" really build a bounce layer to do as much as possible in C++?
I think that tasks demand the best tool for the job. I find it hard to believe that C++- as pervasive as it is, isn't the best tool for any job, so I solicit that query: What task is C++ the best at solving? When is C++ the right-shaped hammer?
I can accept your statement here. It's very similar to Bjarne's statements on C++. Note that I really only have two concerns here:
1. why call it C++ if it's nothing like C?
2. what kind of applied problems solving, does C++ solve best?
I think the general consensus on #1 is to trick people into learning C++ so that they'd think they were learning C at the same time.
But nobody has come up with a single thing for #2. The closest was a sibling post to yours that suggests that because C++ is pervasive, it's good at solving problems created by its pervasiveness, which is really quite unfair, IMO.
Despite those things, I do have certain disinterests in C++: namely that it does "wrap you in cotton wool and shield you from the harsh reality of how computers really work" -- not so much as that, but it does hide the true cost of certain operations. As a result, it's performance is often quite overstated.
This doesn't affect me or most people so much because optimization is quite overstated, but in writing secure software, one needs to be able to audit every step of the code to make sure it's operating exactly as expected. However, because C++ hides the actual operations so frequently, auditing C++ is several orders of magnitude more complicated to audit than say, plain C.
Read some other parts of this thread- particularly the part of how to correctly write to a file in a crashproof manner. I annotate briefly what's necessary to do it in C, and describe (briefly) how to do it in C++ and why it's so much more complicated there.
x = x * 2;
If, this is using HP's vector classes, instead of the GNU vector classes, this runs at about 1/50th the speed (because it isn't taking advantage of the vector enhancements in GCC).
Nonetheless, if you were to use GCC's builtin vector extensions (instead of class-wrapped ones), you could have saved yourself the template unwinds and the typechecking done on x.
I'm not saying here that C++ is slow- I'm merely saying that you most certainly are sacrificing performance by writing in C++. Nothing is free.
Does that mean C++ is the best at making video games?
It may be so- after all, video games need a larger number of mediocre pogrammers (to assist the head developers) than a lot of other projects. Given C++'s pervasiveness this might be why C++ is used.
But if it is so, if (say) Java were more pervasive, then these games would be written in Java.
As a point on this: Most of a game isn't processor intensive, or even computationally expensive. Those operations are reserved to a small number of tightly optimized inner loops. With the general acceptance of OpenGL or DirectX, and dedicated physics processing systems, those loops no longer live inside the program, so people generally don't see them anymore. They most certainly, are not written in C++, and without them, you'd have a chunk of your code written in highly ordered C or assembly. Consider DOOM- largely written in C++, but not the fast bits!
So I reject this: Whatever language is "best" is because it's already the greatest common factor in a development group, because that doesn't really mean "best", it means "minimum acceptable".
What about C++0x? :)
In any event, under C++, exceptions come at a dangerous price: Memory allocations may not get freed as a result of a misused pointer.
Maybe good habits help this, but good habits also help error handling in C. Here's an example:
char *tmpf=0;
do {
free(tmpf);
tmpf=generate_random_filename();
if ((fd=open(tmpf,O_CREAT|O_EXCL|O_RDWR))>-1)break;
} while(fd==-1&&errno==EEXIST);
if (fd==-1) goto FAIL;
if (write(fd,...)==-1)goto FAIL;
if (write(fd,...)==-1)goto FAIL;
if (fsync(fd)==-1)goto FAIL;
if (close(fd)==-1)goto FAIL;
if (rename(tmpf,targetf)==-1)goto FAIL;
return 0;/*success*/
FAIL:
unlink(tmpf);
(void)close(fd);
free(tmpf);
return -1;
}
This is crashproof in POSIX.1. Whether you do this in C or Python, all these contortions are required.
So substitute write for <<, and fsync for fstream.sync(), and to perform the requisite error checking, you've needed a mix of exceptions and if checking (fstream.sync doesn't throw an exception!). Of course, you can't check fstream.close()'s error- you need to check the failbit after calling fstream.close().
The result is three different methods of error checking. It may be helpful to note that I don't look at this example as error checking in C, but really as state-tracking. I include it here because it's a good example of how terribly unlike C++ is than C, because I do it a lot, and because the C++ solution is far from obvious. I think we can agree that if C++ is the best at something, error recovery isn't it.
Perl supports overloading, but it's much less confusing because perl doesn't consider const-ness, readonly-ness, or signed-ness as part of the data type. As a result, the "wrong function" doesn't get called.
I never thought I'd be saying perl was less confusing than C++, but there you have it
How big of you.
My biggest complaint about C++ is that it calls itself C++, instead of "NotAtAllCLike" or "CompletelyIncompatibleWithC" or something that at least displays knowledge of C instead of arrogance for ones own creation.
This confuses New Programmers into thinking C++ is somehow an improved (in any way) version of C, or that it will someday replace it and so, time is better spent not learning C.
It also confuses Real Programmers, because they want to know why they cannot apply good C algorithms and programming skills to C++ programs.
Agreed, but it is fun :)
It seems to me that because there's no body that gives out namespaces (like SUN turning com, net, and org over to ICANN), and no way to resolve namespaces (as in python's "as" qualifier), I'd say C++ namespaces aren't any better than C's namespaces at all.
Now I'll admit, *stream does look like a lot of fun to use, but see below... I want to get the rest of this paragraph first :)
I question the usefulness of type-safety, because a lot of C++ code attempts to allow for automatic type-coercion. This means that the programmer needs to know (or as it seems more likely: guess) what kind of coercion will take place if trying one of these template functions on two different types.
If you are talking about operator overloading, see below.
It seems that adding more facilities with no clear direction for their use contributes to the abuse. I'd say that's as much C++'s problem as anything else.
Thank you for this. I've heard a million different answers that all sound retarded. Saying that the four casts are simply annotations instead of actual code direction makes them make a lot more sense.
but people don't write that. They write a << 1; without checking for errors, and so on. iostream's use of the << doesn't encourage error checking, and as a result, is a bad thing.
If that's not enough reason, consider: why is it you when you saw if (a<<1), you immediately thought ostream? Maybe the next line made it clear I meant bitshift, but seriously, any C++ class in the world could've overloaded << to mean anything, so the language can completely polymorph based on the class(ification) of a variable.
That leads to some seriously incomprehensible crap when the classification is known only as "T".
Exactly. So because C++ was here first, why don't we call it something else? It's clearly nothing like C, so why is it so important to confuse old C programmers like myself otherwise. This only brings confusion and animosity...
That's what I thought, but that's not the case. Consider accessing cout<< in a constructor of a object that's instanced before libstdc++.
Now how exactly is C an academic language?
C is much easier to read, and if I want objects, Objective-C allows me to reuse my C code. At least then, I get an object oriented language. C++ is some weird class and template based language, that requires I either taxonimize everything, or degenerate into a slower and hard to read C.
I'm still unclear why we need four different casts, and I'm still unclear why it's a good idea to have two functions with the same name and data types (save the const or signed keywords, which aren't really supposed to modify the data type)- lest the evil C++ genies make my code call the wrong one.
I'm completely lost as to why it's a good idea making: if (a << 1) mean anything but to check if anything but the highest bit is set, or a[0] mean anything different than *a.
I can't figure out exactly how to control deallocation order when calling destructors during stack unwinds, and I can't figure out how to control allocation order before main().
I don't know why C++ insisted on being completely forwards and backwards incompatible with C, and adopt its name. It isn't a better C, it isn't even a logical extension of C.
I might be able to wrap my head around C++ better if I didn't know C, and expect C semantics, but damnit, that's awful hard to do when it's called C++.
So right now, I'll sign your petition, but if anyone comes up with an example of what C++ is best at, I'll have to retract my signature and simply sign the petition that demands C++ be called (!C)<C.
This just demonstrates my point- Wietse used to think, like parent thinks (and as I assume you think, by defending him), that a function q is bad, and it must never be used.
I think, and I hope Wietse now thinks (I'm taking your word on it now- he made quite a stink about this vulnerability, and TMK, never actually acknoledged its seriousness, or his wrong-edness), that it's the programmer that is stupid.
Since the programmer is stupid, the programmer must use those few bouts of lucidity where he/she is aware of this to insulate themselves from their own stupidity.
Unfortunately, that just makes another myth all the easier to spread: That it isn't possible to resist attacks from evildoers, and that security can never be absolute so why bother/cry about it.
Instead, I find it much better to get yourself in the habit of knowing you're going to fuck it all up sooner or later and make sure that when you fuck things up, you still haven't created a security hole.
Believe it or not, this is much easier than memorizing which system calls are reentrant, and therefore safe to use in a signal handler, or whether mkdir("/") returns EISDIR or EEXIST. By admitting you are at least at one point, going to be completely incompetant (probably at 2am), you can engineer a better design.
Love it or hate it, every person who mutters about setuid, strcpy or gets should have to read the qmail source code, beginning to end. It's an excellent design that should be used as a model for how to write secure software: by partioning the risky bits away such that you can audit them completely.
As long as people keep this function q is dangerous attitude, they're going to make the big mistakes- the design mistakes that aren't really fixable: Like postfix using a world-writable queue directory and the restriction that "important files can't look like postfix queue entries", or why window messages on Win32 automatically mean the window owner is succeptable to a buffer overrun.
That's because porn was almost never on FTP. Pre-WWW porn was found on USENET.
Because QT is written in a fictional programming language (called MOC) - something that makes it different from almost every other toolkit or GUI out there, it's very hard to take it seriously. Think about it: Rather than use a language that is actually good at object-oriented and event-driven programming, (like Python, or Objective-C, or Java), they chose to hang on the popularity bandwagon- they targetted C++ users for the sake of targetting popularity.
That mindset is extremely frustrating: I like to use the best tool for the job, and I've never found a job where C++ was the best tool for technical reasons- only ever because ``that's what the rest of the team is used to/trained with/proficient at'', and I'm sorry, that's a mind-blowingly stupid reason to keep those illiterate programmers around.
Targetting C (or even Objective-C) means that the toolkit or GUI actually has a real interface for programming and interoperability, and not some gross kind of preprocessor or glue code...
Maybe you need practice. Much of GNOME is written in C. My own schism tracker is written in C. I don't know what you find intolorable about C, but Java programmers are the erotic furries of programming, and C++ programmers seem to be completely oblivious as to what's wrong with their favorite language.
Probably because you're not any good at it.
You are completely detached from reality, aren't you?
Never mind that MOC isn't C++. It's a completely different (and incompatible) language designed to make up for an enormous deficiancy in C++. The fact that the QT people chose C++ for it's popularity instead of it being "a good language" should tell you something.
Post hoc...
So you've been wasting your time because you're still a mediocre programmer living in a fantasy world. And we're supposed to take your word at it? I'm not suggesting anyone take my word for anything- I can or do back up everything I have to say on any subject, including the one about you being nearly incompetent.
Consider for a moment that GNOME is a very large, very complicated, and very strongly backed interface, set of guidelines, libraries, applications, and a desktop. Now consider that the gross majority of it is written in C. Presume all you will about my professional history, are you really saying that you're smarter than everyone at SUN, IBM, Novell, Red Hat, and all the people who have made GNOME what it is today?
QT is a piece of shit. It's a terrible user interface that has had to be completely reinvented incompatibly four times in a language with perhaps the smallest imaginable user base, and by singing its praises, you expect to be taken seriously?
On the off chance I'm completely wrong about you, take a twenty minute tour of Objective-C, Xcode, and Interface Builder, and then tell me that you still want to bear QT's children.
If a cop gets a misdemeanor, break his legs. If a cop commits a felony, hang him.