What version of C++ is good ?

I am currently using VC++ 2008 Express Edition.
As I have understand this is non-standard and therefor other versions of
C++ could be a better choice.

What I wonder is, what version of C++ is a better alternative.
To keep in mind is that I need a version that reads .txt files and do Very fast calculations on these and on Arrays as I am very depending of that.

VC++ 2008 does fast calculations and from what I understand C# is a bit slower on that part and calculations on Arrays.
I would also be happy to use C# 2008 Express Edition if it really is that fast in calculations as the VC++ 2008 Express Edition.
So I need a combination of Windows Form Application and fast Calculations.

Thanks in advance !

You seem to misunderstand.
C++ is native and always been and always will be. Microsoft introduced their own C++ targeting the .NET Framework. This C++ is non-standard and it referred to C++ .NET, or Managed C++. This is slow.
C# is also managed and targets the .NET Framework, but is standard. But the whole managed business is slow.
Native C++, the real C++, is what you want. And that is using the edition you're using now. Do Win32 projects and not Windows Forms.

There is no such thing as Windows Form Application and fast calculations. Well, unless you're willing to write dlls in C++ and interoperate to those dlls from C#, which can use Windows Forms. This is also acceptable, but tricky.

You seem to misunderstand, Elysia. C++ does not specify any execution model at all.

All right. You could say that there's three versions of C++. The first is pre-standard C++. This is roughly what Bjarne Stroustrup developed over the years. It doesn't have any properly specified feature set, and compilers built to this differ widely. Thankfully, they're also nearly extinct. Turbo C++ 3.0 and Visual C++ 6 are the last pre-standard compilers that still see some use, from what I can tell.)
The second is C++98 (and its minor revision, C++03), based on the 1998 ISO C++ standard (or the 2003 revision, incorporating all resolved defect reports to this point). All current compilers aim to support this standard to the best extent possible; few if any manage it fully.
The third is the upcoming C++09, the major revision of the C++ standard hopefully to be completed in 2009. Compilers are slowly starting to implement some of its features as experimental extensions; e.g. GCC 4.3 has support for quite a few of them.

Now, separate from that are compilers and their versions. The most popular compilers are GCC and MSC.
GCC is the GNU Compiler Collection, the dominant compiler on Linux, but also exists for many other OSs, including Windows (as part of the MinGW project). It supports many, many different platforms, is highly conforming to the standard, and produces quite good code.
MSC is Microsoft's C and C++ compiler. It is part of the Visual Studio suite and thus better known as Visual C++. It has acceptable to good standards conformance (since 7.1, i.e. Visual C++.Net 2003, improving in every subsequent version) and produces very good code, but only for Windows platforms. It's also considerably faster at compiling than GCC.
Other compilers of interest are Comeau C++, for its extreme standards compliance, and Intel C++, for its exceptional code generation (IA-32, IA-64 and Intel 64 architectures only, of course).


And then there's the C++-similar stuff. Managed C++ was Microsoft's first attempt at getting C++ to interoperate with their .Net framework. It was a spectacular failure. It was ugly and bugly.
C++/CLI was their second, considerably better attempt. It's still a horrible hybrid of poorly interacting features, but at least it won't hang your DLLs. It also has an ECMA standard going for it.

Microsoft and their stupid languages.
C++/CLI is just managed 2.0, even though it's being standardized. They pretty much ruined the syntax too.
However, it's still managed so using native with is not the easiest thing.
And managed is slow. Remember that.

> The third is the upcoming C++09, the major revision of the C++ standard hopefully to be completed in
> 2009. Compilers are slowly starting to implement some of its features as experimental extensions; e.g. GCC 4.3
> has support for quite a few of them.

After the C++98 standard came out, do you know how much of a time lag there was before compilers (in particular GCC) had reasonably full support, and do you think it will be roughly the same after C++09? I'm wondering how long it will be before being able to write code (in particular threaded code) using it. Also, do you know why there's such a long lag after C99 with most compilers still not fully supporting it? Is it just lack of demand?

I'm thinking it's also because of the difficulty in writing a compiler plus the time it takes to create an implementation of the features for the standard.
And compiler vendors are afraid to start implementing things before the standard is actually finished, because they've gotten burned before.

Well i'm using Dev C++ and I do not recommend VC++.

Quote:

---

Originally Posted by robatino

Also, do you know why there's such a long lag after C99 with most compilers still not fully supporting it? Is it just lack of demand?

---

I'm in no way in the know. So I apologize if what I'm saying is incorrect. However, the general feeling I have as a hobbyist without any kind of urge to know everything about C or C++, is the fact C99 did manage to separate C and C++ paths. I don't feel C as a subset of C++ anymore (or C++ as a superset of C, for the more sensitive). Particularly because the C committee seemed to insist at the time in bringing new features through changes to language instead of library additions.

I'm unsure if the upcoming C++09 manages do close the gap, or make it less wide. And that is the reason of the wait. Visual C++, for instance, seems to ignore for the most part C99.

Quote:

---

Originally Posted by PЯO

...and I do not recommend VC++.

---

Why?

GCC's adoption of C++98 was fluid, as becomes an open-source project. It's hard to say when it had reasonable support, although my memories seem to point to 3.2 as a version that sees a significant drop in the number of workarounds employed in Boost (typically a pretty good measure of conformance).
MS's adoption, on the other hand, was sudden. They released VC++6 only months before the ratification of C++98 - from what I heard in an only partially successful attempt to force the committee to see their way in a few contentious issues - and then did nothing for a long time. VC++.Net 2002 came out in 2002 and provided an updated standard library, but nearly no improvements in the compiler itself. (They were probably busy with Managed C++.) VC++.Net 2003 came out a year later and finally contained a massive leap towards conformance.
Given MS's current stance on the issue, however, I expect support for the bulk of C++09 to be considerably faster, perhaps as soon as 2011.


As for C99, I think the lack of adoption is simply because nobody cares about this update. The C programmers seem generally happy with what they have.

I use MSVS 2005 at home and 2003 at work. Personally I'd be lost without the nice features you get with MSVS. I'm not a MS hater or an MS lover but they deserve some props for 2003 and 2005. 2003 is horrible with C# and can hose your project but that's been fixed in 2005. 2005 is an extremely good compiler which produces very good code (for the Windows platform). I've not experienced 2008 yet but I will be purchasing it when it hits the shelves. And they updated MFC which shows me .NET CLI was a miserable failure. If they had not altered the syntax of C++ just to get .NET to work it probably would have been more well received. A lot of programmers would not mind calling out to this library or that b/c we do this every day. But changing the actual syntax of C++ and adding reserved keywords is going too far in my opinion.

C++/CLI is and remains a glue language. Thus, it must work with classic C++ and .Net equally. Thus, it requires separate syntax for each.

The design choices are appropriate for a glue language. In my opinion, the problem is that marketing failed to remember that that was all that it was.

How does C++.NET fit into all of this?

.NET is Managed C++... the nonstandard one.

Oh ok so they're the same thing.

Well, it's C++ and the .NET Framework, so some call it C++ .NET.
I didn't know there was C++/CLI, though (thought it was just another name for the plain old non-standard Managed C++).

ok. thanks. :)

>> Native C++, the real C++, is what you want. And that is using the edition you're using now. Do Win32 projects and not Windows Forms.

I see, I think I have got a better picture of the differences. My projects in C++ does consist of both a Win32 and Windows Forms Appl.
The Win32 project is the one wich does my calculations and I am very happy about the speed.
The Windows Forms application will on the other side not do any big calculations at all. This will only work as a "summary table" for the calculations already made in my Win32.

Well since I learned C# I use it if I need .NET support. And from my experiences at work I now know how to use C++ with C# and vice versa. So I guess I don't need the C++/CLI since C# basically fills that 'gap'.

I have some books on C++/CLI but even after reading them I just don't want to use it. Maybe it's just an attitude I have towards it be it right or wrong. I'm sure it has it's uses but for now I really don't want to dive into C++/CLI.

So to be fair I cannot really give advice one way or the other on C++/CLI. Use what gets the job done.