Slashdot Mirror

Compilers for Windows: Microsoft's, Borland's, icc, gcc-mingw


For Windows there are also

Digital Mars - used to be Symantec C++

LCC

Open Watcom

I think there are more for Linux also, like Visual Age
etc.

X509CertificateSimpleChainVerifier x = new X509CertificateSimpleChainVerifier();

Definitely.

2) Java has garbage collection, C++ doesn't. This is specified in the language. This affects performance.

Hmm... this is probably true in a lot of cases, but read this. (The guy's written a C++ compiler, and the D compiler - D is garbage-collected).

Also, the specification of Java says that it should be compiled to byte code and executed in a JVM.

Really? IIRC, the language spec only defines the semantics of the language, and the VM spec talks about the format of programs, so GCJ could in theory be compliant with the language spec, but the VM spec would be irrelevant. Of course the language was designed to be interpreted, so there are probably performance penalties in both JITed and precompiled code there...

Personally, I'd love to see D being used instead of .NET or Java. For one, I don't trust Microsoft to let Mono live when an important part of the Linux desktop is dependant on it. Second, as for Java, it leaves too big of a memory footprint, and it is still not available on all distros.
Besides that, I don't like VMs, but that's a personal thing. :)

So, why not D? Most people knows the advantages, or can otherwise check the website [http://www.digitalmars.com/d/index.html]. It's very clean, familiar, fast and gives most or more advantages than C#/Java. It has gotten far in development. The frontend is being integrated to GCC. So why not?

long square_root(long x)
in
{
assert(x >= 0);
}
out (result)
{
assert((result * result) == x);
}
body
{
return math.sqrt(x);
}

and it's called the D Programming Language. It has Design by Contract and unit testing built in to a C++ like language.

already has, as part of the language, Design by Contract and unit testing. The D Programming Language. These provide the robustness capabilities, but while having the power of a C++ like language.

The D programming language has design by contract. It seems pretty similar to the SPARK idea...

Check this out.

It's part of a presentation that can be found here


-Reuben

The D programming language has design by contract. It seems pretty similar to the SPARK idea...

Check this out.

It's part of a presentation that can be found here


-Reuben

The D programming language has design by contract. It seems pretty similar to the SPARK idea...

Check this out.

It's part of a presentation that can be found here


-Reuben

They might not be revolutionary, but the is a few ideas
which can be just to reduce the number of bugs in a program.

1) 100% unit test coverage of your programs.
2) Statistical Debugging

3) Valgrind

4) The D programing Language
with build in support for unit testing, contracts and class Invariants.

Theoretically, it's because having a limited-size counter limits the sizes of your strings, such that one couldn't load into a Pascal string a text file with more than 65536 characters (256 in the example you provided, but no one would use a single byte for length count).

Conversely, zero-terminated strings are limited only by available memory. Still, there's a tendency for them to go away and be replaced, except for the kernel, because .NET and JAVA aren't going to go in there for a long time yet: they just weren't made for it. D might, though.

Good god, people, the creator of the language deserves better than a score of 1---especially when he's counter-attacking a piece of FUD that got way over-modded.

Further discussion on memory management as it relates to D can be found here.

A slick, responsive 3D fighter game written in D (and somehow unencumbered by the burden placed on it by the garbage collector) can be found here. Source included, so you can see how slick it is on the inside.

And Walter: Thank you. I've spent a lot of time reading and interpreting the ISO C++ standard, and it usually leaves my brain feeling itchy, flaky, and swollen. With that in mind, I'd just like to say that, after reading all the specs I could find, D (so far) seems to me like the Gold Bond Medicated Powder of programming languages. :-)

The real question is, when are you going to write a book on D? :-)

see templates

Uh, again, you seem to have misread the topic of this discussion

No, you have failed to see that I was responding to the comparison sheet that the author of the D language put together and that was linked to from the story. That comparison sheet contained numerous errors and misstatements about C, C++, C#, and Java.

"[The ability to integrate assembly code into the high-level code is] an implementation-dependent feature, not a language feature of C/C++."

Not really. To be useful, the language has to be flexible enough to let the asm code talk to stuff written in the higher-level language. How do you do that with Java/C# again?

As I was saying, none of the languages provide it: not C, not C++, not Java, not C#. Many C/C++ implementations happen to contain that extension, but it's not a feature of the language.

But I don't see any reason why it should be hard to add to C# or Java if anybody cared to; after all, Lisp had in-line assembly.

I have, with Java, and it is far from being trivial, and not all code can even be compiled in this way (typically because it depends on swing or similar libraries which make undocumented calls right into the VM).

I simply stated that the Java language can be compiled that way. Obviously, most Sun Java programs cannot because they rely on numerous proprietary libraries.

As for C#, I have yet to see a convincing native code compiler. No, pre-JITting is not the same thing, as you still need a ton of supporting framework (and often the original DLLs for the metadata).

Java and C# have native code compilers that work in non-batch mode. In the case of C#, it's a standard component of Microsoft's platform. No, it doesn't generate standalone code, but that wasn't the point made in the comparison.

What functionality is that then? D appears to have all the features I like from C# and Java (as a language) but without the obnoxious 30mb runtime download for the VM and associated tools. Why, pray tell, do I want a VM in the first place?

The ability to load code at runtime, the ability to write software components that work on different CPU architectures even if the main program runs natively, the ability to write portable code transformation tools, and the ability to sandbox untrusted code, among others.

Besides, you are living in a dreamworld if you think that C or C++ require less space for the same functionality. While I think that Sun's JRE is bloated in terms of how much functionality Sun throws into it, in terms of bang-per-megabyte, the JRE and other VM-based languages are far better than natively compiled languages.

That's wierd. I could have sworn that both Java and C# were getting generics/templates in their next versions.

No, C# and Java are not getting templates, but they are getting a parameterized type facility; the comparison table should have listed that but failed to. If D indeed has templates (meaning, the same kind of facility as C++), then that was a lousy design decision.

Altogether, I suspect that both he and you are simply confused about what templates and parameterized types actually are, although you seem to be confused in slightly different ways from each other.

Heh.

Nice feature comparison, except for the fact that it's wrong. Perhaps the authors of D would do better if they actually learned C++ first? Designing a new language when you're clueless is the first sign of disaster. Look at Java.

Resizeable arrays: D Yes, C++ No

BZZT.

Arrays of bits: D Yes, C++ No

BZZT.

Built-in strings: D Yes, C++ No

BZZT.

Array slicing: D Yes, C++ No

BZZT.

Array bounds checking: D Yes, C++ No

BZZT.

Associative arrays: D Yes, C++ No

It's called a map.

Inner classes: D Yes, C++ No

BZZT (perhaps they meant specifically the automatic parent resolution?)

typeof: D Yes, C++ No

BZZT.

foreach: D Yes, C++ No

BZZT.

Complex and Imaginary: D Yes, C++ No

BZZT.

Struct member alignment control: D Yes, C++ No

Give me a break, every C++ compiler supports this. It's just implementation defined.

Now go look at D's page on Design By Contract in C++: here

Notice that any C++ programmer can come up with a far better implementation than theirs using child class destructors and inlining. In fact, Stroustrup even put one in his book in case you're having trouble getting the brain in gear.

The comparison list combines cluelessness and sophistry ("C++ doesn't have this feature! It's in the STL, not the language" - oh please) to try to promote their own half-baked language.

Conclusion:

Yet another half-baked useless language.

I don't get it, what is wrong with D's templates. Admittedly, I haven't used D, but it sounds like it has templates to me...

The article is wrong. D is not at all C compatible. See Programming in D for C Programmers

The D approach is pretty much taking the best from C++, Java and C#, and you can find a lot the stuff you were asking yourself "why is this not possible in [insert current language]" in it. For example what they call function deletates is really missing in C++.

However, some time will pass until a usable compiler will be available for *any* plattform.

The D approach is pretty much taking the best from C++, Java and C#, and you can find a lot the stuff you were asking yourself "why is this not possible in [insert current language]" in it. For example what they call function deletates is really missing in C++.

However, some time will pass until a usable compiler will be available for *any* plattform.

I was oddly confused when I read that un-sourced term in the quickie part of the story...so, from this page:

Contracts are a breakthrough technique to reduce the programming effort for large projects. Contracts are the concept of preconditions, postconditions, errors, and invariants. Digital Mars introduces the first C and C++ compiler to support contracts. Building contract support into the language makes for:

1. A consistent look and feel for the contracts
2. Tool support
3. It's possible the compiler can generate better code using information gathered from the contracts
4. Easier management and enforcement of contracts
5. Handling of contract inheritance


The idea of a contract is simple - it's just an expression that must evaluate to true. If it does not, the contract is broken, and by definition, the program has a bug in it. Contracts form part of the specification for a program, moving it from the documentation to the code itself. And as every programmer knows, documentation tends to be incomplete, out of date, wrong, or non-existent. Moving the contracts into the code makes them verifiable against the program.

fits the requirements just file. TDPL. There's even a gnu implementation of it now.

This seems like a natural fit for developing desktop applications that don't feel like they're running under a VM, yet they are still garbage collected.

But it ain't happening any time soon. Nevertheless: D, anybody?

I would like to see a language that preserves as many features of C++ as possible while adding garbage collection, memory safety, language-based security and guaranteed binary compatibility between platforms/OSes. I don't think managed C++ is "it". Why can't a VM support multiple inheritence? Any pointers?

It's been a while since I looked at it, but the D language seems to address many of your gripes (other than multiple inheritance).

There are compiled languages that are arguably better than C, such as Eiffel, Modula-3, and D. These may be promoted by companies, but surely not controlled. C is popular because it's simple and powerful, is good enough, and has inertia. But that doesn't necessarily mean it's the best.

Maybe because the D programming language is set to replace it. As if we'd be so lucky.

This is one of the big problems with C & C++. Several languages either catch these, or can catch them if the debug flag is set. But they need to know what's a pointer, so no integer casts are allowed.
Examples of languages that can handle this particular problem include Eiffel, Ada, and D. (Actually, as D is still in beta, I shouldn't have mentioned it. But it's my current favorite. Digital Mars D.)
Eiffel is another good choice, but many implementations are a bit slow. And Ada is complex compared to C (though not compared to C++) , but it has many other nice features...as well as a few clunky ones.

I'm sure that there are many other languages that can handle this problem, but those are the only one's that I know that are also suitable for systems programming (*two* constraints).

can't imagine a Java program full of casts

If you can't imagine it, you haven't seen it, either.

If you haven't seen a Java app with lots of casts, it means the app didn't use collections. Which means it was a trivial app.

it's not applicable to Java or other GC languages

D can do it.

But if you can write a C++ program without memory leaks you will have no problem closing every resource

I don't have to close anything. RAII takes care of that.

Because if there are less people trained to do a thing you have to search harder/pay more/train more before things get done

But if people aren't trained, how are they gonna learn ? it's a chicken and egg problem.

I don't understand what is your point here. You first seemed to support the idea that Java was to slow to do this, now the opossite. Or where just mentioning the article? I'm a little lost here

I never said that Java is slow in numerical computations. I said that the article(s) you posted had flaws in it(them)...these "flaws" are deliberate, in my opinion, from people that never gave a dime understanding C++ and how they can be productive with it. For example, they did not compare the top Java version 1.4.2 against a top C++ compiler such as the Intel one. It's unfair, it's biased.

I also said that Java is generally slower than C++, mostly because of the way collections/iterators work, no value objects and because of the GC.

I think that Java will always be slower (even a little) than C++.

Well, the difference will be so small, as to be negligible. Eventually, the language and the JVM will improve so much as to reach the state of a statically compiled language.

But I remember when most programs were made in assembler and C was the slow new language. C winned in the because it was easier (that subjetive concept) to write programs in, rather that because of it's speed.

Nope. The jump from assembly to C gave you a 10x boost in productivity, while the jump from C++ to Java gives you 0.1x boost. In reality, it gives you nothing, if the libraries you use are well written(Qt for example).

Have you worked with Qt ? it is the best library ever written. Don't let others fool you: it gives you the full power of C++ and Java!!! you don't even have to manage memory. It has a wonderful signals and slots mechanism, and plenty of classes for everything. And a program you write under Windows runs as-is in Linux/Mac/Solaris/Unix. No, I don't work for Trolltech, but I am so much impressed with it, I can't stop talking about it. Something made in Java is usually done faster and better in Qt.

Of course, Java has its own good points. But its not all that is cranked up to be. For example, you may have not to delete things, but you sure have to make pointers null. IF you don't, memory is not released. I have seen this numerous times, and it is the Java memory leak problem (leak, in the sense that it is never freed).

You can get garbage collection and array bounds checking in fully compiled languages (such as D), too.

And you'd better still worry about such things to a certain extent, or else you'll be throwing exceptions on legitimate usage cases when your fixed-size buffer turned out to be too small, running out of memory because you didn't bother nuking references to old objects, etc.

Nothing will ever get rid of C or C++. Java tried, C# tried, hell, D language tried. When's the last time you heard of D?

Oh, and if your next question is: why would we want to get rid of C... you're kidding, right?

The D Programming Language is the evolutionary successor to C++ and does have class invariants, preconditions, postconditions, and Design by Contract built in to the core language.

The D programming language seems to be what you're looking for.

No runtime environment. Native string type. Garbage collector that you can suspend. And my favorite, object properties.

No, the successor to C is D

... also, make sure you don't miss the alpha download if you wish to try it out (Windows and Linux).

There's a D?

D Programming Language Reference

is a free download from Digital Mars and it can be used to develop commercial apps.

I'm a slashdotter, and I find the article quite interesting. As a programmer, it helps to keep abreast of *all* options out there, politics/personal opinions aside. Yes, you're right, the article is there to expound the benefits of .NET, but is that a bad thing? No, it's a valid platform for the development and deployment of software, and that's news to slashdot developers.

In fact, I'm somewhat disappointed at the severe *lack* of articles such as this one for the developers section. Developers section articles, indeed articles on programming and languages in general, are unfortunately rare on slashdot anymore.

Personally, I'd like to see more exposure of newer languages, like D, on slashdot.

dostuff($param) or die("Couldn't do stuff!");

to be honest, i don't understand the motivation for using vc++ in a non-professional (read: outside of work) capacity in the first place. i realize the $99-$129 "professional version" price tag that i've seen, and the even cheaper academic pricing, are not too shabby compared with "enterprise" pricing... but they're still more expensive than $0! there are more than several freely available alternative compilers for win32 machines - cygwin gcc, borland (debugger also), djgpp, open watcom, lcc, MinGW, and Digital Mars (nb: haven't examined the license in detail) to name a few. can anyone else shed some light on why a developer might prefer vc++, or under which circumstances vc++ might be considered a clear-cut better choice than one of the alternatives listed above?

>>> hi = "hello"
>>> hi[-1] # Equivalent of 'tail'
'o'
>>> hi[0] # Equivalent of 'head'
'h'

Besides, 'D' is already taken

Actually C++ is not D, D is another language which tries to be a bit less broken than C++. Unfortunately, while D looks like a nice language it also looks as though it may be impossible to write a compiler for it... (After over 3 years in development the compiler still doesn't implement the whole language)

D exists and is implemented here.

The D Programming Language is the successor to C++.

D is here

D Language

It's a cross of C++ with some Java-ish features and some design by contract thrown in. Fine language if you ask me.

I have yet to see this mentioned (which surprised me)

http://www.digitalmars.com/d/

It's taken.

Already done!

D Programming Language