I can only speak for Java...

Java has an integrated build system. You compile one file and if another is needed, that is compiled first, and so on. But if the dependency (which is always just a class) is already compiled, then its interface is very easily and quickly extracted from its class file. I think C++ should modernise its compilation system similarly and rid itself of its preprocessor legacy once and for all. Also, another annoying legacy that should die in C++ is that a global or class identifier must be declared above the code that first references it.

C++ was designed to be a better C. It's time for a better C++.

ahhh the recursion! make it stop!

Marcello

Got rid of it

Oops, they used 2005 instead. The last version I used was 2k3, thus the confusion.
ICC version was the latest, 9.1.
Newer GCC has vastly improved SIMD code generator, thus the alpha. I'm not sure if GCC 4.1 series have the same optimizations or not.

If you don't remember what I said before in ]edit I'll say this again:
... at least for compiling code with lots of SSE2 intrinsics
So when dealing with that topic narrowing my "benchmark" is correct
Btw, that ray tracer should currently be one of the fastest single-threaded ray tracers in the world if not the fastest. Too bad it currently only supports primary rays and no textures. Those problems should be fixed soon and also it should have extremly good support for completely dynamic scenes. Tracing those dynamic scenes is almost as fast and efficient as tracing static scenes.

When comparing some random code ICC should mostly be a bit faster than GCC and MSVC is usually the slowest. Of course there might be exceptions but that is what I and some other people I know have seen.

I made a ray tracer that's even faster! It can render everything in under a second. Although it's limited to 1x1 renders. It does support antialiasing though.

Marcello

No, you don't understand. In C, certain things are only/much easier doable through the preprocessor. Take linked lists, for example: a couple of macros will save you from casts. You don't need to do stuff like that in C++.

The key is the word 'unneeded'. You can ensure a binary module does nothing serious if the O/S does not let it do anything serious. It is the O/S that hands privileges out. Unfortunately, O/Ses do not provide the proper 'sandboxing' of applications, so VMs take over. A proper sandboxing of an exe would be ring protection, like in CPU: an exe could not touch resources of a higher privilege level; unfortunately no O/S implements this.

Yes, it's not free, but the point is it is doable.

If something can be in a library, then it need not be in the language.

C++ templates are preferrable to generics. I do not want objects to be allocated each time I use primitives.

The compile speed difference is not as important as it sounds, because projects are developed incrementally anyway.

So your point is moot, is it not? We don't live in utopia, we have to work with what we have.

Marcello

Compile time isn't incremental as soon as you're including other .hpp files. As soon as you modify a class, everything that uses it has to be recompiled, potentially everything.

In Eclipse, there is no compile time, everything is compiled automatically.

Marcello

This is a requirement for all C++ specification changes. If some feature can be done as a library, it should not be in the language.

It's worth noting, here, that it's possible to write unreadable code in any language. And people will do it. (hmm, ever tried reading any of James Lohr's source code?) In C, I think the more common problem is, er, under-design ... in which the code has been written as one amorphous mass, entirely lacking generality, so when it comes time to extend the code to new uses & such, it can get quite painful. And since your C IDE probably lacks sweet refactoring tools, it can be a lot harder to clean up than similar code would have been in, say, Java.

But this doesn't justify it as a design philosophy . . . or imply that the features discussed could be done as well if they were in library form.

Of course refactoring is technically doable in C++: you can always write a program to programmatically manipulate code written in any well defined language.

The point is not that it is impossible, but that it is much harder to get right.

So in the real world (the world of tools I can actually download and use today, rather than theoretical ones that haven't been written yet) it turns out that there are far more refactoring tools for Java and C# than there are for C++, and these have much richer features and are more robust.

It depends on the feature. Some things are fine in libraries, but others can benefit from dedicated language support for many possible reasons:

• Better error reporting.

• More efficient code generation.

• Nicer syntax.

For example take a typical lock idiom implemented via a library in C++:

{
    LockHolder lock(theObject);
    object->doStuffWhileLocked();
} // LockHolder destructor releases the lock

Versus built into the language in C#:

lock (theObject)
{
    object->doStuffWhileLocked();
}

Not a huge difference, but the C# version is slightly more concise, and more importantly, less error prone because the braces are enforced as part of the construct, rather than just relying on scoping rules to release the lock at the right place.

Another example is lambda functions. boost::lambda does an amazing job of implementing them in a library, but has lots of corner cases that can be very confusing in practice. Nowhere near as clean and easy to understand as the C# delegate syntax.

Of course not everything belongs directly in a language, but some things can be made nicer that way.

You are mistaken about how C# generics work, and are describing the Java implementation here. C# generics do not cause any unneccessary boxing.

Better than they were before, but still far from ideal.

Like the point about refactoring, this is the difference between theory and practice.

Yes, poor error messages are an implementation detail.

But also, the C++ template system makes it hard to give good error messages, as witnessed by the fact that no C++ compiler which actually exists today can come anywhere near the clarity of the errors you get from misusing generics in C# or Java.

I actually kind of like templates because they are cool and powerful: I'm not one of those people who thinks they are the spawn of Satan. But I'm also aware that they have a lot of issues, high on the list being that a lot of people just don't understand them (which is not aided by generally poor error reporting). So if I'm writing a library that I intend to be used by a wide audience, heavy reliance on templates is probably not a great idea. Generics do much better in that regard. The typical idiot Visual Basic programmer who barely knows enough to string together a couple of forms for his business would be totally lost if you handed him a template API, but can generally get on ok with using generic container types.

That feature just calls "make" whenever you save, and isn't recommended. The Eclipse CDT manual, right in the "before you begin" section, states: "For C/C++ projects this feature should be turned off, otherwise builds will be performed whenever a file is saved, including makefiles and header files."

Visual C# Express is free and legal.

Meh... I haven't had a legitimate windows since 3.11.