Slashdot Mirror
Next Generation C++ In The Works
lamefrog writes: "Bjarne Stroustrup and other members of the C++ community
recently met to discuss new work on the language
for the first
time post-ISO standard (C++0x) in an effort to
keep the language moving,
avoid fossilization and avoid being
overtaken by proprietary extensions.
Suggested new features center around the standard library and include support for multi-threading and simple platform-independent systems abstractions (handles, TCP/IP, memory maps etc...)" (Read more.)
"Most intriguing is a suggestion to include extended type information that will eliminate the need for IDLs and make it possible to generate standard bindings to external systems (COM, CORBA, SQL). Clearly Bjarne wants to position this as a platform-neutral, vendor-neutral, standardized alternative to the proprietary, vendor-supported languages that have emerged over the recent years. Audio MP3 and slides available on Dr. Dobb's TechNetCast." Thoughtfully, it's available to download as well (not just streaming), and accompanied by a transcript. Good listening.
C#? (I pronounce it C-Hack)
I disagree. ANSI C isn't broken, but look at early 80s C code. Look at an early version of C and tell it couldn't be improved upon. I dare you :)
Look at libsigc++ for a well-designed implementation of signals and slots which does not rely on a source code generator (moc) and catches various bugs at compile-time instead of runtime.
Qt has the right idea, but its implementation involves unpleasant cruft and extra language keywords (emit, slots, signals, Q_OBJECT, etc.).
It's not a bug, its a feature. Although the handling of less thans is less than ideal (it should just convert them), the adding of spaces to URLs is intentional. Before slashdot did that, there were some jerkoffs who liked to post comments with 10000 character long URLs that would cause most browsers to either choke or make you constantly scroll left and right to read the comments. The breaks in long lines (URLs are very long lines) prevent that from happening, although it does add some annoyance to copy-and-paste URLs (Hint: use the Anchor tag!)
Down that path lies madness. On the other hand, the road to hell is paved with melting snowballs.
I read the internet for the articles.
Umm, my major problem with C++ is execution time. I try and write as little as possible in C++, sticking mainly to C and Perl for anything which needs to execute quickly
You're claiming Perl executes faster than C++? Bwahahaha.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
By creating yet another language, they are just adding to the problem (of incompatible C/C++ derivatives). It would be better to pick one of the existing next-generation C languages and declare that the standard, or at least make the standard source-compatible with said language to ease transition.
I don't use VC++ much, but I think I read (C/C++ UJ) that this is a preference that can be changed to put 'i' in the correct scope.
You can do (hope I get this right)
#define for if (0); else for
in some core header file, and then your for statement variables will have the proper scope.
Seems like it shouldn't have taken that much effort to fix the Windows headers to match the standard, though.
Ooh, a sarcasm detector. Oh, that's a real useful invention.
Your method will break anything like this one.
It's supposed to. Your code (ignoring the HTML gobbling of <) is not legal under the ANSI/ISO C++ standard. Under it, variables declared in a for statement got out of scope at the end of the compound statement.
Ooh, a sarcasm detector. Oh, that's a real useful invention.
The C and C++ specs leave many conditions 'undefined'. That is to say, compiler writers may handle a given situation as they like (generate error, do the Right Thing, who knows?). This always boggled my mind... here you have a bunch of smart guys writing a complex document defining a language millions of people will use for the next few decades, they come up with problem situations and just shrug their shoulders? Undefined? Don't do this? WTF?!? They obviously though this could be a problem that would come up, so why no default behaviour?
"Hot lesbian witches! It's fucking genius!"
Yes, but then you have non-portable code. C specifically was designed for portability. So now you have code that relies on some implementation defined behaviour that may or may not be the same on other platorms, even using the same compiler. I understand the reasons for doing this somewhat, but things like a[i++] = i++ _should_ have precisely defined behaviour. Constricting the ++ operator might lead to inefficiencies on some architectures, but really, when half a dozen characters lead to undefined behariour there's a problem.
"Hot lesbian witches! It's fucking genius!"
Here is the problems I had when trying to compile code (that worked on GCC 2.95 and Borland 5.0) with Visual C++.
- The compiler crashes if you look at it the worng way. Internal errors everywhere.
- The for scope was wrong. Luckily, someone suggested a macro that would compensate for that.
- Lots of silly arbitrary limits, for example debug symbols can at most be 255 chars. That is ok for C, but not for a mangled C++ template. There is a pragma that remove the warning, except that it doesn't work for static objects.
On the other hand, their development environtment is nice, and their library beats GNU and Borland.
Will 7.0 make me happy?
> The C++ definition used to say the scope of
> variable was the scope that surrounded the for
> loop.
That was many, many years ago.
> The reason why it's not the default setting is obvious.
GCC implement the "new" semantic, but still accept code that would be valid with the old semantic with a warning (by default).
// Work around broken for-scoping
#define for if(0);else for
I doubt you will have to fight for features already in C99, while Bjarne probably won't get his wish for a common C/C++ standard fullfiled, I assume the new C++ standard will adopt most of the C99 features. Even though the C standard commite didn't made the job easy. I.e. C99 has a complex keyword, giving trouble for the C++ complex template.
Uses "class" to create new types.
/* not an error! */
I like that this works:
typedef double time;
typedef double distance;
typedef double speed;
time hours = 2.0;
distance miles = 30.0;
speed mph = miles / hours;
> 1. Losing the pointless duplication of .h files.
> declarations in
Not necessarily a good thing. Redundance catches errors.
> 2. Virtual methods can be determined by the
> linker, so the programmer no longer needs to
> specify virtual-ness at all.
Definitely not a good thing, virtualness is important when reasoning about a class. After a call to a virtual function much more state is uncertain than after a call to a non-virtual call.
> 4. Inlining and template instatiation can be
> post poned until link given a sufficiently
> sophisticated intermediate format. In fact the
> compiler can inline any method or function.
This has been the case for a long time, with gcc -repo or Sun CC.
> 5. No more name mangling.
The type information has to be represented somehow, name mangling is not really different from other means.
This issue has been confused by some poor OOP language which doesn't have the ability to specify non-virtual function. These languages should not be used for robust software.
It simply doesn't matter. The same information must be represented, the form (a mangled string, or a struct) is simply an implementation detail.How about creating <stdgui.h> ?
A classic case of "If it ain't broke, don't fix it." And C was never broke. C++ is and remains a monstrosity of unneeded evil.
The problem with these is that if you make them too simple, nobody will want to use them. If you make them too complex, they won't be widely implemented. And there isn't really a satisfactory middle ground either, it's more of a fine line. One missing little key feature can make an interface unsatisfactory, if not outright useless.
:)
There exist standard such abstractions for C programming, under the umbrella of POSIX and The Single UNIX Specification. These abstractions are not as widely implemented as, say, the standard C library! We are still not at the point where you can write POSIX code and expect it to work everywhere.
Any interface that is going to be acceptable to a wide range of C++ vendors is going to have to be dumbed down and braindamaged beyond repair.
For example, a standard C++ threading library probably won't be able to have useful POSIX behaviors in it because Microsoft would leave them unimplemented in future generations of Visual C++. So you will end up with some weak interface that caters to the lowest common denominator, and which programmers will soon learn to avoid.
On the other end of the scale, you could end up with a situation in which the powerful, useful systems extensions are are an optional part of the C++ standard, and one that is only implemented properly by people who have a clue, over top of high quality operating systems. And so only developers targetting only these systems will be able to use the interface. Still, it's better than an interface that all programmers avoid.
I suspect that for some time to come, the real tool for portability will be something that is already there: good old preprocessing directives that allow you to roll several similar programs into one.
The ultimate solution to the portability problem is to actually have one operating system running everywhere. Portability is achieved with greater ease at the lowest levels, and doing it there provides the greatest leverage for everything else. Example: it's easier to have Linux running on some portable device and recompile existing programs for it, than to port applications to some exotic embedded operating system on the same device! This is particularly true because such devices are increasingly built around standard, advanced architectures that fit the model expected by an advanced operating system. The idea of using the same advanced OS for small and large computing is pretty much here now.
Windows CE teaches us that it's not even enough to merely have a reimplementation of the same system call interface. Anyone who has had to port Win32 sofware to Windows CE will understand! If you port the actual kernel, that's a big difference, because you port every nuance of the behavior behind that interface. It's not possible to specify every such nuance in a document and have everyone implement it exactly, and it's hard to be certain to what extent an application depends on these nuances!
Remember, when Thompson and Ritchie presented C and UNIX to the world circa 1974, it was the portability of the operating system that impressed the world. The portability of C programs rested on the retargettability of the C compiler and porting of the OS, not on writing in a standard language using standard interfaces! Porting C programs to different operating systems came later (and is not really all here yet, nearly thirty years later).
This is what language standardization is really about: a bunch of conflicting big interests bent on preserving their piece of the pie. Nobody wants to come out and admit that there needs to be one *implementation* of one interface running everywhere, because that would mean giving up their proprietary operating systems and interfaces, whose incompatibilities they secretly cherish. Since nonportability of software is caused by secrecy driven by ego and greed, universal portability will only be achieved when we recognize the root causes and do something about them. Right now, with our programming language standardization efforts, we are accepting these causes as immutable givens, and working *around* them to create solutions that are incomplete and unsatisfactory when translated to action in the software development trenches.
My number one feature wish for C++: try/finally clauses, like in Java. While I rarely use them in Java, they would be REALLY useful in C++ and make dealing with exceptions much easier. I do not know how many times I have written:
// allocate something
// free it
try {
}
catch (...) {
return;
}
// free it, too
This means lots of duplicated code (or many auto pointers and similar stuff) and many potential bugs.
I like the libsigc-- ones better, far more runtime checking, adaptors, and I think they are even faster. OSS license, and avail. on sourceforge. They are not GTK+ specific, even though it was originally designed for use there.
Nope. It is an array index followed by a jump to that location which contains a jump to the new location. Or at least that is a common way to do it (it does double the size of the vtbl). That tends to make branch predictors happier...
Now other then that one little edge, I did kind of forget the extra indirection, which does make the C++ call a bit slower, but compared to the cost of the pipeline bubble from doing a jump through a pointer, or for having the BTB miss (10 to 20 cycles) the extra two for the indirect (assuming a cache hit) is pretty minor.
Oops. My bad.
Only reference counting can destroy objects as quickly as explicit memory management. Reference counting is also the slowest GC, and frequently not even accepted as GC because they break in the presence of even trivially circular objects. So what most people would think of as good GC will extend the lifetime of objects somewhat (except when they fix a memory leak and radically reduce the lifetime of the object).
If your destructor is important, use of auto_ptr or other "smart" pointers will be needed even in a GCed language. (don't get me wrong, I like GC, I just don't like overselling it)
It is independent of ld.so. Well actually it might be done for similar reasons. It use to always be an indirect jump (like in C, but with the vtbl indirection), but has been changed to a jump through a jump because that runs faster on many platforms.
See the gcc C++ archives for details, or maybe you can find a comp.arch archive.
I'm not a CPU designer, but I hang out in comp.arch a lot. So take this with a grain of salt.
Some CPUs sniff writes to areas covered by the i-cache, and will do a lot of work when they are detected. Assuming BTB targets must be in the i-cache (true on some CPUs) that provides a good way to catch changing tables of jumps, but not tables of jump addresses.
No CPU I know of sniffs BTB source addresses. I think that is in part because BTBs became popular in micros well after self-modifying code became "evil".
Many CPU's (pretty much everything other then the x86 -- and other really old things like the 390) require a (i-)cache invalidation between modifying code and executing that code. The cache invalidation will also invalidate the BTB. So the CPU can feel free to use the BTB to optimize a JMP-JMP sequence, but not to optimize a indirect jump.
While I'm on the topic of CPUs, I think the POWER (incl PowerPC) has dedicated branch registers, and doing an indirect branch through them is quite fast, at least if the CPU has time to prefetch the targets, or they are in the i-cache. Except on the PowerAS where the branch registers aren't special, but the pipeline is so short (an amazing six cycles at 500+Mhz) pipeline stalls are cheep enough that they don't do target prediction, and only static branch prediction.
Could a CPU make indirect branches as fast as JMP JMP branches? Sure, but I think it would slow down all data stores, or the all uses of the BTB, or both. It doesn't seem worth it with current language usage. Could C implement function pointers as JMP JMP? Sure, but that would make function pointers wider then normal pointers (or waste space in normal pointers).
Does this make C++'s virtual function calls faster then C's? That is going to depend a lot on the CPU, and the usage patterns. I doubt they will be faster on a PowerPC, but they could be faster on a AMD K7, or the Intel P3 and P4, and they were for sure in one usage on the SPARC for me. Which is why I went down this rathole in the first place, to figure out how that could be.
I was talking about the equiv code. Yes, C always knows the pointer type, or more accurately C assumes it knows the pointer type, and if it is wrong, the programmer (or user) will pay.
It is your right to think that. Personally I find it easier to bring people into the fold by convincing them to use the more powerful language, and it's cheeper features.
Of corse the first time you look at code that finds the 95% percentile by doing sort, and replace it with nth_element converting a O(NlogN) algo into a O(N) algo and save days of runtime in a billing application, yes, they will buy the algo argument. One savings like that can make up for a lot of runtime ineffecency.
However if you never get them to use C++, you will never get them to "just call nth_element". So I like to start by saying "Yo, if you micromanage C's runtime speed, you can do that in C++ too, and while your in there try templates, they'll make that micromanagment way simpler, go check out the STL too....". That tends to convert more people.
Mmap a large binary file, treat it as an array of int, sort it. Treat it as an array of char, sort it. Use the language provided library to do both sorts.
Done. The C++ STL version is a few lines shorter then the C qsort version.
The gcc provided with BSD/OS 4.2 x86, or the SPARC version. For both languages.
Odd, the C++ program seems to have been eight times faster. Oh, look now that the file is in the cache it is 14 times faster.
What's the alternative, arguing without facts, as you have just done?
Exactly. The hidden costs the other poster was talking about don't exist.
Well, it doesn't so much fool the CPU into thinking the location is constant as to actually inform it that the location is constant.
C++ isn't the only thing that runs on a CPU. It may well be a good idea to have a indirect jump that does allocate a BTB entry, or to have BTB entries allocated if the indirect address is on a read-only page (this may be hard to tell). Of corse one could only do this on a CPU that deals with the BTB entry being incorrect (most modern CPUs do, OOO machines can do it fairly trivially), otherwise you can get some odd problems.
Eh? The vtbl is stored in immutable code space (in most implementations), after all the vtbl is immutable. The only i-cache invalidate is done when the OS maps the page in the first time. I'm unaware of what VM optimizations are being forgone.
You can bitch about the vtbl being immutable is a bad requirement, and prevents C++ from being as flexible as Ruby. But that is a different topic.
So I say there are no hidden costs in how C++ implements this trick. You can argue that there are hidden costs in how the CPU thinks about i-space, but that is a very different argument.
With the sole exception of the x86 all modern CPUs are broken? They all assume that i-space is very seldom altered, and that that altering can be quite costly. In fact even the modern x86 assumes that. The other CPUs require an i-cache invalidate, the x86 makes stores slower by snooping i-cache address, or they make the i-cache smaller, or both.
That seems a little silly as i-space modification is rare, it wasn't even all that common when it was easy. The only place I can think of where it is all that useful is a low level graphics system, but that kind of code can be frequently be pre-expanded, or even more commonly hardware assist is used now anyway.
I have written self modifying code (at least) three time in the last 20 years. I don't mind it being slightly harder now. Have you ever written any?
Or frequently at the "cost" of finding stray pointer usage much sooner.
From a system standpoint making self modifying code faster makes everything else slower. Is there really enough self modifying code to make that a good deal?
I thought the topic was whether the C++ double jump through a vtbl was better then a single indirect jump through the vtbl. C++ does not allow overloading of functions of a single object, it requires a new class for that. So C++ will not benefit from a writable vtbl.
If the topic is something else, please let me know so I can either argue my point, or agree with yours.
Well it was a reply to a C++ article, so I assumed we were discussing C++, and CPUs slipped in in relationship only to that. I admit I may be talking about a different topic then you though, but not to frustrate you, but because I was unaware you were discussing something else.
No CPU I know of has that assumption. All of them allow a i-space change, because all of them need to allow programs to be loaded in. Given the rarity of the changes many require something fairly expensive to be done after the change (like an i-cache flush, or on things like the MIPS a controlled flush of some of the lines).
Ok, does that mean you think the vtbl is mutable? The vtbl is immutable. It is never changed. It is a constant. I don't even know any non-portable ways to change the vtbl.
If C++ itself was changed in a way that needed mutable vtbls I expect the double jump through a vtbl would be changed back to an indirect jump and the vtbl moved to a writable area. But I'm not sure. It might be cheeper on some CPUs do do selective i-cache flushes (like on the CPUs that allow single cache lines to be invalidated).
Are we talking about the way C++ uses the CPU? If so it doesn't make anything slower as it uses immutable i-space to hold immutable data (technically it is code I guess, but immutable none the less).
If we are talking about the way CPUs make modifying i-space expensive, then I expect you are wrong, but it does depend on exactly what code you need to run. It is a big argument, and unless it is one you are interested in I'll leave it dormant.
If we are talking about something else please do let me know.
Those things do exist (for the most part). C++ doesn't cause them though. C++ using the double jump doesn't make these problems any worse (except, arguably "pollution of the BTB..."). If you are not intrested in C++'s use of this feature and want to disscuss modifyable i-space in genneral, I'm fine with that.
But could you let me know what the hell the topic is?
Now of the costs that you listed, what do define "false sharing" as, and what does "pollution of the BTB when the regular L1 cache is damn near as good" mean?
Well it won't happen unless we are both on the same topic. Care to let me know what the topic is?
Pretty much, but you can change that.
The vtbl is not ever written to. On a unix system it is part of the ELF or a.out code area. The linker figures out how it looks, and it is not changed at runtime.
It might be different for a dynamically linked library, but the normal C linked libs frequently (but not always) work that way. BSD/OS does the double JMP trick (at least on the x86), using a ld.so that it got from FreeBSD, which uses a ld.so borrowed from, or inspired by the Linux version. So there is a good chance all three systems do it the same way.
Of corse dynamically linked C++ code is quite rare. Or at least using C++ libs dynamically, it is common for C++ code to use dynamic C libs. This has a lot to do with defcicencies in the ABI, and in template generation code.
So for a static linked program the vtbl is never ever written. I'm not sure about dynamically linked ones, maybe I'll go check.
For statically linked code it is the same as being done at image load time, because the vtbl is filled out at image load time (before that actually).
For dynamically linked code it is also not all that different (I assume) because ld.so does similar things for the C code, and it also has minimal OS support (the mprotect(2) call, make the stub tables non-executable+writable, change them, make them executable+read-only).
That's an opinion based on whether you view it as a kludge or not. I view it as a real use of the BTB because I view the BTB's job a keeping the pipeline filled in the presence of branches.
Some CPUs allocate BTB entries for normal JMP and JSR instructions. The AMD 29k did that, the BTB held an address and the actual instruction. Modern CPUs don't tend to do that because the pipeline is too long to be happy with just one instruction. Some modern CPUs still keep entries for all branch/JMP/JSRs, but the BTB has a "internal pointer" to the i-cache line. This is rare because it is only useful on CPUs where the i-cache lookup takes more then one cycle (otherwise the internal pointer is no win).
CPUs like the HAL SPARC64 actually unfold i-space around control flow instructions, so the JMP-JMP would be replaced with the straight line code, no BTB would be allocated. I'm not sure about the P-IV's trace cache as I don't know if it is a true trace cache, or just shares the name.
In any event I think using the BTB entry to make the JMP JMP faster is a great thing, it avoids a pipeline stall. If that means some other branches can't fit, well at least it got used in some places.
However here I'm only arguing my opinion vs. yours. The right thing to try would be to convert from JMP JMP to a indirect JMP. If the indirect JMP is faster then you are right for that workload. If the JMP JMP is faster then I'm right for that workload. It's probably not all that hard to get gcc to produce either kind of code, so the big issue would be finding the right workload.
Any ideas?
The BTB is actually included in the L1 cache on some CPUs. At least one SPARC, and I think the AMD K7. The down side is they limit the number of jumps that can have a BTB entry per cache line. I guess the other down side is they make the L1 cache take more transistors per line, and possibly reduce it's size.
Oh, it's more then a cycle in many CPUs. In fact of all the modern CPUs except the PowerAS it is a fair bit more then a cycle, if you read the PowerAS papers they make a big deal about it. I think the PowerAS is also known as the IBM North Star, it is the CPU in their more recent AS/400ish systems.
I do agree that if the BTB entry for the JMP JMP pushes out an entry that would see at least as much use it is just shifting the load. Or worse if it pushes out an entry that is used more. A good BTB replacement algorithm can reduce the chances of that happening. A very large BTB (like the ones tied directly to the L1 cache) will also reduce the chances.
On the other hand the BTB entry for the JMP JMP may push out a less often used entry, or no other entry at all. In those cases it is a win.
The question is, does it win more then it loses? The true answer will depend on the CPU and the benchmark. I expect it to be a win though.
Yes, I'm asking how it applys here. I read H and P in '92. I know there is a new edition, but getting it is pretty far down on my reading list. It did actually make it onto my bookshelf and there have been 4 moves between then and now though.
For a statically linked C++ program there is no vtbl patching. None. For a dynamically linked one I don't expect the costs to be different from the C version which has a similar table.
Yeah but the assumption would probably be 16 bytes because that is a really really common number, and even if it happens to be only 50% or 25% of the cache line that is better then doing only a single address.
Of corse that would be if there were any vtbl patching code, because there isn't any.
Independent of context?
If you know that the target won't be altered you can get a very different answer then if you assume the target will be mutable. Or even a different answer on mutable but almost never changed vs mutable and changed frequently.
The answer can also depend a lot on the CPU and other things, like is the main memory system high latency (like maybe remote on a NUMA) or low latency (like on a CPU with an integrated SDRAM or RDRAM controller).
I expect it is the correct thing with a immutable target on most but not all CPUs.
If you don't want to debate, don't debate. There is no need to stoop to insulting your debating partner.
So when do they change the vtbl? I could believe the debugger might do it, but I don't know if it does. The debugger also writes other normally non-writable areas, so I don't think that makes a big difference.
I don't know any other times a statically linked C++ program would change the vtbl. I've been asserting that dynamically linked C++ programs aren't an interesting debate area because (a) I really haven't seen any, and (b) the C code ends up doing the same fixups, and (c) I don't really know when and how the fixups are done (they could be as each vtbl entry is used, or en mass), (d) many platforms that can dynamically link C can't do the same for C++, (e) I figured it was irrelevant because in a apples to apples the C code is just as bad.
No, but those are the only OSes in widespread use that I know how the dynamic linker works on. I also know how Multics did it, how Sprite did it, how SunOS 4.x did it, and a few research systems. I also know how the static linked shared objects on SCO and BSD/OS work.
I didn't want to say "this is how dynamic linking always works", so I went with "it works this way on the OSes I know about".
No, that is a lot of overhead. However I was explaining exactly what ld.so does for C code, not C++ vtbls. For example on many systems a libc.so call to malloc will do a JMP JMP (or indirect jump), even though malloc is in libc.so, the call through the dynamic link table just in case a "more important" .so defines malloc.
I don't know if these (C code!) JMP JMP sequences are better then an indirect jump. By extension I don't know if the same C++ shared object JMP JMPs are a good idea.
Well, I do believe the static linked C++ JMP JMPs don't slow the system down as a whole, and I don't think they make anything more complex with the possible exception of the linker.
Sure they did, I even hesitated to bring it up the first time. I just think there is a lot of code that assumes 16 byte lines, and because the lines of CPUs are currently multiples of 8 bytes (almost always multiples of 16) they tend not to get in too much trouble.
I can think of cases where it would cause trouble. I can think of more cases where it would at the very least fail to be faster then code that ignores the cache line size. I assume it also pisses off CPU designers because there might be some win in designing 30 byte cache lines (or some other odd size), except all the code that assumes 16 byte lines screw it up (but code "just written" would run better).
The right thing would be to run with a #define, or a const int, I was however making a cynical comment that 16 would get chosen, not a pronouncement that 16 ought to be the One True Answer there.
Let's see, what were those costs I was denying existed?
Those I still say don't exist, because I still say the vtbl is not changed at runtime.
Now I do admit that I hadn't thought about dynamically linked code the first time I made that statement. In fact I didn't think about it until about two posts ago. I still don't think dynamically linked code is relevant for reasons I stated at the top of the post.
If we do include the dynamically linked code then of the costs you listed originally, the same ones I dismissed out of hand, the "Invalidating i-cache may blow away unrelated (but needed) instructions" is the only relevant cost. It is not payed on each object creation. Depending on how exactly ld.so works it may be payed only when the .so is mapped the first time, or it may be payed when the first call on that vtbl is made, or the first call through a specific entry of the vtbl is called. Even so the vtbl will be shared for all objects of the same class.
To be pissy, the costs you asserted, and I denied don't exist, even for a dynamically linked object.
Being less pissy, one of the four costs you asserted exists in a radically reduced form. If you include dynamically linked code (and I hadn't argued at the time that one shouldn't, in large part because I hadn't thought about dynamically linked code at all) then you have enough of a point that I should have said "3 of the four never ever happen, the last doesn't happen in practice, and even if it did it isn't per object create, but about as frequent as per class in a .so, or per virtual function per class in a .so, or maybe per .so".
But I didn't realize at the time that there was a small part of the original statement that was true. You were (or seemed) fixated on the vtbl being modified all the damn time, and I was fixated on denying it.
Maybe we would have gotten here sooner if you were civil, but I assure you we would not have gotten here later.
Maybe it wasn't sleaze, maybe I didn't realize it was true.
And I still don't think it is the least bit common.
Some things in C++ are quite slow, but no slower then simulating them in C. Faster in many cases. The C++ STL sort function seems to be about an order of magnitude faster then C's qsort (operating on char, short, and int's).
In fact the STL in general is quite fast, normally faster then the C equivalent (when one exists), definitely faster then what one would whip up in an hour.
C++'s virtual functions are slow. Quite slow. But faster then C calling through a pointer. Sometimes insanely faster because the C++ compiler can actually tell what type the pointer will be at run time. C can almost never tell.
If the only thing you care about is execution speed, use C++. Use the STL. Use C's I/O. Avoid virtual functions, except when you would have used a function pointer before.
I'm going to ignore the bit where you think Perl makes faster code then C++ (I do admit it could in some cases, but not normally).
This is not to say that I think C++ is a wonderful language. I rather dislike it. I love the STL. Everything else in C++ seems to have been done better elsewhere. Still the language has value, if only because of the wide availability.
That isn't surprising at all. The C runtime is very straight forward (except for setjump/longjump). It is pretty clear how things can/should be implemented. C++ does a lot more for you, and it is unclear how they might do it (either because it's hard to guess how anyone might do it, or it's just hard to guess how this one compiler does it).
(the STL's "runtime complexity" requirements is a good start, but it is just big O, the constants can still kill you)
I don't think you will find a higher level language then C with a simpler to guess performance model (unless the model is "everything written in Tcl is slow"). I mean for all Eiffel's wonderful features, or Modula-3's, I don't think looking at two functions and guessing which is faster is among them.
I can't think of any high level language has a simpler runtime then C. That is both high complement, and damnation.
I don't understand this. Is this because the processor assummes that any location you jump to is involitile? It seems that an indirect jump could be "predicted" just as well by assumming the contents of the pointed-to memory location is the same as last time and this would require no more circuitry than the jump-to-jump predictor.
The fact that I can't take some code and change a pointer to a reference (or back) without a huge amount of search & replace of . and -> is very annoying and often I end up leaving inefficient code as it was because of this.
There is no reason for this distinction. There isn't even a reason in C ever since the very first version that remembered the type of variables.
Probably more drastic, but I would like to see '.' usable everywhere '::' is. This means class and variables are in the same namespace, which is incomptable, but it would make the code much nicer to read.
Shared libraries for functions like this are NOT efficient, despite all the hopes and dreams of morons. How big is the identifier that matches up the program with the shared library? I would not be suprised if it is 2 or 3 dozen times larger than the code (take a look at some mangled template names if you don't believe me).
And you have just made this poor sap's program into another entry in DLL (or .so) hell. Now they have to "install" it in order for it to work. Wow, what great advanced in Comp Sci. Someday it will be totally impossible to run anything!
Besides the fact that you returned a reference to a temporary, a quick comparison of the size and readability of his example and your "solution" should make it pretty obvious why!
It looks like the problem is that the CPU designers figured the reason that somebody would jump to *(ptr+offset) is because the entry at *(ptr+offset) changes. But C++ (and all other OO languages, I would think) that entry is a constant, and instead it is the ptr that changes to point at different (but still constant) tables.
This jmp-to-jmp stuff is a way to fool the CPU cache and predictor circuitry into assumming the location is constant, because it figures that jmp instructions are constant. It does seem kind of annoying that it is worth doubling the table size (and thus halving how much fits in the cache) in order to get around a mistaken programming assumpition by the CPU designers.
I think it would be better for a CPU jump predictor to assumme *everything*, whether in instruction, read only, or read/write data, is constant. Modern C++ code typically accesses a given location many orders of magnitude more times than it modifies it!
Yes, reference and pointer are very much alike. That is why I want '->' and '.' to be the same, since having to change these back and forth is the only difference in most cases.
That's just the most outlandish example I could think of, but there are many other platforms out there that would suffer, and for minimal benefit. The internal representation isn't important, it's the interchange representation that's the problem. A standard binary data exchange format, and efficient (i.e. platform-optimised) routines are what is needed.
It's unpopular for good reasons. It would impose too great a burden on unusual platforms such as PDPs (IIRC) where the byte size is 36 bits. Having to mess around with the value before and after every integer operation would be a nightmare. Also, there is the endian problem, as others have mentioned. What I would like to see is a set of std:: functions for outputting binary data in specific formats such as little-endian 32 bit, big-endian 64 bit, etc.
eg:
std::binary_out<int,std::little_endian,32>( 12345 );
(1) A(n optional) method "this()" that returns some pointer-like object to be used as the "this" variable in method calls. Guess what this would allow? No-in-place garbage collection. Imagine being able to move an object around in memory inside a callstack in which the object is being accessed.
(2) Interface separation from inheritance, like "implements" in ML or Java. I would like to be able to specify an interface that a compliant class needs to follow to be passed as a parameter to my function, without requiring the author of that class to ever have heard of my function. This can't be done with inheritance, because the author of that class would need to have known about your interface (read: base class) in advance.
Kyle
[ home ]
Or, maybe, House /implements/ Roof, Walls, and Foundation?
All right, House is not a good example for interfaces. Never mind.
-30-
Or better yet, use the Standard string class..
".sig,
".sig,
You guys are just uisng the wrong language!
How about this? (pardon the formatting, <pre> is not allowed.)
type FOO is new integer ; ;
; ; := 1 ; := 2 ; := 3 ;
:= b; -- ILLEGAL TYPE MISMATCH! := i; -- ILLEGAL TYPE MISMATCH! := f; -- ILLEGAL TYPE MISMATCH!
:= fiz( 5 ) ; -- first fix := fiz( b ) ; -- second fiz := fizzle( f ) ; -- legal := fizzle( f ) ; -- ILLEGAL, TYPE MISMATCH := fizzle( b ) ; -- ILLEGAL, TYPE MISMATCH := frazzle( f, b ) ; -- All legal and proper := frazzle( 7, b ) ; -- All legal and proper := frazzle( f, 7 ) ; -- All legal and proper := frazzle( 7, 7 ) ; -- All legal and proper := frazzle( b, f ) ; -- ILLEGAL, 2 type mismatches
type BAR is new integer
function fiz( i : FOO ) return FOO
function fiz( i : BAR ) return BAR ; -- Different, overloaded
function fizzle( i : FOO ) return FOO
function frazzle( f : FOO ; b : BAR ) return integer ;
f : FOO
b : BAR
i : integer
f
b
i
-- further:
f
b
f
b
f
i
i
i
i
i
-- (operands reversed).
-- And so forth.
-- All arithetic, comparison, indexing, operations are inherited.
Each enumeration type is distinct (with its own namespace). Enumeration types may be used for indexing and loop control, but not for arithemtic.
Sound good? For more info look here or here or here.
Here's a question for you:
How is the parser supposed to understand if myControl is a ** or if cntrlRect is a **?
struct Control **p;
struct Control {
void **cntrlRect;
};
This technique is what you'd use for loading a module dynamically and resolving it's functions dynamically. The syntax is C because C++ is C with features builtin to hide the underlying "ugly" C implementation.
The parser can't dereference the ->> at runtime precisely of the above structure layout; it's ambiguous, you need to do it longhand like C programmers have been doing for eons.
There is already some solution for this. See tuples here.
Szo
Red Leader Standing By!
C# isn't C it's the COM+ extention of what was the M$ lang 'COOL' that was 'j++' ( M$ basterd java ).
;)
Come on guys - I don't even use windows but 3 times a week and I know that.
I'd love to see Stepanov and a couple people of his choosing get together to work on his concept-based language. Either polish up & extend C++'s template handling, or better yet start something completely new.
Someday we'll all be negroes
Garbage collection ain't too popular with systems types either - if you don't want something any more, free it so someone else can use its resources. Either that or throw away the context (apache fork-n-die model) so you don't waste your time scrap-hunting.
Maybe I'm just an old fart about disciplined programming. But then again, so is Linus, so I'm in good company.
Or kernels in C.
Heck, what do stdin/stdout mean to an MFC application?
You need some sort of support library. For a language to be useful, I would expect to be able to chuck the standard one out the window and replace it with one that suits the context I want to use the language in.
Please put in the sockets and signals that Qt implement? Those are damn nice.
And something else... figure out some way to make the error messages from templates more readable. Templates are extremely nice, but when you screw one up, finding your mistake involves parsing a line with 8000 characters. This one's probably more for compliler implementers, but if there's a clean way to help in the language, do it.
If tits were wings it'd be flying around.
"Could you please list the advantages C++ has over Java?"
How about the memory eating JVM for starters?
The point is, the Java people will consider many aspects of the language as 'benifits!'. While the C++ people will see these as misplaced, ill implemented 'drawbacks!'.
It's all about viewpoint...
Overload, dear, overload.
--
Isn't it funny that all the while C* programmers have been tripping over themselves and shooting themselves in the foot with C*'s easily obfuscated syntax, Pascal programmers have been able to enjoy extensions to the language that effectively cancelled all objections given against Pascal?
So, you have a group of people still untangling their spaghetti-pointers and memory leaks, whilst the other have been concentrating on their *REAL* job, programming?
--
. The STL in particular is a beautful, high performance, library that damn near perfectly nails down the balance between power, flexability and ease of use.
Don't forget the mind numbing syntax! The STL is nice and fast, but using it makes me yearn for the layers of casting that Java libraries have.
Scuttlemonkey is a troll
I've been programming for years. I taught myself C++ almost when it came out, back when it was so new, most people didn't understand why it was needed. It had almost no real features beyond the basic language stats.
And really, I'm not sure how I feel about this constant revisioning. It seems to me like the compilers are following Gates' Law (every 18 months, speed of software halves). While some things are nice (namespaces, etc.), I'm not sure how I feel about templates, and all of the other more minor features. I mean, feature extension after feature extension, it's getting a little tiresome keeping up with it all.
The upshot of this, of course, is that C compilers, which aren't following Gates' Law, are now faster than anything on modern processors.
~Conor (The Odd One)
Conor
Programmer, Consultant, Geek, CTYer.
It seems to me that the proper way to do this is to explicitly call the superclass version. It's slightly a pain, but I don't see how you'd miss doing anything by doing it that way, rather than what you describe.
Though I am interested to hear what you'd like to do, under those specs... I can't think of too much that's that interesting. Mail me or something.
~Conor (The Odd One)
Conor
Programmer, Consultant, Geek, CTYer.
I used to have a BCPL programming manual, it looked like a primitive ancestor of C.
Mea navis aericumbens anguillis abundat
Go use Java.
The philosophy of C, and to some extent C++, is that the language does not hide the underlying machine architecture from the programmer. That is why there are all of those "implementation defined" bits in the language. They reflect reality, where not every CPU is a descendant of the VAX or 80386. The language has enough implementation dependent slop to allow its efficient implementation on a wide variety of architectures. The language also gives compiler writers some freedom in how to evaluate and optimize expressions, layout data structures and pass parameters to functions.
Computers with 32-bit pointers/integers and 8-bit characters will not be around forever. They will eventually be replaced by newer architectures, perhaps with 64-bit integers, 128-bit pointers and 32-bit characters.
Mea navis aericumbens anguillis abundat
integral i32; integral i128;
or integral_at_least which would give you a 64-bit integer or whatever is fastest and at least that size for any given architecture.
Download boost and have all that and more...
typedef int (*MyLibFunctionProcType)(int param1);
#define FakeLibFunctionCall \ (*((MyLibFunctionProcType)(funcPtr)))
int retval = FakeLibFunctionCall(7);
This is a pretty standard way for building plug-in frameworks in C-based languages that has been around for awhile.
Left shift 1 for e-mail...
Well, other than the fact that neither C, C++, or Java have the issues that Pascal does.
Delphi is an implementation of Object Pascal.
Look, I don't mind Pascal, and I love OO, but Object Pascal is really a beast to behold.
I find that while there are nice things about C++, it is too cumbersome a language for me to use effectively. That's why I prefer languages like Java and Python - my coding time is much faster in that language, and I don't have to think about things like pointers, memory, leaks, etc.
Admittedly, I haven't used any implementation of Object Pascal a lot, but I haven't really liked what I tried. Pascal is best suited as an introductory procedural language.
A female deer? Sorry, couldn't resist :-P
--
Information wants to be beer, or something like that.
...they're gonna call it C##
bp
Some of the commercial UNIX compilers are actually pretty good. I've been happy in my experiences with MipsPro lately. I've also heard SunPro is good, but I don't know about the "standards" side... same with IBM's xlc. On the other hand, "xlc" is one of the few compilers that actually DOES CATCH that missing semicolon without farting on itself. :)
> ... an effort to keep the language moving, avoid fossilization and avoid being overtaken by proprietary extensions.
You mean keep the compiler writers so busy scrambling to keep up with the new standard that they don't have any _time_ to work on proprietary extensions?
1) Simplify syntax. ... all the standard suspects).
2) Eliminate type casting. Require user specified conversion functions (standard types included with standard library, of course).
3) Eliminate pointer arithmetic.
4) Range types.
5) Standard garbage collection inclusion.
6) Persistant storage. Preferable by a directly included B+Tree database.
7) B+Tree database as a part of the standard library.
8) Foreign Function Interfaces (not just to C, but to, O, Fortran, Python, Ruby, OCaML, Ada, Eiffel
Caution: Now approaching the (technological) singularity.
I think we've pushed this "anyone can grow up to be president" thing too far.
Get in line, sonny. They're still coming out with new versions of Ada, COBOL and FORTRAN.
if you're writing C++ that's slower than Perl you're doing something wrong. I challenge you to support any statement to the contrary.
Sure, Perl has built in facillities that can do some common stuff very quickly, but if you used the same algorithms in C++ it would almost certainly execute faster.
The header climits tells you what the range available is in a platform independent manner. If you think you will not be able to control that your program be compiled on a 32 bit platform then check out INT_MAX and make sure its big enough for what you want to do.
I can't comment on the C99 standard and what they think the gains would be from such a scheme. Though I wonder if those are really fixed bit width types? Can you talk more about that?
--
Poliglut
Say screw it and write in Object Pascal?
My journal has hot
.
cpeterso
It would be especially nice if these types were *not* considered, for the sake of signatures, type-identical to counterpart size-variant types, and if enums were also given a generic root type instead of being int in signature.
// ILLEGAL TYPE MISMATCH!
// ILLEGAL TYPE MISMATCH!
// ILLEGAL TYPE MISMATCH!
I always wished that typedefs created new types, instead of behaving like wimpy macros.
typedef int FOO;
typedef int BAR;
FOO f = 1;
BAR b = 2;
int i = 3;
f = b;
b = i;
i = f;
cpeterso
When Mozilla was started, this was sound advice (for portability sake). By the end of this year, it will be bad advice (in general). Use of templates (and STL) will be strongly favored for portability, speed, programmer man hours saved, etc.
"It's overkill, of course. But you can never have too much overkill." - Anonymous Slashdot Coward
Tee Heee...random moderators keep modding this down....then some other moderator comes along and mod's it up..
Ah....Signal 11 would be proud.
Of course, if you look at how long time it took for standardization last time now would probably be a good time to start.
-eric
Admission is free and all are welcome. Pose your questions to the man himself...
But the point under discussion *is* the claim that Java cannot support generic programming techniques - some people use that argument to say that the Java peg cannot fit well into *any* shape of hole, which is just as incorrect as saying that it can do anything.
I just want to find out for myself where they feel limited by Java when trying to program in a generic manner, as I myself have not felt that limitation. Other people pick up on that argument and then dismiss Java out of hand without even knowing why they would want support for generic programming. I'm just trying to stop the FUD.
I agree with your point that for some things, you simply will not be able to use Java and for others Java is a very good choice. I just tend to think the range of problems where you can use Java is wider than most people think it is. In fact many of the examples you listed could very well be done in Java, but I won't get into that here!
"There is more worth loving than we have strength to love." - Brian Jay Stanley
a) It's tied to a VM.
Not really. There are plenty of companies who have made systems that compile Java code into an executable... however that's been a niche market because most people are quite happy running Java code in VM's. Furthermore, the great thing is that Java is not tied to a specific VM so much as a family of VM's. Don't like your current VM? Swap in one that works better for you (unless you are running iPlanet, GRRRRR)
b) Its frameworks for GUI development try to be a least common denominator at the expense of running well on any given platform.
Totally off base. Rather, Swing is a "greatest common denominator" tagential system. If you use it carefully it works quite well just about anywhere - I wrote a fairly large MDI app all in Swing that was targeted to P166's with 32MB of memory!! It wasn't incredibly fast there, but then again on a P450 is was as fast as any of my other apps.
Swing was meant to be a GUI framework done right, and for the most part I think they've succeeded. It won't really be practical to write consumer apps that use Swing though until OS'es ship with a system to share Java execution and library space.
c) Its not a standard until Sun submits it to a real standards setting body. Until then its just as proprietary (in my mind) as Visual Basic, etc.
On the other hand, only MS make a VB compiler and runtime. Look at the plethora of Java VM's and compilers... If it looks like a rose and smells like a rose and the DNA profiles come back saying "rose", then even if the tag says it's a dandelion it's probably a rose.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Let's say they add some features to the Java to provide support for genericism.
What are you going to use it for that you can't do now in Java? I'm curious because I really haven't seen any examples given that I couldn't code in Java, and I feel like I use a number of fairly genericly oriented techniques when programming in Java. Perhaps I would be happier still if some extension made it into the language, but I don't feel very hampered at the moment.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
The STL is more powerful than the Java Collections package in the same sense as an F1 racer is more powerful than an Audi TT. For just about any real use you have, the TT is more practical and fun to use.
I think the Collections package strikes the perfect balance between a set of libraries that has a lot of power and a set of libraries that just about anyone can fine useful at some level. The Collections package takes care of about 99% of your collection needs on a day-to-day (or even yearly) basis, with a great and extremley usable interface packed with features. Syncronize or make collections read-only on the fly! Sort by internal or custom external comparitors! Easy to use Sets and TreeSets with an AVL tree you don't have to code by hand!
Plus, all that and if you want you can download the whole shebang in a tiny (I think about 48k, but it might be larger) jar file if you need to use it in a 1.x VM.
On top of that, I'm really not sure there's anything you can do in STL that can't be done with a little (or possibly no) effort in Java. Post examples, I'd be happy to see 'em.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I can see general typesafe containers as an argument, in that any time you use a container you know the contents will be what you expect them to be.
But then again you could easily approximate that in Java by providing List, Map, and Collection wrappers that would make sure anything added to a particular collection would be of an appropriate type. You could wrap the overlays around any collection. Just as with templates you need to specify a type that will be held you could do the same with collections if you really cared.
Then again, it works out that pretty much anywhere you have a collection you're going to know what's going in and what's going out. I don't think I've run into a problem yet where it mattered that the container was not type safe.
A rougher approximation for the second item (storing simple types) is of course using the wrapper objects like Int(), and I'll be the first to admit that's a bit of a pain. However, I don't see where that's an argument against Java supporting genericism so much as an argument about how types are handled in the language (and as a great fan of Scheme I'd love to see simple types be objects as well). I don't think it's a really strong argument as in most real cases you'd be dealing with objects, and the wrapper classes are good enough.
If I had to work with lots of collections of ints or longs or whatever, I'd probably just slightly extend a few interfaces like List and Iterator to make use of the standard collections yet have simple access to simple types. Other operations like sorting and so forth would work on the contents transparently just like any other container, and I could still pass the containers around without knowing what they held.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
that an implementation of STL (the MS implementation, one presumes) at the time the book was written was immature. The above post makes it seem as though Kernighan and Pike were frothing in their denunciation of C++.
Try g++ 3.0 pre-release. It's standard libraries are much more standard compliant.
"I switched from GNU C++ to Visual C++ in 1996 (change of jobs) and found that VC++ 5.0 was lot closer to the standard"
Thats odd, as I remember it the C++ standard wasn't finalised until around 1998. Can you really blame major compiler vendors for not having up-to-the-minute support on a moving target?
I do remember VC 5 had a number of problems with STL in particular, and we still have problems with the compiler in VC 6, even with the latest SP (random errors regarding DEBUG_NEW in MFC apps that disappear when you try compile again, as well as internal compiler errors) .. but overall our experiences have been pretty good with it.
-----
Yes I do actually.
When configured properly, they cut compile times quite dramatically (funnily enough, when misconfigured (e.g. if the "use precompiled headers through" edit box is empty instead of containing a filename), they slow down compile times dramatically). I experimented with this stuff very recently actually, managed to get a "rebuild all" down from 6 minutes to 3 minutes 45 seconds, for a project of just over 100000 lines of code, in 7 or 8 projects.
-----
I didn't see/hear any discussion on garbage collection. Anyone know what they think about this? That is my main reason for wanting to use Java or C-sharp.
-- Virtual Windows Project
C++'s fallback is that it is a bloated language with too many frivolous constructs. For anyone who doesn't believe me, take a look at section 3.8 of The Practice of Programming by Kernighan and Pike. Repeating them is a waste of space and my time (and you might as well pick up the book and read the whole thing while you're at it =]).
Therefore, I think that the best thing (well, at least an important thing) to do with the next incarnation of C++ is to move a lot of the bloated architecture into external libraries, so that what is necessary can easily be loaded, and so that execution time would speed up incredibly. Of course, I'm not saying this is easy to do or even really possible, I'm just saying that it should probably be looked at pretty carefully.
---
---
"Of course, that's just my opinion. I could be wrong." --Dennis Miller
| Oh, I have my criticisms of C++: A new standard
... and is one of the most brilliant designs i've seen to date.
| is a mistake when no on produces a fully-ISO
| compliant compiler today. The STL is an ugly
| mess designed by committee; I'd like to see
| restricted template arguments, inheritable
| enums, and a few other new ideas.
the stl wasn't designed by committee, but by stepanov
mx
No kidding.... Look at how w3c was handled... yeah there are standards, but it's hard to get people to follow them correctly. I'm still waiting and waiting for cool things like MathML to get put in to at least ONE popular browser (been hoping for mozilla for how many years?). Remember how long we have held onto COBOL FORTRAN and PL/I? Standards create stability but they allow things to stagnate. I think a new standard is a good thing because it will push people away from the antiquated one we have now. (yeah you may disagree, but people have been using extentions and fragmenting the space for too long...time to regroup)
:-) Good to see so many opinions!
OT: wow, It's been a while since I last posted, an I hadn't realized that my user number is considerably low for how many people are here now..
I think they should stop and concider when it's time to move on. My grandmother coded in C for Bell Labs (ok I'm 15, but still). While C/C++ are still great languages, in the future (ie: when these things finally get around to being fully supported in most compilers) processors will be about 8 times faster (expecting moores law at 1.5 years and 4-5 years until these are supported).
There are many great scripting languages with much more concise structuring than C and C++, and even things like variable-types could possibly be eliminated (perhaps build a virtual machine into the kernel that will handle the programs). Anyways they should think before wasting the time to add onto the language, get it standardized, get it implemented, and getting everyone to learn it.
See Mozart to see what I mean.
By the way, if you believe that we can improve over C++, come and help me implement LX... In my very biased opinion, this language is insanely better than C++. It is also one of the least successful Open Source projects in existence :-)
-- Did you try Tao3D? http://tao3d.sourceforge.net
You can't be serious with C++. I've tried (see my bio if you have any doubt ;-) You should rather consider one of the many C-- in existence. Some tidbits:
C-- is a subset of all ambiguous constructs which could be removed from any C++ extension without impact on general code quality. This naturally include all standard C and C++ constructs.
All new features range from "useless" to "potentially disastrous". The C-- reserved words that fall in the last category do not contain an asterisk (*).
The current implementation (V21.13) is a post-processor written in FORTRAN. It handles errors generated by the C compiler and interpolates with the C-- source code to create an MS-DOS batch file, which more or less does the same thing as what your C-- program intended to do, only slower. This implementations makes it easy to port the C-- compiler, provided there is a FORTRAN compiler, a C compiler and an MS-DOS batch file interpreter. IBM PC/DOS version is currently in beta test.
OK, I wrote all that crap a long time ago, and it shows a bit... But I may have been one of the first ones to propose comments ending in \\ (for left-handed people), a C++ compatible implementation of comefrom, function inheritance, #try .. #catch (to try and compile something), and a few others niceties. Too bad I did not finish it, I still had a lot of work to do on short long, dereferencing of float, dodecadecimal numbers, probabilistic switch, etc.
-- Did you try Tao3D? http://tao3d.sourceforge.net
Correction: The STL is equivalent to (most of) java.util, (part of) java.io, and java.lang.String. They are not equivalent. What the original poster was mentioning was the loss of java.net, java.awt, java.sql, javax.swing, java.rmi, java.lang, etc.
Assertion: You need to talk to a database.
Question: What is the official C++ method of talking to databases?
Answer: There is none.
Assertion: You need to write a graphical user interface.
Question: What is the official C++ method of implementing a graphical user interface?
Answer: There is none.
Assertion: You need to write a distributed (multi-system) program.
Question: What is the official C++ method of implementing a distributed program?
Answer: CORBA? But which ORB?
Assertion: You need to write a multi-threaded application.
Question: What is the official C++ method of using threads and handling semaphores/mutexes?
Answer: There is none.
The biggest advantage Java has over C++ is its standard library. Period.
The biggest advantages of C++ over Java (IMHO) are memory usage and parametric (compile-time) polymorphism w/ templates.
Universal themes regardless of language? Premature optimization is the root of all evil. Efficiency of design/algorithm will almost always win over choice of language (BASIC can be faster than C given different algorithms).
Use what works for you. Use the language that best fits the problem. Let's stop the language wars and get some work done.
- I don't need to go outside, my CRT tan'll do me just fine.
javax.servlet and java.rmi ARE in fact merely libraries (packages in Java-speak). The only thing that makes them "integrated" are their inclusion in rt.jar.
EJB is simply an umbrella term for RMI, JDBC, JavaBeans and JNDI with some convenience classes/interfaces.
Don't get me wrong. They are wonderfully useful and reasons for me to love working with Java, but they are not intrinsic to the syntax of the language any more than the STL is intrinsic to C++. They actually are merely "libraries."
- I don't need to go outside, my CRT tan'll do me just fine.
Already been done. It's called Smalltalk. And one of the reasons it did not take off was the fact that everyone already knew C (or a C-like language).
There is a reason that C++ has curly braces for scoping, parentheses for parameter lists and square brackets for array syntax.
There is a reason that Java has curly braces for scoping, parentheses for parameter lists and square brackets for array syntax.
There is a reason that Perl has curly braces for scoping, parentheses for parameter lists and square brackets for array syntax.
There is a reason that ECMAScript has curly braces for scoping, parentheses for parameter lists and square brackets for array syntax.
I sense a pattern here...
There is also a profound resistance to OO thoery in the C language camp that I still can't quite understand, but that is another story...
- I don't need to go outside, my CRT tan'll do me just fine.
Hunh? I hate to break it to you, but unsigned int and int are two different types. The only similarity they have is their size in memory. It's counter-intuituve to you because apparently you had false assumptions. Do not blame the language for this.
If your function were as follows (warning! useless template feature approaching!)
template <class T>
void swap (T& x, T& y){
T a;
a=x;
x=y;
y=a;
}
and you did this:
unsigned int a=1, b=2;
swap(a, b);
a and b are swapped, which is correct!
A little forethought with the design (and I stress "little") and we find, as you did, that there are two copies of our functions in the binary. Oh no! I've lost maybe half a kilobyte on my hard drive! Look at that extreme bloat! Whatever shall my 27GB drive do? A thousand of these programs and I'll have lost close to one megabyte! Oh wait! No... If I put this function into a library like I should do for all of my heavily reused code segments, I've still only lost half of a kilobyte of position independant code AND shared libraries offset the memory footprint increase.
The waste for a single instance is far from substantial. The waste from multiple instances is far from substantial. The waste from multiple references to an instance in a shared library is so insubstantial, it is laughable.
Worry about your overall algorithms before fretting too much over this. There's a reason we don't freak out over our programs fitting into (less than) 128KB of memory and taking up less space than is available on a cassette tape.
Premature optimization is the root of all evil.
- I don't need to go outside, my CRT tan'll do me just fine.
Oops! Totally forgot the last part of your curious position.
// no temporary
a[i++]=i++;
Hmmm... This is quite a problem. You're right in that it is quite ambiguous and implementation dependant. Let's try an alternative shall we?
a[i] = i;
i += 2;
- or -
++i;
a[i] = i;
++i;
- or -
i += 2;
a[i] = i;
Yet another thing I cannot seem to grok: why do coders get so obsessed about saving a line of text in source (which is supposed to be readable by humans by the way!) when the code output by the compiler is EXACTLY the same for all intents and purposes. In fact, by avoiding temporaries (you did know that "i++" causes a temporary variable to be created right?), it might be 0.0001 seconds faster (woohoo!). The important difference being that the first example is ambiguous to read even if there were a defined behavior. All of the others on the other and are completely clear to anyone regardless of their experience level provided they've have done any rudimentary programming.
Optimize your code, not your source.
16 bit ints are completely justified on a 16 bit CPU. If you think that's weird, you should check out the systems that have 36 bit ints (yes, they exist). Not only are some ints less than 32 bits, some aren't even powers of two.
- I don't need to go outside, my CRT tan'll do me just fine.
According to ISO 98 C++, your example should scope "i" to the loop. Don't blame the language for limitations in the compiler.
It's like blaming the authors of the U.S. Constitution because some representative in Congress tries to establish a law which contradicts the Constitution.
- I don't need to go outside, my CRT tan'll do me just fine.
"I think it is interesting that after less than a decade, C++ is being labeled as fossilizing. While its parent C is still very vital."
1) C++ was first released twenty years ago.
2) C++ is not fossilizing (where is your data that people aren't using C++ anymore?) The STL, a relatively new construct (less than ten years old), is being used more and more. How is that fossilization?
3) If C is so vital, then why are people flocking to Java and scripting languages?
C has its uses. C++ has its uses. Language X has its uses.
On the other hand, I agree with you that if Java adopts generic idioms and assertions, my reasons for using C++ will decrease dramatically. However, since we are talking about hypothetical futures, if C++ gains an easy to use garbage collector and unified thread and socket library, my reasons for using Java will decrease dramatically.
Languages are immaterial. Concepts are important. Use whatever language best describes the concept you are trying to present.
- I don't need to go outside, my CRT tan'll do me just fine.
It is pretty easy to do this using templates and coming up with something like:
integral< 32 > i32;
integral< 128 > i128;
or integral_at_least< 35 > which would give you a 64-bit integer or whatever is fastest and at least that size for any given architecture.
All you have to do is provide specializations for some of the bit sizes and define the others as recursive templates.
This does not have to be part of the compiler, just the standard library.
As for the having-different-signatures part, it is of no use, as far as I can see. The only reason to do that is to maintain binary compatibility in the face of changing type sizes. But this can't happen within the same architecture, so all you need is source compatibility. Besides, as another poster mentioned, it is a major incovenience for users of your code (users as in programmers that use your code).
I really hate this... there *is* a difference between a Language and a Library. C++ is a Language and STL is a Template Library (I won't go into my loathing of the STL as anything other than a compiler test suite). I really wish they'd stop putting this stuff in the Language spec. Make an ANSI C++ Standard Library Set spec.
Like in Java... it's a Language, a set of Libraries, and a Virtual Machine.
Brian Macy
Many other reasonable answers include such things as garbage collection, checked exceptions, portability of binaries ...
Great Windows SFTP Server!
The /Zc:forscope option tells the Visual C++ compiler to follow the standard C++ definition for the scope of variables declared in a for loop.
Is this true? We've been getting desperately annoyed trying to write code that runs on both VC and gcc by this. Unfortunately I can find no reference to this in the docs anywhere. Can anyone confirm this?
What I would like to see is an implementation standard for C++.
At least some way that I could link C++ code generated by GCC with others, such as Sun Forte. We use GCC for platform independence, but we are continually having to write stupid little C function wrappers around classes to get around all of the linking issues.
Then I might be able to do some code re-use at more than just the source level.
Jason PollockIt looks a lot like it would be pronounced like "cocks" because no-one is going to go through
the trouble of saying "cee-plus-plus-oh-ex".
They need to change that. . .
That's true, unless you're playing very pedantically; at any rate it's true enough to make it funny :-) Interestingly enough, "C#" is abbreviated as "dos" in Catalan, as in do-sharp, according to the docs for my local copy of Lilypond. (If you've ever had to watch The Sound Of Music you'll know what "do" represents :-).
perl -e 'fork||print for split//,"hahahaha"'
Bravo!
It's 10 PM. Do you know if you're un-American?
or does this story have a blue border? WTF?
How we know is more important than what we know.
yes, if I close my eyes the world will go away. Having a fuckwit writing news means there is one less competent person writing news which means I, and others who can recognise a dickhead, miss out.
How we know is more important than what we know.
Got a few spare CPU cycles? Help us test the 3.0 prereleases. You can download freshly-built and working RPMs from http://www.codesourcery.com/gcc-snapshots/ and run your favorite C++ through it.
The C++ library has been completely rewritten. It wasn't stable enough for 2.95 (or RH's 2.96), and since then it has depended upon recent changes in the compiler itself, so it didn't get included in 2.95.3. Someone else on this page was complaining that "even g++ doesn't have fully-templated iostreams like the standard says," but the new library always has. (It just hasn't been turned on by default in any existing gcc release, is all.)
There are other changes as well. Some really cool ones are already in the tree but won't be included in 3.0; we decided to wait until 3.1 for major user-visible features. The big (IMHO) change for 3.0 is the vendor-neutral ABI for C++ that will let you link code compiled from different compilers.
When will it be released? Sooner, if you help.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
Geez -- I haven't often seen such ignorance displayed with such force. You really ought to consider doing some reading on GC as a topic, and not rely on (I'm guessing :) experience with one really bad implementation.
:)
Properly implemented, GC has no impact on the classes interface, or even the lifetime of the objects. What it does accomplish is to allow the designer to concentrate on the problem semantics and ignore object lifetimes. There are real problems where this is a serious issue, and where you cannot design the problem away without implementing reference counting or some other poor cousin of GC. Semantic nets, and related AI type problems tend to have this characteristic.
And no -- sloppy thinking does not result in GC, it results in Windows applications.
The problem with getting a proper implementation is that GC would like to know the types of things in much more detail than the compiler ordinarily makes known to the runtime system. If all obects had RTTI type information, then GC is much easier to implement in a clear and correct way. If the standard prescribed hooks allowing implementations to provide GC, then we'd have it when we need it without lots of extraneous effort. G++ has one such facility.
hope this educates you a little
You presume too much. To my way of thinking, Java has some serious flaws that could have been avoided. Others have mentioned VM and the lack of independent standards -- I'm not so concerned about those.
What bothers me about Java are these two things:
(1) The thread primitives are not primitive enough. Per Brinch Hanson and C.A.R. Hoare demonstrated the minimum requirements for correct threading 30 years ago (IIRC) - the library implementation in Java leaves open some very hard to track down race conditions (Note that the fact that you have not seen the problem only means that you have not triggered the problem).
(2) Interfaces cannot contain code, so cannot provide behaviour. Multiple inheritance is prohibited (Yes MI is hard to get right, but sometimes it *is* the right tool for the job, with all alternatives being inferior). This leads to duplication of what should be common code.
Language design is really hard to get right, so there can be no guarantee of continued progress. Some new ideas will turn out to be really bad ideas. We have to try things out and see how they work in practice. I'm fairly certain that every language will be less than perfect because of the cognitive distance between how humans think and how computers work. What makes a programming wizard so amazingly productive is (imho) a well trained mind, and the ability to *really* focus on a single task.
All useful languages that I am familiar with are also equivalent to some Turing machine. You can always write a transformation to a Turing machine description (not that it would be *easy* -- they don't call it the Turing-tar-pit for no reason :). In turn, you can always write a transformation from a turing machine description to a common processor type machine (loosing infinite tapes in the process, but that is no real loss, since the original program has that same limit).
So -- I contend that you can compile *any* computer language that you can interpret. The only question that remains is whether compilation is useful for the language in question.
Well, you are right that I was digging at Windows. I've been astonished at certain types of thinking about program construction that is directly attributable to exposure to Windows and/or MFC. (I usually refer to that thinking as Windows/MFC-induced brain damage) It seems to me that the sloppy thinking occured when those interfaces were constructed (I don't imagine that they were designed....), but the effects carry forward to anyone who learns to program by being exposed to them.
;-)
But that was not the point of my post, really. I just like take every opportunity to point out the flaws of the MFC/Windows programming model.
You can use GC to cover up design flaws, just as you can misuse any feature of any language. The mere presence of GC in a design does not indicate sloppy thinking. It might. Or -- the presence of GC might indicate that the objects modeled have such indeterminate lifetimes that GC is the best solution to managing them. Before you rant on *that* being a result of sloppy thinking, consider the semantic nets I mentioned above -- they deal with real world data that is changing over time, and it is not clear when a node is no longer useful untill the last reference is lost or dropped. If the semantic net is multi-type, you might have a serious problem keeping up with the reference management, particularly when there are multiple referents, and no clear hierarchy. GC expresses memory management well under these circumstances.
I'm not saying that GC is the only solution here -- clearly reference counting would work, but it tends to obscure the code and has limitations (e.g. circular structures). IMHO, GC is the best engineering solution to that type of memory management problem.
Adding GC as an *option* to the language just gives me another useful tool. Your tool box can never be too full.
Irregardless, he has a point. :-)
------
No there are plenty more areas that warrant a gripe.
.h files. In fact, you would not need .h files anymore except for backwards compatibility. 'Course you'd lose the ability to make a header file do different things based on defined symbols, but that would be an advance IMHO.
The lack of an alternative to #include and 30+ year old linking technology sticks out in my mind as something that impacts both programmer and execution time. Fixing this would allow:
1. Losing the pointless duplication of declarations in
2. Virtual methods can be determined by the linker, so the programmer no longer needs to specify virtual-ness at all.
3. Virtual methods can be implemented by binary decision trees instead of jump tables. This speeds execution on pipelined CPUs. They can also be inlined when there are few overloads.
4. Inlining and template instatiation can be post poned until link given a sufficiently sophisticated intermediate format. In fact the compiler can inline any method or function.
5. No more name mangling.
6. Faster compiles -> no need to parse the same M header files N times for N files, once compiled, the intermediate format defines the interface to a module. Basically this is essentially global precompiled headers.
Could this be done and keep backwards compatability? I don't know, and I wouldn't care. I would personally convert all 5000+ of my companies C++ modules just for the performance benefit and future time saved.
Wow, so smug, and yet so wrong. Rather than explain in excruciating detail how narrow minded your response was, or possibly how poor or incomplete your education is, I'll forgo all that nastiness and help you out.
Headers are a kludge leftover from C++' C ancestory. They allow all sorts of nasty tricks, but generally are considered the simplest way to accomplish independent compilation units. A more complicated, but much more efficient and less error-prone way to do this is to devise a language in which you can annotate the methods, types, etc that you wish to be part of the interface for a unit. When the compiler compiles the unit source, a compact description of the unit's interface is stored _somewhere_ in your build environment. When you need to use the interface of another module, your compiler goes into that module's description and pulls out the information it needs without doing any parsing whatsoever. I would imagine you would get compilation speeds in excess of a simple language like C using this technique.
For a library supplier, they can use a simple tool to generate documentation from the source.
As for virtual methods, this is an implementation detail that really does not need to exposed in the language if it could optionally use better linker/object technology. The language implementation can decide which methods need to be virtual itself through global analysis at or before linkage. For any given method, it must be virtual if any derived class overloads it. Since current linker/object technology is incapable of maintaining this kind of information and some code generation would be required at linkage, a more flexible object code format and linking technology would need to be created, but we are talking about a new version of C++, aren't we?
Note that once you have the list of methods which overload a method, you can implement that method using a decision tree, each branch of which contains the code for the derived class. This avoids the pipeline stalls that you get with vptr virtual dispatch, which I might note is essentially forced upon the compiler writer because of inadequate linker technology.
All sorts of interestings things become possible and lots of C++ frustrations fall away when the antiquated C linkage mechanism is done away with. But I fear it is too radical a change or it can't be done in a backwards compatible way. So I'm not holding my breath.
Not necessarily a good thing. Redundance catches errors.
The only errors this catches are discrepancies in the header and source, which of course would be avoided by this feature.
Definitely not a good thing, virtualness is important when reasoning about a class. After a call to a virtual function much more state is uncertain than after a call to a non-virtual call
I disagree. Virtual-ness is an implementation issue which is exposed in the base class because of linker limitations. There should however be an overload keyword for methods in the derived class to make the intent clear and avoid erronous overloading, as well as a way to keep base methods from being overloaded intentionally.
The type information has to be represented somehow, name mangling is not really different from other means.
However with sufficiently advanced linking technology, no mangling need be done at all. Its a kludge to get around old linkers.
I don't seriously think the C++ committee would make any of these changes a reality, but I can dream. More likely a new high performance language will be created soon. There are so many issues in C++ due to its heritage, any new language with similiar (or greater) performance, features and a C-ish feel would be instantly popular, and probably take away both Java and C++ "market share" very quickly. It's an opportunity waiting to happen.
This ignores the idea that you want to be able to explicitly tell the compiler which functions should be allowed to be "virtualized." How would that work out if the compiler auto figured out which functions should be virtual? Would you replace virtual with a "no_virtual"
I think a keyword like "final" on a base method that you don't want to be overloaded, and a "overload" keyword on the method in the derived class would do what you want ( to avoid erronous overloading). With these kinds of changes, a new language would probably be required as it wouldn't be particularly backwards compatible.
Small Eiffel does some of this. Not that I advocate Eiffel per se. See:
http://smalleiffel.loria.fr/papers/papers.html
point 1: Class designers often do not know which methods will need to be overridden in derived classes, thus if they are kind they declare any usefully overridable method virtual. Now, dispite the C++ mythos of paying only for what you ask for, all clients of that class must now pay for the virtual table overhead even if nothing in their _particular_ application requires overloading of some of the virtual methods.
point 2: Only public/protected functions that are not marked to be un-overloadable would require this special processing. Most of the code generation could still be done at compile-time, but you'd have to allow for some flexibility w/respect to code layout and additional (small amounts) of code at final link. You definitely could not use existing object file formats.
Dynamic libraries are a difficulty with this scheme, but could be done by falling back to vptr tables for the classes that are exposted by the library.
point 3: As for virtual methods, a jump through a data table is more expensive because no speculative execution can be performed. This is true even for implementations that put jump instruction in the table. The pipeline is stalled until the vptr of the object is fetched. By contrast, even if the id of an object has not been fetched, decision trees can be speculatively executed, at least for small orders of overloading. Thus by the time the id is fetched, the correct code will most likely already be in the pipeline.
That would be extremely bad programming practice (making everything virtual). I would argue that a class designer that doesn't know which of his methods will need to be overridden in derived classes is either lazy or doesn't really know what they are designing.
This is just the nature of reusable software. If you design a library class with a method that does something useful by default, but want to make it replacable or extendible, in C++ you have to make it virtual, independent of whether or not it actually gets overrided or extended in a particular program.
Virtual method calls are less efficient than direct calls because of the following factors:
1. The vtable base has to be loaded from the object. There is no getting around this unless you've already got it in a register. If you are in a method of the same class, or you already called a virtual method of the object, you probably have it already in a register, otherwise you need to load it. A decision tree implementation also has this overhead.
2. Until this value is loaded in some form, there is no way to look ahead in the instruction stream-> the indirect calls are dependent on the vtable address. And yes there are multiple possibilities for the instruction stream, and they all depend on the vptr of the object being called. If there were not the case, a direct call could be used.
3. If the vtable is implemented by an array of function pointers, you've got another load to do before you can start filling the pipeline again. If it's an array of jumps, you're incurring only an extra instruction overhead.
4. The fact that the vtable, the functions themselves and the original code are usually at different address neighborhoods, you incur more stress on the CPU caches. This is statistical stress, which may not be a problem with any particular call, but overall more cache misses happen, on average, and in general.
5. It is impossible for compilers to inline virtual methods without global analysis, which is generally precluded from the use of dated linking techniques. This inability precludes an easy solution to #4
6. The previously mentioned need to make all methods that _might_ be overloaded virtual, especially for library code which is difficult for end users to modify.
In short, C++ vtable-based virtual methods incur at least one more instruction to be executed, probably a pipeline stall, can't be inlined, and cause more cache stress.
In Eiffel, every method CAN be polymorphic (I dunno if there is an option like "final") If the compiler can determine that a method has no overloaders, this case is is optimized (at least in reasonable implementations) as a direct call without you having to worry about it. This is the ideal, IMHO.
Redundancy is useless if it is mere copy/paste duplication with some minor editting. I can't imagine anyone dismissing Java because it lacks this division, on the contrary, it saves time, and given simple tools for extracting interfaces, does not have any drawbacks.
virtualness:
I don't disagree that thought must be given to the design of the base class, however, I don't believe a language should penalize you for allowing overloading on a method even if the method is not overloaded by any class in your link unit. Whether or not overloading is allowed by default is a matter in which I no particularly strong opinion, although I believe that C++'s default of non-virtual is mainly due to the inability to avoid the penalty in almost all implementations.
Nothing annoys me more than the "for (int i=0; iblah; i++)" scope bug (int i should be within the scope of the for loop, not the block of code containing the for loop).
Equally annoying is attempting to do something with templates that cause the compiler to freak out and crash. Once that happens you have to Clean everything and rebuild from scratch, after removing what caused the compiler to freak out (it corrupts files when it crashes like that).
Current VC support for templates is patchy at best. *sigh*
While having those types defined would be nice, don't fool yourself into thinking that having them would solve a lot of porting problems. Bit ordering is an annoying problem that tends to bite you in the ass when you don't want it too. Especially if your apps go between Intel & non-Intel CPUs.
The /Za flag turns off a lot more than just the for loop scoping "feature." User beware.
c) Its not a standard until Sun submits it to a real standards setting body. Until then its just as proprietary (in my mind) as Visual Basic, etc.
actually, it should be proprietary in the minds of everyone... the little TM (trademark) gives it away!
G.
Actually, the behavior he is describing is what is actually implemented in most cases.
:: scope-resolution operator.
During the base class constructor, the virtual function table pointer is initialized to point to the base class table, thus when the user written ctor code is called any virtual function ref will be to the base class ctor.
When the next level of inheritance's ctor is called, the VTPTR will be initialized to the derived class VTBL, and so any virtual will go to the virtual class.
During destruction, the process is reversed.
All that is needed is to formalize this behavior.
Close.
First: Though the usual implementation is via a vtable pointer, the spec speaks in terms of what virtual function is entered, rather than in terms of when the vtable pointer is stored, so that compilers are not constrained to use a vtable implementation.
Second: The current spec defines the behavior of calls during the constructors and destructors of the classes, but leaves open the behavior during the construction and destruction, and other initialization if any, of the member objects.
In terms of "storing a vtable pointer" the current standards allow the compiler to store the derived-class vtable pointer either before or after the member object constructors are called and/or other member initialization is done (or even at some arbitrary point during such initialization). I claim it should be tightly specified to be stored AFTER all other initialization (including any other automaticly-generated code) and immediately BEFORE the execution of the first line of the body of the constructor.
Similarly, it allows the base-class vtable pointer to be stored before the member DEstructors are called, after, or during. I claim it should be stored immediately AFTER the execution of the last line of the body of the destructor, BEFORE any member destruction or other automatically-generated code.
In the general form, the reasoning is as follows:
Member constructors (and other member initialization) are peers with base class constructors: They constitute the creation of pieces of the object, which are to be finished parts before the object is constructed from them. First they are constructed and initialzed. Once that is done the class' own constructor assembles them inito a composite object and initializes that composite object.
Until the pieces of the object are completed the object is just a collection of pieces. It is only during the execution of the body of the constructor that the collection progresses from a pile of parts to a unified, operational, component.
So calling the derived-class overriding of a virtual function before the derived-class constructor is executing is a mistake. It calls a function of an object that does not yet exist, rather than the corresponding function of the component piece, which DOES exist and IS initialized.
During the execution of the constructor, the author of the derived class can take whatever care is necessary to use only the features of the object whose underpinnings are properly initialized. While the member objects are being constructed the author of the derived class has no such opportunity.
On destruction the issues are similar. While the derived-class has had a chance to initialize, some of the underpinnings for the virtual functions may need to be torn down on finzliation. Calling a virtual function after its support structure is torn down is also an error.
Writing a code generator to store the vtable pointer at the proper moment during construction is trivial. Writing one to store it at the proper moment on destruction is slightly harder: The base class and derived class might be separately compiled, so either the base class must export its vtable pointer for the derived class destructor to store or the derived class must generate its own equivalent vtable.
My definiton means that virtual function calls in initialization expressions get the base-class overriding. But that's not a problem for two reasons: It's currently not specified, and the author can specify the overriding he wants by using the
Now, there is a problem related to this that I'd like to see addressed:
Consider a base class which exists to allow an object to attach to a list and have a virtual method called in response to events sent to that list. It is up to the derived class to overload a virtual function to handle those events.
This is exactly one of the reasons we wanted this definiton.
Now, ideally I'd like the base class to connect to the list in the ctor, and disconnect in the dtor. However, it is not safe to connect to the list until the object is fully constructed, as an asynchronous event may cause the virtual method to be called before the object is constructed. Equally, I want the object off the list before the dtor is called for the same reason.
What I'd like to have would be an additional two methods. The first would be called immediately after the ctor, the second immediately before the dtor. Thus, these calls have at their disposal the whole, fully constructed object, with all virtual methods intact and ready to go.
In the case of global objects or static objects, the compiler would generate a second list of function calls, to be called after the init code has iterated through all the static constructors (and another to be called before iterating over all static destructors).
With the definition I'm proposing you have a solution available, and it doesn't require two overridings of the function. Consider:
First: Create a construction-progress member variable, and initialize it to the "no progress yet" state. This variable is thus initialized before the vtable pointer is changed, and it will persist after destruction.
Second: The vtable pointer is changed - but any of your virtual functions that need construction that isn't complete can check the state variable, and do what is appropriate for the current level of construction. (This is probably making a call to the base-class version of the function and returning the restut.)
Third: As construction progresses through stages that enable various virtual member function behavior, the constructor updates the state variable, "turning on" the fully-constructed behavior, or any intermediate-step behavior, as necessary.
By the time the object is fully-constructed and the constructor exits, the full behavior of the member functions is manefest. The teardown sequence proceeds similarly, but in reverse.
If you like you can implement the "state variable" as a set of "pointer-to-function" variables, to eliminate the explicit tests at the start of the member functions. The "real" virtual member function would be something like:
foo(args) { return (*this->current_foo)(args) }
It's not quite as execution-time efficient as your double vtable pointer store, but it gives you arbitrarily fine control without extra compiler mechanism.
Having done a fair bit of multithreaded C++, I am of the opinion that, if they are going to standardize on a threading library, they are going to need this sort of hook.
Check.
Though originally intended to handle non-multithreaded cases (such as the non-polically-correct examples of garbage collector pointer-walks and error-exceptions during construction), this scheme is also adequate to support correct behavior in multithreaded code.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Suppose:
you are constructing an instance of a derived class
one of its base classes has "published" a pointer to the partially-constructed instance
the class has a virtual member funciton
the member function is overridden by this class
the class also has a member variable of a class type with construction
the constructor of the member variable (or something it calls) finds the published pointer and calls the virtual member function.
What happens?
My claim is that such a call SHOULD be legal and SHOULD call the BASE CLASS version of the member function. Similarly, during the execution of the DEsctuctors of the member variables you should also get the BASE CLASS version of the member function. You should get the derived class version exactly from the beginning of the execution of the first line of the body of the constructor through the end of the execution of the last line of the body of the desctuctor.
The reasoning is too involved to go into here. Suffice it to say that:
It's a consistent generalization of the philosophy of the C++ constructon-destructon semantics (and of the way that the C++ semantics differs from those of Objective C and Smalltalk.)
It's an compiler implementation that is allowed by all the levels of C++ standardization.
There's a LOT of neat stuff you can do with this guarantee that you can't do without it.
There are a lot more opportunities for programming error if your compiler doesn't work this way. (Not to mention the issue of code that works find with a compiler that does it one way but breaks when run through a compiler that does it a different way.)
The original C++ work didn't specify the behavior in question. The first ANSI standard explicitly left it open. The revised ANSI standard not only explicitly left it open but said "don't do that". B-(
At the time I first proposed it (about 10 years ago) we looked into a sample of the compilers on the market. There are four binary combinations of member constructor/destructor and base/derived version of member function, of which I claim one is "right" and the other three "wrong":
Cfront and the Cfront-derived C++ compilers tested (Sun, SGI) got it "wrong" one way.
The three IBM PC compilers tested got it "wrong" a second way.
Gnu G++ got it "wrong" the third way.
so standardizing on this semantics wouldn't favor any particular vendor's existing product.
IMHO this somewhat obscure issue is one of the major impediments to C++ achieving its potential as an object-oriented language, and it is unfortunate that is wasn't "fixed" in one of the previous standards.
Perhaps there's one more chance here.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
It will be great when C++ has many of the rich data types java does. I'm certainly looking forward to it, but I'm sure I'll still write everything in C anyway.
They should annoint a conformance suite, so that things like VC6 won't be able to claim "standards conformance", when they don't even handle exception specifications properly.
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
It isn't usually a good idea to compare languages so narrowly (better/worse) outside of a specific domain. It gets unneedlessly emotional when both are the obvious best choice for different domains.
Also, lousy syntax isn't usually a problem. Consider that COBOL and Perl have two of the Worst Syntaxes In The World.
While your 'new' illustration has value, cars are far too easy to produce. We seem to get maybe four or five useful new programming languages a decade. There's a reason. It takes a lot of work and hassle for a language to mature. You can learn from the mistakes of the past, but there are still plenty of new mistakes to be made.
Jack Valenti and the MPAA are to technology as the Boston strangler is to the woman home alone
I don't know what that means.
Jack Valenti and the MPAA are to technology as the Boston strangler is to the woman home alone
Forgot some ops too
// a = b XOR c
// a = a XOR b
// a = NOT a
/. how come I can't edit my comments? :)
o) ~ would be the new XOR op.
e.g.
a = b ~ c;
a ~= b;
o) ! would be used for binary not as well as logical not.
e.g.
a = !a;
Errata:
The fixed point should read:
fix < 8,8 > fix < 8,24 >
And the static cast should read
static_cast < int * > (pC)
P.S.
Hey
I've been thinking about how to make C++ better in my spare time for the last year or so.
// array 10 pointers to function returning int
// array of pointers to func.
// pointer to func, no more stupid parenthesis matching
// 0x1A2
;-)
(Unfortunately my notes are at home, so this isn't the full feature set)
Here are some comments I'd love feedback on.
o) New operators:
^ would be the standard math power operator. The compiler would optimize ^2 the much it does now with *2.
@ would be the pointer derefence op. (Allows you to search for where pointers are being used)
?= (replacement for ==, since it is WAY to easy to get = and == mixed up)
$ is also another operator for users.
o) STANDARDIZED and PORTABLE types
NO MORE "long long" crap.
int8, int 16, int32, int64, int128 (signed int's)
real32, real64, real80 (floating point)
fix (fixed-point)
char8 (8-bit ascii)
char16 (unicode-16)
char32 (unicode-32)
int would be the "native" integer type for the cpu.
float would be the "native" floating type for the cpu.
o) New keyboards
"func" would preface all functions/methods. (helps the compiler out, and lets editors be able to expand/collapse functions easier)
"macro" would force the function to be inlined.
"include" is part of the language. No longer needs that ugly pre-processor hack.
o) Cleaner Syntax - CONSISTENT reading of right to left.
Pointers would bind LEFT (instead of right in C/C++)
i.e. Pointer to a function
The old C++ way: new (int (*[10])())
Easier C^2 way: new func int() * [10]
e.g.
func int () * pFunc;
o) C style implicit () casts gone. Only C++ style casts. (Allows for searching of casts)
e.g.
C++ way:
char *pC;
int *pI = (int*)(pC);
*pI = 3;
C^2 way:
int *pI = static_cast(pC);
@pI = 3;
o) standard way to turn OFF implicit up-casting
o) Binary constants. (We have decimal, octal, and hex. Where's the binary notation??)
Preface numbers with "Zero Z"
e.g.
const int mask = 0z0110100010;
o) "typedef" and "alias" would be extended.
typedef would make a NEW type. (Compiler wouldn't throw away the newnames)
alias would behave like the old typedefs currently
Maybe it's time to download gcc 3
*shrugs*
Seperate namespaces can be very usefull when you are using more than one third party tool and THEIR code, not yours, have common object/method names.
Don't get me wrong, I hate C++ and its sillier "features", but namespaces are one of the few goodun's.
I suppose I'm not too threatening, presently, but wait till I start Nautilus
One reason that Java doesn't have genericity (templates) is because the VM spec cannot change to include it without breaking backwards compatibility. Or something like that. Look for OOPSLA conference papers from '99 and you'll find something. From what I remember there is an interesting read, if a little mathematical.
One thing I MUCH prefer over Java is that there is a single memory management scheme for object references. None of this on-the-stack vs passed-by-refernce vs newed-and-passed-by-pointer vs passed-by-reference-from-a-newed-array business going on. You only have "its a reference and it may be nill".
I have to work with code that uses 4 or 5 third party libraries. Dealing with the different object allocation schemes at the same time is a real pain in the ass, especially because it's also CORBA based and we have to deal with inter-process allocation and deallocation also.
blather blather blather
I suppose I'm not too threatening, presently, but wait till I start Nautilus
Damn, you beat me to it.
--
python -c "x='python -c %sx=%s; print x%%(chr(34),repr(x),chr(34))%s'; print x%(chr(34),repr(x),chr(34))"
Two years ago I used SunPRO with STL, and I didn't found any deviation from the standard. Everything worked as expected (unlike g++, which was useless for C++ back then).
Java flaws?
Co-variant arrays.
I would hope that any changes to the standard will focus on the C++ Standard Lib and not so much on language semmantics/features. The C++ library is in need of some serious features. While I recognize why they had to stop and finish, the work is losing ground to more complete libraries in other languages. The STL needs to be completed, and dare I say, some of the implementation should even be standardized. Certainly, the interfaces should be standardized. My God, lets make hash tables official, and pick an implementation. Also, the iostream libs need to be expanded to include asynchronous I/O, more usable streambuffers etc. Also, the standard needs to officially ditch strstream and replace it with string_stream. As for threading, well Posix has pretty good threads, although events could be wrapped up a bit neater (like dare I say in win32). As for handles and such, it would be in the C spirit, as the standard C lib has things like FILE and such.
Someone you trust is one of us.
Yes, mdev 7.0 is probably one of the most compliant C++ compilers out there. It is one of the few linkers than handles template-objectfile redundancy propperly without tedious pragma's and bizzare typedefs in cpp files. Also, the msdev implementation of STL and IOStreams is to the letter of the standard with full template iostreams (unlike g++ non-template IOStreams). However, msdev's implementation includes nothing that is not in the standard (like hashtables), except auto_ptr. All in all, Microsoft has embraced C++ big time (MFC and especially ATL). Frankly their devotion to that sad ancient religion, hasn't helped them conjour up the stolen data plans nor given them clairvoyance enough to learn the location of the rebels hidden fort...kha..cc.cka..aaak.
Someone you trust is one of us.
a) Its tied to a VM.
b) Its frameworks for GUI development try to be a least common denominator at the expense of running well on any given platform.
c) Its not a standard until Sun submits it to a real standards setting body. Until then its just as proprietary (in my mind) as Visual Basic, etc.
Just my 2 cents
Wow, so this is what interests you people. No wonder us MBAs can't relate at all! I tried writing a simple C++ program and thought I did alright, but all the stuff you guys are talking about just goes way over my head. Good thing I dropped out of CompSci and became a business type guy - I couldn't hang for sure.
This post brought to you by your friendly neighborhood MBA.
I'm glad to see he still beleives that users who don't use a feature shouldn't suffer a performance hit for it being part of the language.
As long as that's adhered to, I imagine I'll keep using C* for the forseeable future. If they add things that cause a performance hit for everybody, I and the scientific community will probably stick with an older version, even once it's obcure. Just look at how much Fortran 77 is still being used!
Personally, I really like the fact that I can write one section of code in a very generic OO manner, but then have the inner loop essentially in C. I try to get the advantages of C++ while avoiding the performance pitfalls in the most time critical parts of my scientific codes.
its called java.
nothing shall exist 'twixt c and java.
'cept python. mayhaps.
call it (c + 2), get rid of all those horrible side effects!
As for virtual methods, this is an implementation detail that really does not need to exposed in the language if it could optionally use better linker/object technology. The language implementation can decide which methods need to be virtual itself through global analysis at or before linkage.
This ignores the idea that you want to be able to explicitly tell the compiler which functions should be allowed to be "virtualized." How would that work out if the compiler auto figured out which functions should be virtual? Would you replace virtual with a "no_virtual" specifier? Changing explicit virtual declaration to an explicitly not virtual declaration?
I'd be interested to see the pro's and cons of decision tree versus v-table. Any good links?
int* pi = malloc(sizeof(int));
That's an illegal C++ statement!
It's technically not legal in C either, but compilers accept it since they assume they know what the programmer meant.
int* pi = (int*)malloc(sizeof(int));
Now, that C++-version is legal C, but it is *poorly written* C code. Any C programmer worth his salt would frown on a program littered with such statements.
What are you talking about? That's perfect code. You should always cast your return values to the approriate type. It enforces type checking. Doing otherwise can be dangerous. Anyone not doing it should be immediately shot. Perhaps you should check out the Ten Commandments for C Programmers. Specifically, commandment 3 and 4. Malloc is a library function which returns a (void *). That is an illegal pointer to dereference, modify or use in any meaningful way. You have to cast it to use it.
Most modern compilers often just do it for you, but assuming a compiler will do it for you reduces portability. Also, subtle bugs can appear since the compiler has to interpret what you meant. This case is pretty clear what the intention is, but more complicates situations are sure to come up where the compiler will guess wrong and you'll be sitting there scratching your head wondering why your program is segfaulting.
-----
"Goose... Geese... Moose... MOOSE!?!?!"
Higher Logics: where programming meets science.
In ANSI C you are always allowed to assign void* to another pointer type. In fact, that is what void* is for. Adding a cast buys nothing.
Adding a cast provides consistency, clarity, good style and correctness. The compiler may not care, but it will sometimes misinterpret what you mean, and your programming colleagues will thank you for being clear in your code.
Moreover, adding a cast can disguise the fact that you've forgotten to #include stdlib.h. If you forget to include this header (which has the prototype for malloc), then the compiler will assume that malloc returns an int.
How often does that happen? You're telling me that I should always program in bad style for the odd time I might forget to include stdlib.h? I've forgotten to do it before, and that kind of mistake is always immediately obvious. And if you do it often enough for it to be a major problem, I suggest actually paying attention to what you're doing. I'm not flaming here, but honestly, that's like forgetting how to add 5 and 6. There might be the odd time you get it wrong, but it only takes a moment to realize your mistake. If you're consistently adding 5 and 6 wrong, then you might want to go back to grade 2.
Normally, this would fail to compile when you try to assign it to a pointer. But if you have included the cast, your program will compile and silently mix integers and pointers. This will work on a machine where pointers really do have the same physical representation as ints, but will fail elsewhere. Thus, not only is the cast not needed, it actually makes your program more prone to portability bugs.
I think that saying 'programming according to the language standard reduces portability' is a ridiculous statement. But I just noticed a possible source of misunderstanding between us. It's in the line:
int* pi = (int*)malloc(sizeof(int));
Which I said was correct. It is NOT correct even with the cast. It's valid, but not correct. That statement is requesting an int and assigning it to a pointer. That should read:
int* pi = (int*)malloc(sizeof(int *));
or
int pi = (int)malloc(sizeof(int));
Which ever he meant. Those are correct statements. The first was an oversight on my part. Perhaps that's what you meant about decreasing portability due to differing implementations of (void *) and int? (in which case I would agree with you because it's bad programming)
The fact that the previous, incorrect statement would be legal in C++ worries me even more. Perhaps the original poster mistyped?
-----
"Goose... Geese... Moose... MOOSE!?!?!"
Higher Logics: where programming meets science.
Huh? As I read it, the original line is quite correct: malloc a chunk the size of an int, treat the return pointer as a pointer to int, and store that pointer as 'pi.'
*sigh* I'm studying for exams, and my brain hurts. Forgive my mistake. You and I(in my original post) are correct...
-----
"Goose... Geese... Moose... MOOSE!?!?!"
Higher Logics: where programming meets science.
Cleaner does not always mean clearer. I don't find your way clearer at all. Let's propose a hypothetical(yet common) situation. C requires you to declare all variable at the beginning of any block. You declare an 'int *p;' at the start of your function. About twenty or so lines down, you're tracing through some deeply nested some 'if' statement or some loop. In an average program, you'd normally have quite a few things to keep an eye on. You may have some structures with their own members being read, swapped, deleted, looping variables, etc., then all of a sudden you come across the following line:
p = malloc(sizeof(int));
Since C is so versatile(sometimes painfully so), I can only hope but wonder at what the person who wrote the code intended. What is p? I'd have to go back up to the declaration to make sure it's an (int *) and make sure it is what I think it is, and not some other funky magic the programmer was attempting.
Proper casting encourages good style and (more) correct programming because it forces you to think about what you're doing instead of blindly throwing pointers around(which, if you've ever done any C programming, you know is an easy trap to fall into). Seeing code that casts everything properly shows me that the person put a little more thought into their code. I'd more readily trust that kind of code.
I'm not suggesting it happens often. I was just pointing out a potential drawback to casting the return value of malloc, in addition to the fact that it accomplishes nothing.
I know you were trying to say it was a drawback. In my opinion, you're example was pointless. It's like saying you need the proper sequence of steps to start a car, and if you don't follow them the car won't start. That's just the way the world works, and you won't find anything that doesn't have it's tradeoffs and drawbacks. Your example was just a nitpick.
The standard says that the casts are unneccessary.
If the standard said that casts were unnecessary, there would be no built-in type checking in compilers. Also, it would be impossible to convert between types such as int(32-bit in GCC) and chars(8 bit). Alot of common code would be completely invalidated without casting. In short, no, casting is quite necessary.
If you have included stdlib.h, this code is correct, with or without the cast.
No, it's not correct(in that it won't do what you expect it do), but it is valid code.
Btw, I just looked in my copy of K&R2 and noticed that they cast the return value of malloc. Their influence over what is considered good C style is (rightfully, IMO) powerful. Then again, K&R also allow their hello world program to fall out of main() without returning a value...
Since you have the K&R2 book, perhaps you should check out page 142, near the bottom(just before that code snippet), quoted here for convenience: The only reason that you can use the allocated memory without casting is because compilers cast it for you. Unfortunately, this leads people to believe that you don't have to cast things since they believe the compiler will handle it for them. But like I've said before, the compiler will not always be right in guessing what you meant and then you'll just be left scratching your head wondering what's wrong.
As for the hello world program, it seems they only do it for the first chapter. I'm sure they were just trying to concentrate on getting some key points across and not have to explain every niddling little detail to a beginner.
-----
"Goose... Geese... Moose... MOOSE!?!?!"
Higher Logics: where programming meets science.
What guarantees do you have that this be a 16-bit unsigned integer. Unsigned yes, but 16-bits? Guarantees? I've never seen any.
Besides, try 32-bits or 64-bits.. They're more useful anyways.
- Steeltoe
http://www.debunkingskeptics.com/
A couple of months ago, I decided to learn Java instead of C++. These are the reasons why I wanted to use Java instead of C++:
1) It was platform independent. I wanted to be able to create programs that didn't discriminate on the platform being used. Mac users and windows users should also be able to use any GNU GPL program that I write. Sometimes people can't choose their platforms. (Like me at work!)
2) It's more advanced in features than C++. It does the memory allocation and dellocation by itself. With a JIT (Just In Time) compiler, the code is as efficient as C++ programs so I've heard.
The only reason not to use Java is that it's proprietry. That bothers me but not that much because Sun is IMO a trustworthy owner and I believe they will keep the Java technology innovative. I would like Java to become a standard.
Mark
vi
:s,JAVA,C++,g
:s,JVM,Vtable,g
Note that it now reads like something I read 8 years ago.
LMFAO
Every age has its luddites.
roflol
From comments made at the meeting, it appears that Visual C++ 7.0 will be significantly better. Stroustrup said that he didn't even try programming on one popular implementation (I don't think he said Visual C++, but it was implied) until the latest drop, in which he said things now work correctly. If nothing else, the for loop scope is correct. :-)
I switched from GNU C++ to Visual C++ in 1996 (change of jobs) and found that VC++ 5.0 was lot closer to the standard in the areas I cared about (library, since they used Dinkumware) than was g++. For the base language, especially templates and catching incorrect constructs, I found Microsoft and gnu both pretty dreadful.
The April 2001 C/C++ Users Journal has some results from conformance testing. There are conformant compilers, and then there are popular compilers.
Thats odd, as I remember it the C++ standard wasn't finalised until around 1998
Right. I should have said "Draft Standard." But I don't think the template stuff matched any specification. My most memorable g++ bug was that member initialization occurred in the order members appeared in the initializer list, not the order of declaration.
As for Microsoft, their compiler - when it worked at all - tended to produce correct code. YMMV.
All your compilers are belong to us!
Why not use operator overloading? Overloading operator -> for a Handle class (probably a template class) fixes that problem quite cleanly. It also makes porting to other platforms easier (and let's face it, Mac handles were a hack dating back to the 128K days). I always wanted to do that when I was programming on the Mac, but at the time there wasn't a good C++ compiler available.
And what about partial specialisation of templates?
Thats not in, is it?
Oh, and FWIW, auto_ptr *is* part of the standard.
Thad
Thad
Bjarne Stroustrup recently had an interview with LinuxWorld where he outlined his plans for the future of C++. Here's an in article that analyzes and contemplates the ramifications of these changes.
Don't expect these changes anytime soon though. From recent ACCU meetings it seems that most of the C++ standard from 1997 still hasn't been implemented now let alone new libraries that are yet to be designed. The soonest I see any of Bjarne's ideas being usable by developers and standardized is 2005 if the rate of compiler and library development continues at the current rate.
--
File system structure technology matured years ago, so it's quite easy to integrate such things into a standard library, but user interfaces are completely different -- many of them, including the Microsoft Windows user interface, are still rapidly evolving today. Any attempt to try to standardize them would more than likely backfire, since every UI would have different constraints and features. Who's to say which ones are correct and which ones are not?
I used up all my sick days, so I'm calling in dead.
--
--
I like to watch.
I've often thought, however, that it would be really great to have a direct C++ port of Javadoc. I use Java as much as I use C++, and I've really come to like Javadoc.
- Javadoc-umentation tends to be more accurate, because since the documentation is in the source code, programmers have less of an excuse to make undocumented source changes.
- Javadoc shows you sub- and superclasses automatically, which makes both development and maintainence of others' code much faster.
- Finally, it creates shiny PHB-friendly webpages for your department intranet with no extra work.
:-)
I've heard that Javadoc can actually be coaxed to work with C++ code, but I've yet to play with this.--
--
I like to watch.
C++ could possibly include standard libraries for threading, but that would require too much cooperation between competing OS vendors, would require a shite-load of work, and in the end the hackers would end up using faster OS-native schemes anyway. They could also possibly add some standard ODBC stuff, but since ADO is now preferable on Microsoft platforms, it might not be worth the effort.
Lack of a standard C++ distributed object model sucks. Really bad. But to add something WRT that to the standard, they'd have to design their own, to avoid showing bias towards a vendor. So we'll continue to use CORBA on UNIX and DCOM on NT.
I feel that the committee needs to reevaluate its scope before going forward. If they add too much to the standard library, C++ will end up being just like Java, in that everyone always does things the same way, and that the control of entire industries will be in the hands of a single group of people. Some would see that as a good thing, but not me.
Windows is the "standard" operating system for most people, but on Slashdot, the use of alternative systems is encouraged. I feel this is a good thing because it adds variety and a Darwinian heterogeneity to life. It doesn't make developer's lives any easier -- do you think game developers are happy about the prospect that in the future they'll have to write for Linux in addition to Windows? The only solution is a standard cross-platform solution (why, I think Sun has one!), which puts us at the mercy of either a Evil Bad Corporation or a stagnant standards body.
Which is best? Freedom, choice, and the endless complexity associated with it? Or bondage, lack of choice, and the ability to relax and not worry? C++ has always seemed to be about the former -- it's not simple, but it lets you do whatever the hell you want. The latter is the domain of proprietary corporate languages such as Delphi, VB, and Java. There's not necessarily anything wrong with either camp, but I think that it's too late in the game for C++ to change direction.
--
--
I like to watch.
--
--
I like to watch.
Merlin will be very cool... a logging API, the new JDBC libraries, all sorts of cool stuff.
Yeah, on $500k+ Sun boxes. If you're app doesn't scale then buy a bigger box.--
--
I like to watch.
:)
Wait a minute. A large number of /. readers are complaining about MS C++? Why should we care if it is good or bad or if it is out of date or not? We are Linux users are we not or am I hearing that the majority of us are using MS C++ which means you must be developing for M$. Please tell me this is not the case. Ok. :-)
---------------
Sig
abbr.
Karma stuck at 50? Add 2-5 inches.. err.. 2-5x Karmas Count to your pen1es.. err.. Karma all naturally and private
Troll.
Jordan Bettis
``Wherever you go, there's another stupid sigfile quote.''BCPL is the language frome which B was begot.
Larry Wall talked about it in a speech once (might have been Postmodern) where he joked that the replacement to C should be called P, Going through the letters of BCPL.
So, in 2090, then, we should be programming in L.
Jordan Bettis
``Wherever you go, there's another stupid sigfile quote.''You open a new window in your editor & write a C program. Then you remember how nice life was before fascist pedantic arseholes decided to take over the world.
C++ is disgusting.
rmstar
Wow....C# is the one word answer??? You are implying that the language is going to be OPEN for everyone to use, and the source available on every platform then so that security flaws could be inspected by everybody? If that is true, it really would be the answer, wouldn't it?
Time is what keeps everything from happening all at once.
Seriously, couldn't some work be devoted to finding that small language that is supposedly screaming to get out of C++?
"When the compiler sees a destructor it generates a Finalizer() method, so that when the last object reference is released it is added to the finalizer queue. The Finalizer() method will call the destructor. Finalizers are discouraged for performance issues and because you cannot guarantee when the clean up code will be called."
That's equivalent to Java finalizers, not C++ destructors. Different and less predictable semantics.
Yeah, becuase it splits evenly into two 16-bit values. This was good for LISP (which was along with Fortran pretty much the only game in town as far as high level languages go at the time (we're talking PDP's here) from what I've heard), as the "low moby" (is that the right term? the "low" half of the 36-bit byte) could hold 16 bits of data, and the "high moby" could hold a 16 bit pointer to the rest of a list structure. The two correspond to car and cdr respectively, I think. I don't hack LISP, so please forgive me if I've gotten that backwards.
--
News for geeks in Austin: www.geekaustin.org
News for Geeks in Austin, TX
Take a gander doxygen (http://www.stack.nl/~dimitri/doxygen/) or doc++ (http://www.zib.de/Visual/software/doc++/).
They're both like JavaDoc for other languages such as C/C++ supporting HTML, LaTeX, etc. as output formats. Good docs (esp. for OO projects) are important, and these two tools let you make them pretty easily. Yeah, more time consuming than // or /* ... */ but you get more for your effort too...
--
News for geeks in Austin: www.geekaustin.org
News for Geeks in Austin, TX
a user interface, cross-plattform like swing, as fast like it should be... and most stuff java has, without the need for the virtual machine ..
You might want to take a look at GCJ if you want to compile Java language code into native binaries. GCJ's class libraries implement most of Java 2's APIs (RMI and AWT are not finished; volunteers are welcome to help).
Will I retire or break 10K?
Let's take the following function
void swap(int& x, int& y) {
int a;
a=x;
x=y;
y=a;
}
Now do this:
unsigned int a=1, b=2;
swap(a, b)
a and b remain with 1 and 2, which is wrong!
Why?
Because when they are cast they get put into temporaries, and the reference now acts like a call by value (the temporary is changed, but NOT copied back - the changes are lost)
Correct me if I'm wrong, but this sounds like a problem with the compiler. Temporaries should be considered const. You should only be able to implicitly cast an unsigned int to a temporary int if the reference in the argument list is a const reference. I tried your program on my compiler, and it barked at me.
As an even less useful piece of information, I believe C's precursor ("B") got its name from the place it was developed - Bell labs.
A useless piece of information, mainly because it's incorrect. C came from B. Where did B come from? A? It actually came from "BCPL" (Basic Combined Programming Language). So what is the next programming language going to be called? D or P? =)
Perhaps the dillemma means we are forever doomed to use names like C++, C#, etc.
-In C, I can be assured of minimal compiler overhead/bloat
What makes you think that C++ is bloated? I used to work on some realtime systems, and don't think the code was bloated. We used assembler inserts in the internal loops and always checked the machine code generated. We didn't use STL, or RTTI or other new stuff, though.
-In C, I can use modules/libraries that were written in assembly language without having to worry about name-mangling or things like that
You can have the same in C++
-With C, I don't have to search through a class-browser to find a function that I need
I don't see a big difference between finding a function and finding a method. If you can leave without code browsers in C, you will not need them in C++. Function overloading makes life more difficult, though; you're right here.
-I can actually use C to write an operating system
Well, we all know some operating system written in C++, but I would not touch it ;)
It's not like I'm advocating C++. I personally see some big problems with C++ and its OOP. But your list of problems is definitely not something I experienced, and I've been working with C++ since the end of 80-s.
That's probably one of the areas in which C++ is better than C. C++ is strongly typed (it has to be or overloading wouldn't work) and therefore errors like this will always get picked up whether you include stdlib.h or not.
Having said that, if you use the -Wall switch on gcc the error of not including a prototype will be picked up (as a warning).
Personnally, I'm in favour of putting the cast in because it makes the programmer think about the return type of malloc. I have seen too many errors similar to:
char c ;
c = malloc (sizeof (char)) ;
which gives an error if you have included stdlib but not if you haven't.
I guess the fundamental problem is that the whole error checking of C is inadequate and that is one of the few problems I have with that language.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
I think that's a good point (some paragraphs would have helped). M$ seems to be constantly revising the environment that programmers for Windows have to deal with. Can you remember DDE, replaced by OLE, replaced by COM (the same thing really) replaced by whatever .Net is going to use? Can you remember ODBC replaced by ADO or is it Ole DB or something? Now according to the latest MSDN journal, MAPI is obsolete. Just think of all those MAPI based applications that have got to be rewritten. They also had a go at their socket API to make it more M$ like and slightly less BSD socket like.
A cynic would say that M$ does it to keep the revenue flow of it's MCSE department healthy. Or maybe to keep it's competitors one step behind.
BTW has anybody noticed, that even in POT mode the HTML paragraph tags still get interpreted as HTML.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
Geez -- I haven't often seen such ignorance displayed with such force.
And no -- sloppy thinking does not result in GC, it results in Windows applications.
I haven't often seen such ignorance.... In what way does sloppy thinking result in Windows programs? I think this is just a snide dig at Windows programmers born from sloppy thinking.
Anyway I think GC hides sloppy programming and given that most programmers, even the ones who have been programming in C for 20 years are sloppy programmers, GC is probably a good thing. It means we might get some code that works properly.
BTW about 18 months ago I saw a demo of Veritas' Cluster services with an admin console written entirely in Java. Veritas were prepared to admit at the time it had a memory leak, so garbage collection is not a panacaea.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
Yeah, I'd like:
typedef unsigned short int uint16 ;
uint16 i ;
unsigned short int j ;
i = j ;
should throw up a compiler error or warning.
That also means you could overload functions differently for unint16 and unsigned short int. and enums etc.
I completely agree with this. Obviously, you can use a cast if you really do want to assign one type to the other.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
How about C+=2 ?
They'll probably get it working on Macintosh, seeing as how that's the only other platform they currently deliver apps on.
for(int i=0; i<10;i++);
still puts the i in the wrong scope according to the standard. And don't get me started on the template non-conformance issues.
I hope you're right though. It would be so nice to have a compiler from MS that is decently standard compliant.
When will we see a mainstream language implementing multimethods (as in CLOS for example)?
Relinquish
Yeah, Windows CE on hand-helds and Windows XP on PCs will be the 2 platforms.
Just because it CAN be done, doesn't mean it should!
I'd say templates and temporaries should go.
Let's take the following function
void swap(int& x, int& y) {
int a;
a=x;
x=y;
y=a;
}
Now do this:
unsigned int a=1, b=2;
swap(a, b)
a and b remain with 1 and 2, which is wrong!
Why?
Because when they are cast they get put into temporaries, and the reference now acts like a call by value (the temporary is changed, but NOT copied back - the changes are lost)
I tested it and confirmed the counter-intuitive bad behavior.
Okay, so let's use a template for it to avoid the "deadly" casting, and instantiate int, int and unsigned int, unsigned int versions.
I tested this two. 2 different copies of IDENTICAL machine code.
Not much waste, but for big functions, the waste becomes substantial.
Templates are a hack.
Making the user worry about temporaries is a hack.
(The value should get copied BACK if it is call by reference. And it needs to handle the aliased reference case, e.g. a function that takes 2 references that is called as foo(a, a) and declared as foo(int& x, int& y) should have changes in x reflected immediately in y and vice versa).
And they need to ditch "implementation defined" behavior. Pick a behavior, and MANDATE it. Evaluate function arguments left to right, one at a time, and THEN call the function. Make a[i++]=i++ have a defined meaning. Make ints of less than 32 bits illegal. Heck, force standard bit sizes of the legacy types, and use int32, int64 for future code.
Those are just some ideas.
This is not meant to be a troll, you have to admit ambigity in the language is bad, and 16 bit ints are an abomination...
Just because it CAN be done, doesn't mean it should!
Their goals of avoiding stagnation and fossilisation are admirable, but as an active developer (and student) of C++, I find this to be counterproductive. Thinking about new constructs and definitions is always a good goal; redefining the standard that can hardly be considered standard if divisive and stupid.
Just my $0.02.
The middle mind speaks!
You can't initialize a vector, etc, with any iterators you want, because although the constructor is supposed to be templated to accept any iterator types, it isn't -- it only takes iterators for that container currently.... I hope this is fixed in 7.0 too.
I was thinking about this earlier today, and I think that what's really needed is a language that forces you to define your types before you can write any code. It should force you to define them in a simple language describing the number of bits, signedness, etc... Then, your compiler could just tell you whether your processor could support your spec or not, and you could just change the spec when you switched platforms, or got new functionality in a processor.
Java gives me Diarrhea.
I do have a problem with the application of GC to an entire language... I believe that the applications that would seem to require a GC-like algorithm are very rare in commercial software, (as you mentioned, more prevalent in AI)...
Maybe C++ could make it easier to do GC on specific classes, but I really don't like a language that doesn't let you encapsulate the details of memory management within a class...
C#
With the language the way it was, I had to do something like:
or both of which are insanely ugly. I think it would be far better to have something like:I post this in hopes that someone on the committee will read this!
> what they would miss most if forced to use C++
> instead of Java
wow, harsh. what if they said "nothing"?
remember, someone at sun wrote your fancy
java library in c.
Anonymous posts are filtered.
Not precisely. I want it to be a different type. That just makes it an alias for an unsigned short... which means you can't have a unique signature for a function with a unsigned int16 as an argument, as opposed to an unsigned short int.
-- Still waiting for the Nike endorsement
Tell me about it. I've got a program here that does client/server interactions with mixed binary data streams, and I have to runtime identify the data type and handle the byte-swapping for conversion. Unfortunately, the protocols were developed for an Intel platform, and are not inet ordered (bigendian). But... shrug ...you go after what you can, when you can. Self-ordering types would be... problematic... for optimal processing.
-- Still waiting for the Nike endorsement
typedef unsigned short int uint16 ;
uint16 i ;
unsigned short int j ;
i = j ;
should throw up a compiler error or warning.
That also means you could overload functions differently for unint16 and unsigned short int. and enums etc.
I completely agree with this. Obviously, you can use a cast if you really do want to assign one type to the other.
Yes. But it shouldn't use the same keyword... How about:
-- Still waiting for the Nike endorsement
As a programmer who often works on massively cross platform C++ server and client applications, a lot of these proposals (distributed processing, standard thread libraries) are nice, but there's one major gripe with the language under all platforms: the lack of standard sized types. What I mean is, integral types in parallel to the short int, int, long int, long long int (C99 standardized, not C++) etc, with names like int8, int16, int32, int64, int128... allowing portability without meticulous work in wrapping and handling functions, outside libs, autoconf scripts, etc. It would be especially nice if these types were *not* considered, for the sake of signatures, type-identical to counterpart size-variant types, and if enums were also given a generic root type instead of being int in signature (eg, operator(ClassName&, enum) ) and a variant size integral type defined to the size of a pointer were included. Just some thoughts from a person who has to extensively use the language.
-- Still waiting for the Nike endorsement
Well, there is a large body of libraries available through the STL and through third-party vendors such as RogueWave. Admittedly this isn't an out-of-the-box solution, but there it is. Added to which, the STL is a much more meaningful implementation of extensible libraries.
When I grow up, I want a garbage collector to come take away all the crap I'm too lazy (or incompetent?) to clean up myself....
I don't use VC++ much, but I think I read (C/C++ UJ) that this is a preference that can be changed to put 'i' in the correct scope. The reason it defaults the way it does is so it doesn't break the various windows headers.
Waltz, nymph, for quick jigs vex Bud.
Look at some of the things that C99 added to C for a similar tack, IMHO, that the next generation of C++ (C+=2) should take.
I like the idea of "long long". Perhaps defined as a twice the size of the current compiler's "long" type. Currently, this would allow a 64 bit type for use desktop programmers (128 bit for those of you that get the fancy workstations). Stop the madness before "huge int" becomes the standard.
The beauty of the STL is that it doesn't involve anything that couldnt be implemented on any system. Adding things like multi-threading, any sort of GUI support, or anything else that can't be generalized to work identically on all platforms seems to be a mistake.
Waltz, nymph, for quick jigs vex Bud.
Namespaces have been a god send for the work I've been doing. I've had to write a lot of simple data structures to add high-speed functionality through DLL's to an interpreted scripting language (RadBuilder -- which is actually kind of fun, when was the last time you actually got paid to implement a binary search tree instead of just using some library version?)
Anyway, I can use whatever names I want for my classes and functions since I can wrap the whole thing in a namespace and not worry about conflict. I can call a function "sort" instead of "radbuilder_dll_sort" and not worry that there is a name conflict with some other library I've included.
It doesn't make programming mindless... it's just another tool (one that works for me).
Waltz, nymph, for quick jigs vex Bud.
As of the latest standard, I believe there are 37 keywords with the addition of inline, _Bool, _Complex, _Imaginary, and restrict. K&R C had 31 keywords vs. ANSI's 32 -- ANSI added volatile, signed and const and dropped asm and fortran.
At least, I think that's how it went... it's somewhat blurry now, I haven't used C in a long time...
J
Comment removed based on user account deletion
Comment removed based on user account deletion
Where did the cool poweder blue color scheme come from? I really like it. For that matter, why is it that pages tend to have different color schemes? Normally it's the plain green, but sometimes there is tht red scheme that, imo, look prettty bad.
This blue is really cool, though. Very soothing.
Stupid like a fox!
I do remember VC 5 had a number of problems with STL in particular, and we still have problems with the compiler in VC 6, even with the latest SP (random errors regarding DEBUG_NEW in MFC apps that disappear when you try compile again, as well as internal compiler errors)
Do you have precompiled headers on?
MathML is already in Mozilla, and it works pretty good from the bits that I've seen, unfortunately, Mozilla is probably not a popular browser.
Some of us are big boys, and we can handle C++ just fine, thank you.
--
Scott Robert Ladd
Master of Complexity
Destroyer of Order and Chaos
All about me
I'm a rather eclectic fellow when it comes to programming languages. Since the mid-70s, I've written code in (chronological order) MBASIC, Z80 assembler, FORTRAN, COBOL, 8080 assembler, C, Pascal, Modula-2, Prolog, C++, Java, and Python. I've dabbled in many more languages.
Specialization is for ants, as Heinlein said.
Where is it written that every program must be written in one "true" language? I won't hire one-trick wonders; give me a programmer who knows a couple of programming languages, who shows me they can adapt and think, and I'll give 'em an office...
Programming isn't about syntax -- the essence of software development is design and algorithms. Each language brings a different perspective to the table, and a wise engineer uses the right tool for the job.
My current commercial project wraps a portable, high-performance engine (C++) in component architectures (COM, JavaBeans) for server-side (Java) and standalone (C++, Visual Basic, Java) applications; we have several utilities written in Python. The C++ is for performance (Java and Python can't cut it, believe me), the Python for quick development, and the Java for network-oriented "stuff".
C++ is a power tool that shouldn't be given to inexperienced or undisciplined programmers. What makes C++ powerful is that it isn't an object-oriented programming language -- C++ is a multiparadigmic language providing the tools I need to build code in the best way for a given task. Is it perfect? No. Is it a dmaned fine tool? Yes.
Oh, I have my criticisms of C++: A new standard is a mistake when no on produces a fully-ISO compliant compiler today. The STL is an ugly mess designed by committee; I'd like to see restricted template arguments, inheritable enums, and a few other new ideas. But overall, C++ is a damned fine tool, if used by a professional in an intelligent fashion.--
Scott Robert Ladd
Master of Complexity
Destroyer of Order and Chaos
All about me
Compare the standard containers library, as implemented by ISO/ANSI/IEC, to Stepanov's original STL, and you'll find a rather large set of differences. The C++ Standard Library is a corruption of Stepanov's fine work...
I continue to use the original STL in many projects, avoiding the ugly, often poorly-implemented mess that stems from Chapter 23 of the standard.
--
Scott Robert Ladd
Master of Complexity
Destroyer of Order and Chaos
All about me
no one
Nope; in fact, it's a shit browser.
arnald
C# is proprietary. C# will probably NEVER run on anything but windows. C# will exhibit no better performance than Java. C++ is and will continue to be the language of choice for complex applications with performance constraints. There's 3 reasons C++ will still be around, and thus is worth improving. I was at the Conference this article is about. I heard Bjarne's speech, and I also attended an 8-hour tutorial on C# (by Stan Lippman, if anyone's wondering). I can see where C# will have some utility (rapid GUI development for the Windows platform, mainly), but it won't be replacing C++ for most of the situations where C++ is currently the best choice.
Xentax
You shouldn't verb words.
To give the answer the forum speakers gave, they just finished NOT doing anything for a few years, to give the compiler groups time to catch up. They don't want to wait any longer.
Xentax
You shouldn't verb words.
This is just a question but what would all the benifits would there be from a new C++ language I know that there should be lots but I don't know what they all are so would people please enliten me?
jeb.
If by "powerful", you mean if it complicates the definition of the system by 1000% to make it 10% easier to do something you want to do less than 1% of the time, than I would agree. Java is often less "powerful" than C++. But the compilers for it actually compile the whole language.
jeb.
Nah, object oriented Pascal is nice. I still use C++ though because it allows operators to be overloaded, something Delphi (Object Pascal) still lacks.. there are other minor differences, but at work I use Delphi and at home and whenever else possible I use C++.
All I know about Bush is I had a good job when Clinton was president.
It also has it's place in business though, and in Europe it has a much larger following (specifically Borland's implementations of Pascal-- Borland Pascal and Borland Delphi). You're right though, as a training language it's a step above Basic and shares enough similarities with C and C++ that anyone migrating from Pascal should be able to catch on quickly.
About Java though, while it's nice to have garbage collection and be able to avoid memory leaks, I just don't see Java being a C/C++ killer. Garbage collection just seems like a step beyond exception handling (alloc a pointer, 'try' to operate on it, then free the memory in a 'finally' handler), and another way of bloating the CPU resources used by an application. (In other words, a step backwards.)
Java works for web technologies, but I don't see it taking the place of common application development.
All I know about Bush is I had a good job when Clinton was president.
On instruments like the violin or in voice, Db should be slightly higher than C#. -- Cpk71
You're opening a whole can of worms here! There are many who disagree violently with this assertion, maintaining that mean-tone tuning or any other deviation from equal temperment is a hopeless throwback to the seventeenth century. Certainly, if you play in a symphony or an ensemble in which equal temperment instruments participate, you'd better play/sing tempered fifths. Easley Blackwood was famous for berating string sections on this point.
Of course, if playing Irish fiddle tunes or singing madrigals, you're quite right -- use those pretty-sounding perfect intervals. But if you're playing Beethoven, Hindemith, or Thelonious Monk I'd stick to the tempered scale.
ROFL, didn't expect this conversation in this thread.
- What's bimodal and brown? A chocolate-covered flip-flop.
-- We all have enough strength to endure the misfortunes of other people. La Rochefoucauld
naasking said: int* pi = (int*)malloc(sizeof(int)); ...is NOT correct even with the cast. It's valid, but not correct. That statement is requesting an int and assigning it to a pointer. That should read:
int* pi = (int*)malloc(sizeof(int *));
or
int pi = (int)malloc(sizeof(int));
Huh? As I read it, the original line is quite correct: malloc a chunk the size of an int, treat the return pointer as a pointer to int, and store that pointer as 'pi.' The result is a pointer to an int-size value. Your two examples do something quite different. The first mallocs a chunk the size of a pointer, and makes 'pi' point to it (yet 'pi' is defined as a pointer to int, not a pointer to a pointer). The second mallocs a chunk the size of an int, treats the address as an int, and stores it on the stack. Neither of these seem to be the desired result.
Try rereading these. I don't think I skipped my coffee this morning.
- What's bimodal and brown? A chocolate-covered flip-flop.
-- We all have enough strength to endure the misfortunes of other people. La Rochefoucauld
It's called Delphi
---
"Watch these suckers jump when I get Administrator."
Back when it was still being designed, the version of C before the final standard was called "B". Pretty useless factoid, but interesting.
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
C++ was an innovation that extended C into object territory that it was never designed to handle.
Take the best Ferarri from 1966. Best of breed for its time. Nice looking too. Race it against the best of breed from this year. Do whatever you want to that 1966 Ferarri, it will never be as good as a new a fresh design.
Java syntax is an improvement over the convoluted syntax that is C++. Deal with it. Its creators would have to be less than top-notch considering they could see all the bad things in C++ and avoid them.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~ the real world is much simpler ~~
--- -- - -
Give me LIBERTY, or give me a check.
Did the moderators not bother to click the link and see that it goes to a GOATSE.CX-esque picture? Somebody mod that down please... the post is a junk post to trick people into clicking the link.
I fear that no one reads the moderator guidelines anymore.
-------
-- russ
"You want people to think logically? ACK! Turn in your UID, you traitor!"
Natural != (nontoxic || beneficial)
Actually, in ANSI C there are very good reasons not to cast the return value of malloc.
In ANSI C you are always allowed to assign void* to another pointer type. In fact, that is what void* is for. Adding a cast buys nothing.
Moreover, adding a cast can disguise the fact that you've forgotten to #include stdlib.h. If you forget to include this header (which has the prototype for malloc), then the compiler will assume that malloc returns an int. Normally, this would fail to compile when you try to assign it to a pointer. But if you have included the cast, your program will compile and silently mix integers and pointers. This will work on a machine where pointers really do have the same physical representation as ints, but will fail elsewhere. Thus, not only is the cast not needed, it actually makes your program more prone to portability bugs.
where there's fish, there's cats
How much does it really add? Is
really any harder to read than ? It could be argued that the former is easier to read, since it is cleaner.And if you do it often enough for it to be a major problem, I suggest actually paying attention to what you're doing.
I'm not suggesting it happens often. I was just pointing out a potential drawback to casting the return value of malloc, in addition to the fact that it accomplishes nothing.
I think that saying 'programming according to the language standard reduces portability' is a ridiculous statement.
The standard says that the casts are unneccessary.
int* pi = (int*)malloc(sizeof(int));
If you have included stdlib.h, this code is correct, with or without the cast.
If you have not included the header, the cast won't save you.
Btw, I just looked in my copy of K&R2 and noticed that they cast the return value of malloc. Their influence over what is considered good C style is (rightfully, IMO) powerful. Then again, K&R also allow their hello world program to fall out of main() without returning a value...
I suspect that most uses of casting malloc's return value are really just holdovers from pre-ANSI compilers and pre-ANSI lint utilities.
where there's fish, there's cats
I seem to recal a Bjarne Stroustrup quote along the lines of: "I think there's a smaller, cleaner language inside C++ trying to get out", and I definitely agree (assuming I'm haven't got it wrong and am totally misquoting him). Everyone I know has picked their subset and is wary of going outside it.
Have you tried the Intel compiler?
I think you seem to recall incorrectly then
Well, someone said it about something. In my imagination, if nowhere else.
Yes, mdev 7.0 is probably one of the most compliant C++ compilers out there.
It's not. AFAIK, most other popular C++ compilers are better. I've used Visual Studio .NET 7 for a while now, and it hasn't improved much over 6. The standard library is a little more compliant, but only in a few places. The compiler itself still doesn't support all the standardized features. The following list is taken from the VS.NET help file:
Standard Compliance Issues in Visual C++
The alternate forms of the following keywords are not available: and, and_eq, bitand, bitor, compl, not, not_eq, or, or_eq, xor, xor_eq
Argument-dependent name lookup, also known as Koenig lookup, is supported for operators but not for other member functions...
A name introduced in a selection statement should be in scope for the remainder of the selection scope...
Covariant return types are not supported...
The export keyword is not supported on templates...
Class and template members must be declared and defined within the class or template...
Class template partial specialization is not supported by the Visual C++ compiler...
Partial ordering of function templates is not supported...
Visual C++ does not deduce template arguments for function templates; that is, all template parameters must be used in function arguments or return type...
Function try blocks are not supported...
Function exception specifiers other than throw() are parsed but not used.
As can be seen in the Visual C++ source file, uncaught.cpp, uncaught_exception returns false.
I too have heard that VC++ 7.0 is much better. I wonder why people still have time to generally bash things without specifying the scope of their problems set. If someone was saying that for "generic" usage that VC++ sucks, I refuse to listen. I need to know when it sucks and why. I am not saying that VC++ is a holy grail by any means, but let me know where it gives you beef. These comments are like saying Java is only 5% slower than native code. Ok, maybe this is true, but the important question stands: Is it only 5% slower in applications I might use. Anything else is just generic and useless.
Random thoughts...
I think they'd have a chance at creating a good language if they followed Java's lead.
[[Insert cries of outrage]]
No, seriously. Java's got some knocks on it but the main problems are verbosity of code and the way it gets implemented (virtual machines, HTML converters, general slowness, etc.). If the new language were built in the same abstract way that Java is, you'd get a decent OO language with none of the ugly memory management techniques that a C coder has to go through. I'll still probably code in C, just because I like it and don't need objects for what I do and the speed is nice, but I think that for the average programmer, messing around with mallocs instead of "new" and arrays of chars instead of a string class is a real pain-in-the-butt price to pay for performance. I know these (strings and "new") are both aspects of C++ right now, but you've still got backwards compatibility (if you can call it that) with C and that means a bunch of confusion (ie: a bunch of C-string functions that don't work all that well with C++ strings, etc.). It's a huge mess to sort through, with C techniques available on the one hand and C++ techniques available on the other. And it's not like I've ever seen a C++ textbook aimed at beginners that didn't teach C fundamentals at the beginning. The overlap is practically assumed and accepted, and I think that's bad for the language.
I think if they went for simpler and more cleaned up, they'd make the language a lot more attractive. I don't think they should model it on C++, myself.
Although, I do have to admit that the time might be better spent working towards improving the supporting libraries with C++. One of the nice benefits of C++ is that, even though it can be a pain in the ass to build appropriate foundation classes, ones that get built nicely are a DREAM to work with. Of course, that's a language-irrelevent issue...
--------
Bleah! Heh heh heh... BLEAH BLEAH!!! Ha ha ha ha...
Could the next version of C++ make Purify less important? The fact that this product line exists indicates a C++ usability problem.
>express our software musically than in C++.
excellent idea.
Windows 98: BUUUUUUUUUUUUUUUUUURRRRRRRRPPP
Visual Basic: [EXTREMELY LOUD FART]
Quake III: [toilet flushing]
"Any connection between your reality and mine is purely coincidental." -Slashdot
The subtle difference is that phase one gets an incomplete base class, while phase two gets the finished object, and hence virtual method calls in the base class get passed to the derived class handler.
What a stupid stupid way to import stuff: gotta protect the whole thing with #ifdefs, think about forward declarations, urg
...he's exactly the type I would hire. He seems to at least attempt to understand what he's talking about, and isn't afraid to speak his mind. Now his immaturaty is showing through, but at least I can work with that. I'd take a dozen of guys like this over a couple hundred programmers with no drive. You must have one hellva time finding programmers. Oh, and to jsse himself, if you read this feel free to email me your resume. I would be more than happy to discuss Java employment with you. And no, I'm not a recruiter or a manager. But I am the lead programmer for my company and do make the recommendations for who gets hired and who doesn't.
Javascript + Nintendo DSi = DSiCade
The number of differing Application Binary Interfaces with a significant user base can't be terribly high. Why not a template parameter for the compiler to target the different platforms? I suppose some linker interface trickery would degrade performance.
Reading Mr. Stroustrup's February response on /., he seems disinclined to endorse anyone's ABI. Can the discussion be obviated?
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
Let's see: :/) overloading, and thus no name-mangling
-In C, I can be assured of minimal compiler overhead/bloat
-In C, I can use modules/libraries that were written in assembly language without having to worry about name-mangling or things like that
-C has none of this namespace nonsense
-With C, I don't have to search through a class-browser to find a function that I need
-C has no function (sorry, method
-I can actually use C to write an operating system
I could go on all night, but I think I've made my point as far as that goes.
People often tell me of C++'s advantages over C, but all those "advantages" make me think of is code bloat and unwanted speed reductions.
- Ctor/Dtor. First of all, Ctors *are* guarranteed in Java. Dtor is mostly needed for memory management in C++ - which is not needed in Java. When dealing with external resources, it is no harder to remember to call "g.dispose()" everywhere than it is to remember to "delete p". C++ garbage collectors don't call dtors either (and for good reason).
- Multithreading. This is a library issue - and newer Java library classes *don't* synchronize unless you ask for it. How 'bout some of those older C/C++ libraries that aren't thread safe at all (e.g. returning values in static memory!)
- Generic types. Gotta agree with you there. Hopefully, GJ will be standardized soon.
- Operator overloading. Agreed, but I haven't missed it as much as generic types. Probably because I haven't tried to do any scientific code in Java. Right tool for the job and all that. (Go Fortran!) This is a language issue, and several free Java extensions offer operator overloading.
- Explicit allocation. You absolutely do *not* want this in Java. For the high level code Java is intended for, eliminating memory corruption as a source of bugs is *critical*. It is also critical for sandbox execution of untrusted code - something C++ doesn't have a clue about. Yes, custom memory management can be faster, but using the C++ default of malloc/free in generally not any faster. Right tool for the Job.
- Support for plain functions. Java has had plain functions since 1.0. They are called 'static' methods. Have you actually used Java?
In short, while C++ is good for small to medium projects which are perfomance sensitive, it is unsuitable for large or security sensitive projects because of memory corruption which grows exponentially with project size.C/C++ is especially unsuitable for security sensitive applications such as nameservers, web servers, mail transfer agents. Because of the pervasive use of the wrong language for these servers, the most common exploit by far is overflowing some buffer to overwrite the stack with native code.
The bottom line is, neither language can substitute for the other in all applications.
As a senior developer in a Java shop, one of the things I often ask interviewees is what they would miss most if forced to use C++ instead of Java. Anyone who answers anything other than 'the libraries' gets a big black mark next to their name in my book.
It's you who deserves a big black mark on your face. Java beans achieves the concept of reusability, as they can be created and redistributed like blackboxes - it's especially important to commercial and enterprise usage. Take a look at some java factories like Flashlines, they sell individual java beans which can be used on any platforms and any development environment. EJB, Servlet, and RMI etc. are hardly merely 'libraries', they are integrated parts of Java, and you just can't ignore their importance. A Java app developed on personal java 1.1 can run on any mobile devices compliant with this jvm, without recompilation.
I really doubt someone with such an insight and knowledge in Java could be a senior developer in a Java shop...or you are simply a troll?
javax.servlet and java.rmi ARE in fact merely libraries (packages in Java-speak). The only thing that makes them "integrated" are their inclusion in rt.jar.
Ever heard of terms like rmic, rmiregistry, EJB-containers? Are they a java libraries?
EJB is simply an umbrella term for RMI, JDBC, JavaBeans and JNDI with some convenience classes/interfaces.
Should I comment on your pure imagination on EJB? Nah, RTFM yourself!!
Damn, fell into another troll's trap again....
This means that you could write and test source codes in shell batches without the need to compile, and then when ready, compile, or that the same interface is used by shell scripts and program applications.
More importantly, it means that the same knowledge and tools can be applied to writing both scripts and code, and if c-- is more forgiving, like CEnvi used to be, a good way to learn and explore c in a meaningful way. {ps} it probably is, but I have not upgraded to vers 4, since there is no OS/2 support :) {/ps}
OS/2 - because choice is a terrible thing to waste.
IANA Musician, but I seem to remember from my ancient days of playing violin that C-sharp is equivalent to D-flat. Which also seems to be an appropriate description.
Low level coding IS best.. for the final binary. Yes, it is a little tougher. Yes, it is more work for the programmers. Yes, it does take more time and more thinking on our part. But, does this matter? No. Our goal should be to produce the best binaries we can. The fastest and smallest binaries we can! Sacrafice your own time and brain power for a good binary, thats what matters. Take the hard road and reach the better paradise.
Question
http://www.ironfroggy.com/
Time, Date, Timezone and calendar handling
...
Universal constants (PI, e, etc)
Unit Conversion
I think that multiple return values is also a useful, and nice idea -
int, int foo()
{
return x,y;
}
With all the negativity going on here at Slashdot in relation to C++, it makes me wonder if slashdot has been infected with dot com web scripting try- hards, and the real hacker crowd has migrated elsewhere.
My 0.01 (Australian cents arn't worth much) is that C++ would benefit from perhaps a few minor enhancements to the language, and certainly a major expansion of the standard library. Things that come to mind - multi-threading, networking, TCP/IP protocols, optional garbage collection, various smart pointers in addition to auto_ptr. I'd also like to see some HTML/XML oriented functionality as part of the standard library. A serious math and vector calculus library would be useful for graphics programming.
I don't think it would be desirable or necessary to change things in a way that substantially breaks existing code.
It would certainly be nice to have some of Java's tricks in a standardised form, and to decrease dependence on vendor specific 3rd party libraries.
It's understandable that 15 year old programmers are more interested in Java-style padded-cell programming, but out here in research/commercial land, we've got existing code bases to consider - and Java just isn't that big enough an advantage to justify large, time consuming porting efforts.
Make Java an ISO standard, and it could be taken half seriously. C++ is my bread and butter, and I won't be relying on Microsoft or Sun to improve my primary development environment. Roll on, C++0x!
How about trimming the C++ language back a couple of years? How about then adding these "features" as libraries? How about NOT making the language any more complicated than it needs to be.
Seriously, look at C for an example of a language that wasn't the ultimate solution to every problem, but ended up being so useful that it is used for just about every problem.
Dancin Santa
Sounds better than ++C++.
Dancin Santa
You're welcome AC.
...in an effort to keep the language moving, avoid fossilization and avoid being overtaken by proprietary extensions. Suggested new features center around the standard library and include support for multi-threading and simple platform-independent systems abstractions (handles, TCP/IP, memory maps etc...)" /reducing/ the feature
set to make it easier to learn, and more portable (and probably faster.)
Yeah, wouldn't it be terrible if the language remained static - then people could spend less time learning it and more time using it. Or horrors, imagine if somebody actually suggested that was already too much bloat in the language and we ought to work on
Just look at all the damage RISC did - it took years for the industry to overcome the prejudice against bloated, high gate count chips caused by low cost, ultra fast processors.
Instead of thinking about what they can add to the language, maybe they should talk about what can be removed from it.
...in an effort to keep the language moving, avoid fossilization and avoid being overtaken by proprietary extensions. Suggested new features center around the standard library and include support for multi-threading and simple platform-independent systems abstractions (handles, TCP/IP, memory maps etc...)" /reducing/ the feature
set to make it easier to learn, and more portable (and probably faster.)
Yeah, wouldn't it be terrible if the language remained static - then people could spend less time learning it and more time using it. Or horrors, imagine if somebody actually suggested that was already too much bloat in the language and we ought to work on
Just look at all the damage RISC did - it took years for the industry to overcome the prejudice against bloated, high gate count chips caused by low cost, ultra fast processors.
Instead of thinking about what they can add to the language, maybe they should talk about what can be removed from it.
I think, insofar as programming languages are concerned, we should stop creating new puzzles to figure out and solve the ones we have. This is all a lot of opinion, though.
35 keywords to the language. 35! That's it.
I agree... that's quite an accomplishment. C is a much smaller language than C++. Small is often desireable, but smaller != better.
There are too many ways to do the same thing.
You like C, but you complain of too many ways to do the same thing in C++?
The language was released while still being developed.
And C wasn't? There's K&R C. There's K&R2 C. There's C90. There's C90 with the 95 addendum. Now there's also C99.
"Every C program is a C++ program"?
No one has *ever* said that (no one who knew what they were talking about anyway). A simple case is the C statement:
int* pi = malloc(sizeof(int));
That's an illegal C++ statement! In C++, it would look like:
int* pi = (int*)malloc(sizeof(int));
(Please forgive my lack of new-style cast and my lack of namespace specification). Now, that C++-version is legal C, but it is *poorly written* C code. Any C programmer worth his salt would frown on a program littered with such statements.
What *has* been said (accurately) is that all the C programs appearing in K&R2 were checked not with a C compiler, but with a C++ compiler.
C is a good language. I happen to prefer C++.
________
It's always a long day... 86400 doesn't fit into a short.
I've developed for both c(++) and java.
:) (Just keeping hoping that one day the lonlyness vanishes, and some other might enthusiated as well :)
I find c++ not satisfying, especially when compared to java language structure.
However java didn't provide me the speed i wanted to have, nor did I want to be forced to garbadge collection.
As I guess already several have before, I came out starting developing my own object oriented language, trying to merge c(++) and java the way I think it should be, the compiler at the actually translates to nice plain c code.
http://dtone.sourceforge.net
Well, I'm the only develeper and user of that language, however having quite some fun with it
--
Karma 50, and all I got was this lousy T-Shirt.
g++ has come a long way toward addressing the first (at least on those platforms that g++ supports well). This will hopefully address the latter.
As a senior developer in a Java shop, one of the things I often ask interviewees is what they would miss most if forced to use C++ instead of Java. Anyone who answers anything other than 'the libraries' gets a big black mark next to their name in my book. This is really the only area where I think Java has a real advantage (not just a marketing advantage) over C++. If the latter language were to get decent standard abstractions for things like networking and and multi-threading (and the ever-increasing plethora of Java extensions), it would be much more attractive.
Of course, because of the nature of standards comittees, Java will likely have genericity and direct management of memory before this new standards process actually produces anything <sigh>. Thus I'll have to program in this crappy language for the forseeable future. Oh well.
If the comitee was waiting for some compiler implementors to catch up, i think we wouldn't be able to use new standards before they outdate. The problem is not that compiler vendors do bad in implementing basic constructs, rather than there are hordes of programmers and companies, that implement new constructs on their own, resulting in a big mess of basically equivalent but incompatible proprietary extensions. It's not only nessecary to do things like that in order to "save" the language from practical extinction, but to clear up the mess that evolved from everyone implementing missing features.
a user interface, cross-plattform like swing, as fast like it should be... and most stuff java has, without the need for the virtual machine ..
1) Standardised ordinals - signed and unsigned - of known platform independent sizes - maybe we could have something like int8, int16, int32, int64, nat8, nat16, nat32 and nat64?
2) A mechanism by which overflow can be detected when performing arithmetic on numbers (particularly for ordinals above)
3) Run-time polymorphism - not only would this satisfy language zealots who claim it's impossible to implement the identity operation as a compiled C++ function - but would also make it possible to easily implement more flexible containers.
4) A type system to constrain template instantiations. When I template a class with another, I want to be explicit about what behaviours my template parameter type should support, and to have this aspect of my program statically verified.
5) An improved scheme for enumerations whereby new enumerated types can be easily inherited from existing ones.
I've other things I could moan about, but I don't want to see C++ done an injustice - it performs well with many real problems, and I would like to see it developed in such a way as to eliminate as many of its idiosyncrasies as possible.
C# will be standardized by the EMCA, to do this they need to have it run on at least 2 different platforms. I'm sure MS is evil and stuff, but spreading FUD about them is not good.
I think that templates are fixed, I know that MFC are finished, design wise, the only updates will be bug fixes.
They plan something new, which will be fully template based, which mean that they either have to go OS or fix the compiler.
Guess what will they do?
--
Two witches watched two watches.
Which witch watched which watch?
I want Ada's style way to create and limit new types.
/* new reserved word, I'm afraid */ {
Frex, in Ada, you can do this:
Week is new integer 1..7;
(This create a new type, named Week, which is an integer that can only accept values between 1 to 7)
And the compiler will take care of making sure that the value is within viable range.
Compare this to C++'s way of doing it:
typedef Week int;
(Week is a new name for int)
This saves me the time checking what the variable contains, and actually make Week a new type.
Here is how I would like it to be:
create
week ( int (1-7) );// I don't care how you spesify ranges
//only operators allowed, not functions
};
Yes, I *know* I can do it with a class, it's not the same.
Ada also allows you to specify the size of the type you create (16,32,64,whatever) saving the need to check on each platform & compiler what size the basic stuff is.
I think my method is more readable than Ada's way, at least to C's people.
Borrowing from Ada is not a bad idea at *all*, IMO.
I like C++ better than Ada, though, Ada's OO approach is a little strange, and it's syntax can drive me crazy sometimes.
--
Two witches watched two watches.
Which witch watched which watch?
Not if I've to use the :: operator.
I *hate* this one.
What is wrong with "." operator double duty, as it does in Java?
--
Two witches watched two watches.
Which witch watched which watch?
for (int i=0;i10;i++){
//do stuff
//do some more stuff
}
for (i=0;i45;i++){
}
Your method will break anything like this one.
--
Two witches watched two watches.
Which witch watched which watch?
There is a compiler switch in VC6 that fixes this, but it's off by default because some core header files in windows needs it.
The standard changed, it's not VC's fault.
--
Two witches watched two watches.
Which witch watched which watch?
The *new* standard, several years ago, you were perfectly okay doing it.
--
Two witches watched two watches.
Which witch watched which watch?
That's one of the most annoying and frustrating things about C++... it isn't implemented properly and effeciently anywhere yet (g++ comes close, but still enough annoyances to be, well, annoying).
Ryan T. Sammartino
Ryan T. Sammartino
"Ancora imparo"
Actually, I use namespaces a lot, mainly for logically seperating different modules of a program (timing, input, sound, graphics etc etc). True, I could do this another way - directorys or name prefixes perhaps, but namespaces is a lot more elegant in my opinion, and errors can be caught at compile time, rather than link time which leads to much more helpful error messages. JM2C
There's no $$$ in 'team'...
www..--..net - for incisive, w
I've always wanted to do this:
(int, int) foo (){
return (1, 2);
}
void bar(){
(a, b) = foo();
}
You could return both a string, and the length of the string at the same time (without having to do the sheisty bar = foo(&returnValue))
Ne Quid Nimis - All things in moderation
C++ has never being a great language: 1) It's type system is a failure (same as pascal), incoherent and misconcepted design. Real and usefull type systems can be found in ML languages that can found almost errors at compiling stage. C++ and a lot of others are really UNSAFE programming languages. 2) No Garbage Colector. (more memory mistakes) 3) Bloated and useless declarations and syntax. Most C++ programmers only use a subset of the language. 4) Too low level (as Java and pascal) to be reliable in large proyects. 5) Low productivity, a large debugging and testing effort. 6) Low level of expresiveness and abstraction. The programmer waste a lot of time dealing with irrelevant stuffs. My conclusion: It is very difficult to C++ to evolve to a BIG language as the basement is poor. Also in the OO arena are much better languages as Dylan (not Java). Better still functional languages of the ML family as OCaml from (INRIA) also with OO support that reach quasi C++ speed and superior memory perfomance, 5-10 times more productive than C++ or Java.
Arturo Borquez
...why am I drooling and breaking out in a cold sweat at the same time?
abstraction -- overhead -- efficiency -- complexity -- standardization -- divergent implementations -- progress -- stagnation
EAAARRGH! [head explodes]
I can honestly say that this fills me with nothing but the purest ambivalence.
--
Thanks to the recent success of distributed SETI data processing, we can finally move beyond mere ISO standardization to GSO standardization.
The main problem will be translating everything into '''d''k'pogi, as per Galactic Standards Organization regulations.
--
A real language for real computers! This is the best news I've read on Slashdot for quite a while!!!
Been looking around for the official ISO white paper for some time. Anyone know where it can be found? I'm looking for the end-all be-all reference to the language so I can settle all of the "no you can't" vs. "yes you can" disputes about the office/school.
-------------------------
-------------------------
It is the monkied monkey that monkies with another monkey's monkey. Monkey.
What about re-packaging the STL (and the extensions) with nested namespaces, like packages in Java (eg, std::sql::oracle::query) ? It may make the reading clearer, and could lead to better programming.
What about Microsoft's up and coming C# language that is supposedly arriving with .NET What effect will this have on any other programming languages? In my school, DeVRY Tech, they use Microsoft visual c++ and visual basic, i think they will continue to use whatever microsoft puts out..
Programming languanges evolve in different ways due in large part to the style and personality of their authors, owners or shepherds. Sometimes this happens "in committee," (Ada, PL/1, and C,) sometimes thru benevolent dictatorship (Java, C#) and sometimes it's organized anarchy (Perl, Python.) But there are common threads. A language escapes from its origins and begins to mature in the field. Many users (programmers) become adherents and start to demand updgrades. Different vendors fork the base to attract more followers than their competitors. Disgruntled users demand A STANDARD! Proposals for new features are submitted, debated and then assessed by public review. Much ado is made over backward compatibility. Finally a version # is stamped. Lather, Rinse, Repeat. These cycles taper off and eventually the language survives into old age or becomes extinct.
What is critical is its adaptability to changing environments. Faster, smaller systems. Larger systems. More memory, less memory. More communications (network), and distibuted systems. Languages evolve to do more in this more diverse arena, but the better languages don't just get bigger, they refine, adapt and avoid asteroidal impacts. They exist in many ecological niches simultaneously. Consider Java and Perl in this regard. Java: J2SE, J2EE, and J2ME. Perl: Sys admin scripting, CGI-BIN and even real time video editing.
I think it is interesting that after less than a decade, C++ is being labeled as fossilizing. While its parent C is still very vital. I feel this is because the effort to bolt on object orientation on a proceedural language core resulted in too many compromises and patches (multiple inheritance, const-ness etc.) Java, on the other hand, is evolving to pickup the best from C++ (assertions, generic programming.) Maybe it is time to let the horse expire.
Take C, mix in C++ and sprinkle a bit of Java.. result, DELPHI..
is just called Ada 95 !!! Good compilers available, real time oriented, security oriented...
Just a few work about the language Naming : this is Ada and not ADA ! This is not an acronym, but named after Lady Ada, the first known programmer.
Bjarne Stroustrup is speaking at Columbia University
ACM @ Columbia Univeristy welcomes all ACM members and interested persons:
April 26th, 2001
JAVA BYTES
OK, maybe not, but there are certainly alternatives. Far and away the
most popular programming language in the world today is C++. Unlike many
modern inventions, C++ has one clear creator: Bjarne Stroustrup.
On April 26th, he's coming to speak at Columbia, thanks to Columbias ACM
chapter with the support of the Department of Computer Science. This is a
rare chance to hear one of the major figures in both computer science and
the information economy speak about his creation.
The topic will be C++ itself, and thus should be of particular interest to
dedicated Java types, as C++ is the primary programming language of the
"real world." Used a Microsoft product lately, either operating system or
application? Written in C++. Played a computer game? Used any retail
software whatsoever? Ditto. Tens of billions of dollars worth of
software written in C++ are sold every year.
So anyway, come and listen to the guy who wrote the worlds main
programming language talk about programming. The talk will be aimed at
intermediate-level computer science undergraduates. We promise that your
mind will be stretched.
Please go to our site: http://www.cs.columbia.edu/acm for directions to
the lecture hall at Columbia U. where the talk will be taking place.
Columbia U. itself is located at 116th and Broadway.
-- ACM @ Columbia U.
Bjarne, C++ is without a doubt the masterwork of language design, but we just aren't up to it. Mastering C++ in all its beauty is simply beyond 99% of the programmers out there, even among those who have mastered the pointerish issues of C and the OO issues of Smalltalk independently. Its just too hard.
:-)
For you maybe, but those of us who are not trying to write C and Smalltalk programs in C++ really like it. Powerful and flexible often means that it takes a while to get used to it. Generally it is also worth the effort.
Keep up the good work Bjarne!