I'm not sure the reason I like C# over C++ is the fault of IDEs or the fault of the language.

One of my favorite things about VS C# is the intelli-sense, clear function descriptions when typing, immediate feedback on syntax errors before compiling. I find myself much more productive with C# even though I'm not doing much memory management in C++ anyway.

I don't see any reason why these features couldn't be implemented in C++.

Quote: Original post by ApochPiQ
Part of the goal of Epoch is to remain execution-environment agnostic; the language spec itself doesn't require a VM to underlie the running code (it just so happens that writing a compiler against a VM is far more efficient for bootstrapping a language than compiling down onto the bare metal). In fact one of my big goals with the project is to provide a highly controllable garbage collector (which can even be totally turned off should you so choose), rich support for bit-level twiddling and other stuff that generally goes into C/C++ code, and a method for modeling direct hardware interaction. You can think of it like a systems language with modern features.

Of course one of the big steps to gaining major acceptance will be to target an existing hardware architecture directly, probably through cross-compilation to something that already has a good machine code optimizer.

So would this language be in competition with .... D?

Epoch's feature set goes far beyond what D offers, especially in the parallel processing/concurrency department.

Quote: Original post by TheBuzzSaw
C++ would certainly benefit from improved syntax and a faster compiler, but the many attempts at "fixing" or "improving" the language tend to go the wrong way.

First off, I do not want a virtual machine between my program and the hardware. VMs are fine for many everyday things. General purpose business applications are fine running on a VM, but when it comes to real-time application development (primarily game development), a VM is simply not acceptable. I do not want a garbage collector running whenever it wants to; I'll manage my own memory, thank you very much. I'll take care of the low level optimizations. I don't want a VM rewiring my code on the fly. I just don't want a VM at all!

I would absolutely love it if C++ eventually adopted an elegant import system. I totally agree that #ifndef guard blocks are quite obnoxious, but considering that my IDE creates the two files and the guard block for me, I really don't care that much. It would be nice if there was a native C++ thread system, but I'll get by using OS-specific APIs.

There are simply too many harsh tradeoffs. C# adds a VM and locks me into one OS. Java adds a VM and performs poorly. C++ is a bit harder to code in, but I have much more granular control. Again, that control is unimportant when writing a business app, but I demand that control when dealing primarily with graphics.

You would have a point, if all you were doing was writing performance critical code. However, even in performance critical applications, the part of the code that is actually performance critical is tiny. (90% of execution time spent in 10% of the code, or how does that saying go again?) The logical thing to do would be to write the performance sensitive bits in C or C++, and do everything else in a modern, productive language. Using C++ for all of it is just masochism.

Quote: Original post by SimonForsman

Quote: Original post by Talroth
Going from playing with Python in interactive mode, C++ is truly painful when it comes to compile times. (A page or two of code for a simple OGL examples needs about 5-10 seconds from the time I hit compile/run till I see pretty pictures,...)

Do you go get yourself a sandwich when doing a total compile on a large project or something?

Its a feature, why do you think professionals all use C++.

http://xkcd.com/303/

:)

That is all well and good for a JOB, but what about when I actually want to Work and get stuff done?

Quote: Original post by ChurchSkiz
I'm not sure the reason I like C# over C++ is the fault of IDEs or the fault of the language.

The thing is, I use MonoDevelop to develop some stuff over on Linux, and even that sucked less than C++ code completion. So it's how C# allows better tools to be developed more simply. Well it's more CLI architecture than C# I guess.
Oh and about functional programming, yeah definitely on my todo list (F# specifically). I've played with haskell tutorials a bit and Linq seems pretty functional in it's approach.
I also noticed that I keep delaying learning F# cause I don't see any practical short-term gains, while two years ago I would have done it just for the fun of it. OMG this thread is like a bad introspection/look back session, bad because it seems my enthusiasm about programming is degrading waay too fast. I will go learn some random F# stuff now ...

Quote: Original post by TheBuzzSaw
First off, I do not want a virtual machine between my program and the hardware. VMs are fine for many everyday things. General purpose business applications are fine running on a VM, but when it comes to real-time application development (primarily game development), a VM is simply not acceptable. I do not want a garbage collector running whenever it wants to; I'll manage my own memory, thank you very much. I'll take care of the low level optimizations. I don't want a VM rewiring my code on the fly. I just don't want a VM at all!

Well there is AOT that theoretically negates the shortcomings of a JIT, mono implementing a LLVM back-end and going towards supporting AOT where reasonably possible.
GC is a double edge sword, I miss RAII and destructors from C++ but then again, dealing with other libraries/APIs and thinking about memory ownership is nut fun ether. The key to GC pauses is avoid using dynamic allocation in perf. critical sections, which is what you would do anyway.

Quote: Original post by TheBuzzSaw
I would absolutely love it if C++ eventually adopted an elegant import system. I totally agree that #ifndef guard blocks are quite obnoxious, but considering that my IDE creates the two files and the guard block for me, I really don't care that much. It would be nice if there was a native C++ thread system, but I'll get by using OS-specific APIs.

I've only really talked about C# vs C++, I didn't even mention the niceties that CIL introduces, think language interop, DLR, reflection. Adding a import system on to the C++ would fix some problems, but it would still be lacking IMO.

Quote: Original post by TheBuzzSaw
There are simply too many harsh tradeoffs. C# adds a VM and locks me into one OS. Java adds a VM and performs poorly. C++ is a bit harder to code in, but I have much more granular control. Again, that control is unimportant when writing a business app, but I demand that control when dealing primarily with graphics.

Mono is a decent cross platform .NET/C# implementation. It might not be on par with .NET in every area but it beats it in others (SIMD for eg.) YMMV

Quote: Original post by Antheus
Yea... C++ isn't C#...

Quote: my rude awakening regarding the actual usability of C++ compared to C#

You might want to talk to Rubysts or Pythonistas regarding usability of C#.

At least with MongoDB you'll be web scale regardless of language.

MongoDB is web scale?

Quote: Original post by Luctus

Quote: I do not want a VM compiler between my program and the execution.

Heh, is this what it would have looked like thirty years ago? [smile]

Yep, so I guess in 30 years time, VMs will have improved as much as compilers have over the last 30 years and they'll be ready for use ;D

Quote: Original post by RedDrake
The key to GC pauses is avoid using dynamic allocation in perf. critical sections, which is what you would do anyway.

One nice thing in C++ though, is that I can overload new for use by performance critical parts so that the code is still simple and readable (looks like dynamic alloc), but behind the scenes I'm using a stack-based mark and sweep allocator or some-such, which makes the dynamic allocations almost free.

Quote: Original post by Hodgman
One nice thing in C++ though, is that I can overload new for use by performance critical parts so that the code is still simple and readable (looks like dynamic alloc), but behind the scenes I'm using a stack-based mark and sweep allocator or some-such, which makes the dynamic allocations almost free.

Yeah it's a nice hack but does it break the "principle of least surprise" ? Having it explicit would actually be insightful IMO.
Anyway, not arguing that C++ doesn't have the upper hand when it comes to memory management but I'm saying that when it really matters you can still do something about it in C#, avoiding dynamic memory allocation being one of the things. Most of the time tough, it doesn't matter IMHO, and you are glad the extra work isn't there.