Quote:Original post by EasilyConfused
With regard to Lode's point about iterator names, I believe an 'auto' data type is being discussed for C++ that would derive its type from the right-hand side of its initialisation:

vector<int> v;
for(auto i=v.begin();i<v.end();++i)

// etc

Would obviously require an initialisation, like a reference, but would save a lot of typing. Does anyone know if this idea is still being bandied around for the next standard?

Actually the "auto" keyword lights up in my editor when using C++ highlighting, does this keyword have any meaning already in C++?

There is absolutely nothing wrong with learning another language. Anyone who thinks that broadening your horizons is a bad thing needs a clue-by-four upside the head. At the risk of overusing this somewhat stale analogy, all programming languages are simply tools in your toolbox. Sometimes a project will call for the gentle touch of a screwdriver; other times it will require high-grade explosive dynamite. Trying to hack through a mountain with a screwdriver is using the wrong tool for the job, so you want as many tools available to you as possible.

That said, learning another programming language is not a trivial endeavor (despite what those "Learn C++ In 21 Seconds!!!oneone~~!" books may tell you), if only for the reason that you don't have infinite reserves of time. You may be better served in terms of a career and as a problem-solver by choosing a language that is somewhat more mainstream, like C#, Java, or (dare I say it) Ruby.

I have used D a couple of times, and these are the main things I have noticed:

Better arrays (and therefore strings) than C (but not as good as STL containers).
Garbage collection (not sure if this is a pro or a con).
Anemic standard library, particularly no templated linked-list (but the community could wheigh in on this one, and write one).
Very fast compiles (the same small project of mine compiles in less than 1/10 of the time written in D).
No support for dynamic libraries (and this is the deal breaker for me).

Quote:Original post by Red Ant
I'm reading up about the D language and what I've seen so far looks very promising. So far I've been mostly programming in C++ and Python and I love both languages (of course I realize that neither language is quite without flaws, but I still think they're both great languages). I've also had contact with Java, C# and Perl but didn't find them particularly appealing.

I'm using D quite a bit and have been for three years or so. I have a D Blog and I maintain a collection of C bindings for libraries like OpenGL, SDL, OpenAL, and more over at dsource.org. I know of at least one commercial C++ game project that being converted to D right now, but that's the only commercial app I know of at this time.

D is still in development and is getting better with each release. There are warts, of course, particularly with some things not working as intended. Overall it's a pleasure to work with.

In the three years I've been using the language I've noticed that there tends to be two types of people who give D a look: the ones who glance through the docs and dismiss it offhand as inferior to C++/Java/ or wherever they are coming from, and the ones who actually dig in and try it out. The former aren't going to like anything new no matter how great it is. The latter are looking for alternatives and are generally happy with what they have found in D. I don't take much stock in the comments people make based on what they have read in the documentation. They have no idea what they are talking about until they have actually typed enough D code to get a feel for it. It's like the people who say, "Java is slow" - they are clueless.

Quote:Original post by Red Ant
D seems to aim at providing a 'better C++' sort of.

It's not trying to be a "better C++". It's trying to be a "better language" in general. It incorporates ideas from a broad spectrum. I think that it largely succeeds, but there are some kinks yet to work out.

Most of the ideas came from Walter's 20+ years experience of writing C++ compilers. One of his major goals for D is that it not only be easy for programmers to use, but also for compilers to parse. Decisions on syntax and features are always made with that in mind. A D compiler is much easier (and cheaper) to put together than a C++ compiler.

Quote:Original post by Red AntAre folks here using D a lot?

Few in the GDNet crowd tend to use anything outside of C++, though I seem to have noticed an increase in C# posts in recent months. I don't expect many people around here to bother with D for a long while yet.

Quote:Do they think D has a future?

I think it does. And so does the D community at large. If we didn't, we wouldn't be using it.

Quote: Apart from the fact that it's always good to learn new things, is there a reasonable chance that D will become an important language to know?

Walter Bright has been around C++ circles for over 20 years. In that time, he has built up quite a list of contacts. Big names in the C++ world, such as Scott Myers, Andrei Alexandrescu, Bruce Eckel, and Matthew Wilson, for example. Some of D's design was inspired from the ideas of, or discussions with, such people. Walter still has ongoing debates and discussions with them on the D way, both privately and publicly (some of the discussions you can see at comp.lang.C++).

Whether or not this means D will be 'important' remains to be seen. The problem is that it fills a strange niche that is somewhere between managed languages (Java, C#) and systems languages (C++, C). It offers many benefits over C++ and C, and can interface cleanly with legacy C code, but it remains to be seen if it's enough to convince a technical mangager that he should switch his codebase from C++ to D. And while I think D is much more pleasant even than Java, I don't think D is even going to be considered much by that market. The VM makes things like reflection, dynamic instantiation and some other features easier to implement than in a compiled language. D has none of that (though Walter has said relflection is something he wants to add down the road).

Whether it becomes important or not, there's nothing wrong with learning to use it. Programming in D has actually helped me to become a better C++ programmer. So even if I never use the language outside of my little hobby projects, it has still been worth learning.

Quote:Original post by swiftcoderBetter arrays (and therefore strings) than C (but not as good as STL containers).

Most of the container implementations I have seen in D are implemented on top of D arrays to enhance them, not replace them. D's dynamic arrays are so flexible that they can be used as vectors, stacks, queues, maps and even trees with very little effort. Most people do tend to wrap up that functionality and templatize it. I just don't see STL containers as being any better. I guess it's just a matter of what people are used to. Some D users have implemented STL-like libraries, others have implemented something modelled after Java's collection framework.

Quote:Garbage collection (not sure if this is a pro or a con).

Ultimately it's a pro. Right now, it's iffy. The current implementation gets the job done but it is by no means optimized. This will (hopefully) be remedied before a 1.0 release. But D does give you the ability to bypass the GC completely.

Quote:Anemic standard library, particularly no templated linked-list (but the community could wheigh in on this one, and write one).

A lot of people point to this as a deficiency. The library has a long way to go, for sure. But for now, Walter's focus is on stabilizing the implementation and the spec and crushing bugs. The library has been discussed multiple times on the NG and will get an overhaul before 1.0. Even so, there is already an alternative, community-driven, standard library called Ares.

Quote:Very fast compiles (the same small project of mine compiles in less than 1/10 of the time written in D).

What's really cool about that is when you use Derek Parnell's Build to compile your project. I've never seen a simpler or faster compiler tool chain for any language.

Quote:No support for dynamic libraries (and this is the deal breaker for me).

D has had support for DLLs for several compiler versions now. Initially, the implementation required that each DLL have its own GC, but that has been remedied. I'm not sure where the shared library support stands on Linux right now, though.