The future of C++

1,382

September 25, 2006 04:21 AM

Quote:Original post by Raghar
Quote:Original post by Calin
C will take assemblers place

How would you do in C?
shr eax, 4
sar ebx, 4

Please use pure C. For some task C/C++ is confusing, non selfdocumenting, and it works badly with 64 bit registers (it has unnecessary much abstraction).

>> and << are doing the job quite well. They typically map to shr/shl and sar/sal. Most compilers implement a int64 type (either as a "long long" or as a __int64). I don't see the interest of having to cope with the register size in a high level language - just trust your compiler, he'll do the job for you.

I have some problems to understand your statement. What's the point of controlling individual registers in C or C++?

To be fair, C already took the place of asm in 90+% of the case where asm was used. There are still some places where only asm can fit the bill (booting an OS and setting up the environment so it can use a C compiled program) but they are farily rare these days. You can even use a C compiler to produce efficient code for microcontrolers (for example, the Atmel ones).

But that doesn't even answer to the OP's question: what is the future of C++. The future of asm programming is not very important. It will still be there, and we all know that.

Regards,

-- Emmanuel D. [blog, in French] [blog, very bad googlized translation]

Anonymous

September 25, 2006 11:41 AM

Quote:Original post by MaulingMonkey
It's just a trade off. "Easily" implement enough to do "little" worthwhile ("out of the box") versus implement with a great amount of effort enough to do a bit more ("out of the box").

And it is still unfair if you compare the C++ portability of a tiny application written in C++, that only needs the C++ standard library with a huge enterprise application that needs half of the .NET libraries.
I mean take a look at the Compact Framework. They let some funktions out to make it smaller (and probably easier to implement). What deters anyone from writing an Even-More-Compact Framework, that just has the functionality of the indefinitely smaller C++ standard library?

MaulingMonkey

1,729

September 25, 2006 01:23 PM

Quote:Original post by Anonymous Poster
Quote:Original post by MaulingMonkey
It's just a trade off. "Easily" implement enough to do "little" worthwhile ("out of the box") versus implement with a great amount of effort enough to do a bit more ("out of the box").

And it is still unfair if you compare the C++ portability of a tiny application written in C++, that only needs the C++ standard library with a huge enterprise application that needs half of the .NET libraries.

Indeed. Good thing that's not what I was comparing at all when I was discussing portability, eh?

Quote:I mean take a look at the Compact Framework. They let some funktions out to make it smaller (and probably easier to implement). What deters anyone from writing an Even-More-Compact Framework, that just has the functionality of the indefinitely smaller C++ standard library?

You mean besides the fact that "anyone" typically won't be backed by a specific Microsoft project campaign, and thus very probably *won't* see widespread acceptance, applications targeting this minimalized framework, and thus gaining little benifit towards "portability" and platform independant C# applications in general?

'nuff said.

Raghar

97

September 25, 2006 02:41 PM

Quote:Original post by Emmanuel Deloget
Quote:Original post by Raghar
How would you do in C?
shr eax, 4
sar ebx, 4

Please use pure C. For some task C/C++ is confusing, non selfdocumenting, and it works badly with 64 bit registers (it has unnecessary much abstraction).

>> and << are doing the job quite well. They typically map to shr/shl and sar/sal. Most compilers implement a int64 type (either as a "long long" or as a __int64). I don't see the interest of having to cope with the register size in a high level language - just trust your compiler, he'll do the job for you.

What I tried to show are some inconsistencies of C++. Some type of work, like codecs, is better to do in Java (and use Java to exe optimizing computation guided compiler) than in C++.
>> is nice, however advanced languages have also >>> (shr). Until C++ would have defined different commands for sar and shr, it would be impossible to use some types of branch-less optimizations. Things are even worse behavior of >> is undefined.

Definition of exact size in bits for all standard data types is surprisingly still not part of specification. Reason? Only plausible reason might be legacy code, this is however a somehow bad reason if people are not happy with typing sizeof... sizeof... size you know. Other reason? Lot of programmers would need to learn new things, all old source code would need an PRAGMA oldC in its header files. On the other hand majority of smart C++ compilers might believe - if programmer didn't used sizeOf he expected an int to be a 32 bit data type.

Of course compiler Dependant compiling is also a possibility. Use int64 and hope the compiler would know what it is. However with this approach, even Java could have template (compiler time) meta programming, and operator overloading.

What I missed? Multithreading support and a memory model. Lack of build in thread library and papers about how should compiled code work on multicore system in heavily multithreaded environment is astonishing.
Actually C++ doesn't miss only build in tread library, it misses also build in image, sound, input, and window libraries, thus enforces the "we all like a command line" behavior.

Of course some problems are mitigated, slowly. It seems the C++ would become something like superset of the Java standard 1.0 .

Quote:I don't see the interest of having to cope with the register size in a high level language - just trust your compiler, he'll do the job for you.

I have some problems to understand your statement. What's the point of controlling individual registers in C or C++?

BTW I never said a programmer should handle registers, even in ASM this could be optional. My complain was about impossibility of easy and clear implementation of some algorithms, without using ASM. IMO standard data types should be virtual registers in the same way arrays are virtual representation of the memory.

Yes you can trust the compiler to create incredible bugs for you, or change behind the scenes algorithm to make you program crawl, however the better behavior is try to verify the resulting binary. Hopefully current compilers are smart enough to don't use "a - a" as reason why remove all error cancellation from the algorithm.

Anonymous

September 25, 2006 04:13 PM

Quote:Original post by MaulingMonkey
You mean besides the fact that "anyone" typically won't be backed by a specific Microsoft project campaign, and thus very probably *won't* see widespread acceptance, applications targeting this minimalized framework, and thus gaining little benifit towards "portability" and platform independant C# applications in general?

'nuff said.

Oh last time you wrote this small library was not even worth mentioning and now you need backup from Microsoft to realize it?

Quite strange answer. You mean C# is less portable and nobody would use added portability. Why then is portability an advantage? Nobody needs it, nobody wants it, nobody would use it.

I think a lot of people would apreciate a less cumbersome language than C++, with a less strange standard library (come on, you can't seriously defend the <

Deyja

920

September 25, 2006 04:41 PM

Quote:What I tried to show are some inconsistencies of C++. Some type of work, like codecs, is better to do in Java (and use Java to exe optimizing computation guided compiler) than in C++.
>> is nice, however advanced languages have also >>> (shr).

Shift-right makes sense for primitive types, and for nothing else. Why, then, is it unnaceptable to recycle the operator for streams?

Quote:Until C++ would have defined different commands for sar and shr, it would be impossible to use some types of branch-less optimizations.

Such as?

Quote:Things are even worse behavior of >> is undefined.

You are missing either a comma and a 'the', or 'if'. In either case... the behavior of operator>> is well defined. If you write a custom one that has undefined behavior, well, that's hardly the language's fault.

Quote:Definition of exact size in bits for all standard data types is surprisingly still not part of specification. Reason? Only plausible reason might be legacy code, this is however a somehow bad reason if people are not happy with typing sizeof... sizeof... size you know. Other reason? Lot of programmers would need to learn new things, all old source code would need an PRAGMA oldC in its header files. On the other hand majority of smart C++ compilers might believe - if programmer didn't used sizeOf he expected an int to be a 32 bit data type.

Actually, the size of primitives are very well defined. An int, for example, is atleast the size of a machine word. A short is at most the size of an int, and a char is at most the size of a short. You probably won't believe me, or will offer some other excuse, but not all systems have the same size words. A lot of embedded systems are still 16 or even 8 bit. If the size of int was guaranteed to be 32 bits, you would have to write different code for different platforms, or suffer performance penalties. 32 bit integers are slower than their 64 bit counterparts on many 64 bit systems, especially when alignment is considered.

Quote:
Of course compiler Dependant compiling is also a possibility. Use int64 and hope the compiler would know what it is.

First, 'compiler dependant compiling'? Second, what the hell does an int64 type have to do with

Quote: However with this approach, even Java could have template (compiler time) meta programming, and operator overloading.

I just don't see the connection.

Quote:
What I missed? Multithreading support and a memory model. Lack of build in thread library and papers about how should compiled code work on multicore system in heavily multithreaded environment is astonishing.

It has a 'memory model'. Threading is a property of the platform. Surprisingly enough, the vast majority of computers out there AREN'T running a task-sharing operating system. And there is a vast library of papers multi-threading. Most of them are language-agnostic. Nor does the presence or absence of multi-threading have any effect on the generated code.

Quote:Actually C++ doesn't miss only build in tread library, it misses also build in image, sound, input, and window libraries, thus enforces the "we all like a command line" behavior.

Again, those are all properties of the platform. It is the lack of these things in the C++ standard library that makes it portable. These services are all platform specific, and are supplied by platform specific libraries. Also, are you suggesting that C++ can only be used for command line applications? That's absurd.

Quote:
Of course some problems are mitigated, slowly. It seems the C++ would become something like superset of the Java standard 1.0 .

Actually, it seems to be the other way around.

Quote:BTW I never said a programmer should handle registers, even in ASM this could be optional. My complain was about impossibility of easy and clear implementation of some algorithms, without using ASM.

An example?

Quote: IMO standard data types should be virtual registers in the same way arrays are virtual representation of the memory.

No. The compiler is much better equiped to make effecient use of registers than the programmer is.

Quote:
Yes you can trust the compiler to create incredible bugs for you, or change behind the scenes algorithm to make you program crawl,

[rolleyes]

Quote:however the better behavior is try to verify the resulting binary. Hopefully current compilers are smart enough to don't use "a - a" as reason why remove all error cancellation from the algorithm.

A minus A? Error cancellation?

http://jemgine.omnisu.com

Deyja

920

September 25, 2006 04:52 PM

Quote:Quite strange answer. You mean C# is less portable and nobody would use added portability. Why then is portability an advantage? Nobody needs it, nobody wants it, nobody would use it.

No. He meant that any code written to target this 'more compact framework' written by 'someone' would be LESS portable, for a variety of reasons.

First, the user probably already has the .net framework. The size of the distrobutable is irrelevant when they already have it.

Second, 'anyone' is not someone I trust. I am not downloading nor installing this additional framework. Microsoft's framework I can trust not to be malicious. I can even trust an opensource framework written by committee.

Third, the code targetting the platform is only portable to systems that platform has been ported to. There are lots of ports of the official framework. How many are there of this new one? Are you going to write them?

Quote:
I think a lot of people would apreciate a less cumbersome language than C++, with a less strange standard library (come on, you can't seriously defend the <

Assuming you meant the stream-insertion operator and not the less than operator, yes, I can 'seriously defend' it. Please examine the alternatives. There are really only two that offer the same functionality. Or, well, only one, come to think of it - member function chaining won't work : It prevents conversions on the left hand side.

stream_insert( stream_insert( stream_insert( std::cout, "Hello"), " World!"), std::endl);

That still, unfortunatly, totally screws over the modifiers like 'setw'.

http://jemgine.omnisu.com

MaulingMonkey

1,729

September 26, 2006 04:19 AM

Quote:Original post by Anonymous Poster
Quote:Original post by MaulingMonkey
You mean besides the fact that "anyone" typically won't be backed by a specific Microsoft project campaign, and thus very probably *won't* see widespread acceptance, applications targeting this minimalized framework, and thus gaining little benifit towards "portability" and platform independant C# applications in general?

'nuff said.

Oh last time you wrote this small library was not even worth mentioning and now you need backup from Microsoft to realize it?

In the case of C#? Yes for widespread acceptance of that library, since it's basically Microsoft's language in terms of inertia and heading development. In the case of C++, the equivilant would be it's standards committee. Guess what - they are 100% behind C++'s standard library. It is no accident that this library has gained widespread acceptance/use, even for all of it's flaws which are basically *explicitly kept* for the sake of *bending over and taking it from the rear* as it is savaged by backwards compatibility needs.

And even *being* a standard, it's only rather recently that, say, the game programming community actually warmed up to it, instead of treating C++ as C with classes. That seems to be evidence enough that there's a lot of resistance to widespread acceptance of such a thing.

Quote:Quite strange answer. You mean C# is less portable and nobody would use added portability.

Given the number of windows specific programs in a world of multiplatform libraries that come from just about every ofrice of google? Some people would use it if developed, matured *and* was a significant project (which introducing small APIs to shirk the responsibilities of implementing the full .NET library fails on all counts) *or* was standard.

Would someone code it in the first place? With a nice big standard out there, probably not. You don't see people trying to implement a new container library for C++ on a platform that dosn't even implement the standard ones, typically - one tries to get basic *standard mandated* functionality running first, so you don't feel like a lying dickweed in calling it a C++ environment. Same would apply to C#.

Quote:I think a lot of people would apreciate a less cumbersome language than C++, with a less strange standard library (come on, you can't seriously defend the <

Well I'm not sure what all you were going to say, but I certainly never claimed anything to the contrary of what I can see. While standards are nice and wonderful for portability and widespread use/acceptance, it comes at the price of keeping a lot of mistakes in place (Ever tried to close a template with >>? Use &vector[0] on a std::vector<bool>? Invoke one of the umpteen million undefined behaviors of C++? Used language aspects that plain out don't compile on more than one C++ compiler because the language is too damn complex for everyone to get it right?).

When coupled with backwards compatibility with that bastard language known as C, you can bet this brain dead stepchild zombie of a language has much better alternatives in many (most? all and I just don't know it yet?) situations. But yeah, in a way, it still is more portable than C#.

Anonymous

September 26, 2006 06:35 AM

Quote:Original post by MaulingMonkey
But yeah, in a way, it still is more portable than C#.

You are totaly right but I wanted to make clear, that this is not due to the almighty and untouchable C++ and its libraries, but the efforts put into it.

Most languages with the same support could achieve the same, including C#.

The future of C++

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

The future of C++

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines