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.
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.
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.
You can use a auto_ptr only if you have allocated something using new. If you malloc'd it, or used some (C) library that requires you to call a function to free the resources auto_ptr cannot help.
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.
auto_ptr is less then 100 lines of code. You can take the one from and template it up a bit more to use any allocate/free functions you like. You can even get some counted versions from boost.
finally may still be nice for some things, but following the "all resource allocation is object creation/all deallocation is destruction" design will eliminate 99% of those.
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.
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 );
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.
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?
--
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
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
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
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++.
"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'm aware of that garbage collector (I use it for a number of projects), but it is has a number of limitation because it doesn't have any support from the compiler. That collector for example, knows nothing about your data structures so it has to assume everything could be a pointer forcing it to scan the entire heap. This is not practical for real-time application where GC needs to be done incrementally. Yes, the xerox collector can run experimentally in incremental mode using page protection - but this makes it hard to debug on many platforms and though I have not tested the speed, I suspect it has a fairly dramatic performance hit if you application accesses a lot of data. Also hardware page protection is not available on all platforms (DOS, game consoles, embedded systems, etc).
Right now if you want fast incremental GC you have to make you own smart pointers and do reference counting for all global roots. It would be nice to see compilers with reference and resource management builtin so you don't have to make everything look like template hell.
Also it's a misnomer that GC adds more overhead in terms of speed. Applications written to properly use GC spend less time copying/freeing objects than their non-GC counterparts so on average a GCed program with a good collector will have better performance. Not to mention I recall a study showing that c++ programmers spend some 50% of their time dealing with allocation/deallocation and a large percentage of bugs are related to memory leaks and premature frees. On average GC makes your program go faster and it almost always speeds up your development (which is more important these days).
I've written a few garbage collectors myself using smart pointers to track global roots and then I use thread-suspension during collection to deal with currency issues. It would be nice to see something like this standardized and supported by the compiler and support libraries (i.e. enumurable counting pointers and thread suspension). It could be toggled on/off by class so that there is 0 overhead if you choice to not use it.
-- 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
"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.
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)
Irregardless, he has a point. :-)
------
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.
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
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.
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
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*
FYI
gcc, and possibly other compilers, actually do this on purpose. Since the c++ standard is not stable (ie they are already changing it again), they use the different versions of name mangling to keep folks from compiling wrong versions of C++ libraries together.
So that standard would be great and all, but it might just be the next thing changing
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))"
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.
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.
call it (c + 2), get rid of all those horrible side effects!
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
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.
--
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.
Some of you are saying that finally encourages bad design. Rather, I feel that instead, most C++ programmers don't use the try/catch mechanism to its full potential. Hacking in Java has actually made me a better C++ programmer.
--
--
I like to watch.
It's also possible to write code that creates pointers a conservative GC won't find. "Numerical Recipes in C" does this in its storage allocator, which creates offset arrays so they can index from 1. ("Numerical Recipies in C" is actually "Numerical Recipes in FORTRAN" transliterated to C, as comparing the two books makes very clear.)
Reference counting, with compiler support to optimize out much of the count updates, looks more promising for C++. "Smart pointers" have been around for years, but without language and compiler support, the overhead is annoying.
Weak pointers (the Perl kind, not the Java kind) can be used to avoid the circular linking problem. "Backlinks" should be weak pointers. It's possible to introduce restrictions that force an "ownership tree" of data, so that it's unambiguous which pointers should be strong and which should be weak. But that may be too restrictive for C++.
I've been writing up something on "Strict C++". The general idea is like "strict mode" for Perl; it's optional, there are more restrictions, and it's safer. If the whole program is in "strict mode", you're guaranteed pointer safety (no buffer overflows, no dangling pointers, no memory leaks.) The restrictions are less restrictive than those of "Safe C++" (another PARC project).
Now that we have the STL, and it's in widespread use, it's more reasonable to do this than it was a few years back. Much of the safety can be encapsulated. The general idea is that you pass references to collections around, not raw pointers. On collections themselves, you use iterators. Iterator arithmetic can be made safe, (there are STL implementations that check in debug mode), and with code hoisting in the optimizer, much of the checking can be safely removed during compilation. Pointer arithmetic on non-iterator pointers would be prohibited in strict mode. With one big exception.
Part of this is a "great compromise": "const" pointers to objects that don't contain pointers don't have to be safe. This allows the use of "const char*", classic "printf", but not "sprintf" or "scanf", which write an argument whose length they cannot verify. You can read junk, but can't write it. Provided you can turn a memory access hardware trap ("Bus Error" to UNIX people) from a bad access into a C++ exception, this is safe enough for practical purposes. We can't get too religious about this or programmers won't go for it.
If this catches on, programs written in it won't have buffer overflow vulnerabilities. That's enough reason to do it. Not everything needs to be in "strict mode", but important programs should be.
"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?
-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.
When will we see a mainstream language implementing multimethods (as in CLOS for example)?
Relinquish
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!
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...
No, they claim every difference is an improvement. That's a good book -- I own it -- but their advocacy often crosses the line of sanity.
Like when they defend the whole single inheritance fiasco. They use the example of a House and how you'd want to make it inherit Foundation, Walls, and Roof. Makes sense, right? But then they say to make Walls extend Foundation, and Roof extend Walls, and House extend Roof. Um, a roof isn't a wall. It shouldn't have wall-specific methods.
Java does have some things going for it. It's a neat little platform for applets and set-top boxes. But it is vastly overused in settings for which it is painfully unsuited (like Web servers). And certain pathetic hacks to get around the confinements of Java (such as using "interfaces" to pretend for a second that Java can almost simulate multiple inheritance, but wretchedly) just cause more spaghetti code, pain, and suffering.
Try a real object system sometime. You'll like it.
--
TO BUY A NEW CAR WOULD MAKE YOU SEXUALLY ATTRACTIVE.
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.
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
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
It's called Delphi
---
"Watch these suckers jump when I get Administrator."
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)
You can write operating systems and real applications in C/C++.
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!
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.
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"
...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.
--
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.