What's new

Falling in love with C++11

Hacktarux

Emulator Developer
Moderator
Did you already discovered all the nice new features of this new standard ?

I know i could not go back to previous compiler when i replaced:
Code:
boost::shared_ptr< std::map< std::string < std::map< std::string, std::string > > > >::iterator it = mymap->find("astring");

with

Code:
auto it = mymap->find("astring");

That little keyword with some other ones like, integrated shared_ptr, integrated bind and foreach made me wonder how i could read old c++ code in the past :)

There are a lot of other new features, what do you think is the most important for your usage ?
 

Cyberman

Moderator
Moderator
LOL

Well how about only using C++ 2011 in anything with greater than 16megs of ram and 8megs of program space? It's a real memory pig from what I have seen.

Also remember that lovely syntactic sugar is hiding a bunch of stuff!

I remember when I was looking at the output code for different objects used in C++ it was quite scary too see what insanity those "cute" syntax things invoke in terms of the processor. All the internal pointers for example in a typical C++ object aren't particularly safe, the saving grace is the C++ compiler handles them, however if you noticed a lot of C++ compilers in the last 10 years have egregious bugs in them. GCC/G++ had a long standing one with the volital keyword which actually didn't become noticeable unless you changed the optimization level, needless too say some modules in the kernel of linux stoped working depending on your optimization level. What was happening was the keyword lost it's meaning in the optimization step of the backend (woops). Apparently Visual C++ Intel and a number of other major compilers had this bug until some students who were doing a disertation on optimization steps discovered this. :D

Anyhow depending on what you are doing you need to be keenly aware of what the compiler is actually doing with your code.

I always look at the assembler output for this very reason (scarey I know but rather important).

You may wish to turn on name demangling before looking at it (if you can in your compiler).

Cyb
 
OP
Hacktarux

Hacktarux

Emulator Developer
Moderator
Well, for sure you have to be VERY careful with C++ but it is usually designed for speed, you still have a really deep control of what is going on. However, i agree, it is complex to think about everything with this language. For example, i think about the new move constructor feature. The idea is nice and if you use it correctly it will greatly help to produce nice asm code but it is one more thing to think about and each time one of these feature is added it is increasing a learning curve that is arguably steep enough.

I do not feel compiler bugs are that common as i have not encountered one despite maintening very complex c++ programs for years. And i do not think the code is taking that much space. Most of the time it is the symbols that are taking all the binary space.

In the example above, there is very little code produced for this line. The advantage provided by the new standard is to avoid repeating over and over the same type precision you specified when declaring your variable initially.
 

Cyberman

Moderator
Moderator
Well, for sure you have to be VERY careful with C++ but it is usually designed for speed, you still have a really deep control of what is going on. However, i agree, it is complex to think about everything with this language. For example, i think about the new move constructor feature. The idea is nice and if you use it correctly it will greatly help to produce nice asm code but it is one more thing to think about and each time one of these feature is added it is increasing a learning curve that is arguably steep enough.
Ineritence I always said "is a two edged sword" use carefully (snicker). C++ can be quite combersome and slow, it really depends on how 'easy' you made it for yourself. The use of virtual constructs etc are attractive but you could inherit the wind if you aren't careful. I heard C++ 2011 added static object creation control? Is it true? I find it hard to agree with that after 20+ years of C++ code without it and people creating functional code without it. (Just curious of course.)
I do not feel compiler bugs are that common as i have not encountered one despite maintening very complex c++ programs for years. And i do not think the code is taking that much space. Most of the time it is the symbols that are taking all the binary space.
Most of my frustration with compilers has been the backend generating erroneous code. For example you would think a unsigned long long size would be 8 bytes when you add a unsigned long too it (syntactically renamed uint64_t and uint32_t) however I discovered it did not properly promote the unsigned integer to a 64bit int. Instead it masked the 64bit integer lower 32 bits and added a uint32_t (err weird). So by descretely placing (uint64_t) in front of the uint32_t you would think it would promote it correctly right? Nope it didn't I found I had to do something like (uint64_t)((int32_t)<variable>) and that for some reason fixed the code generation. Probably something to do with how they handled unsigned long versus long (I am sure they tested it! heheh).
Anyhow compiler bugs can be a bit frustrating when you have to deal with things like swaping byte data or moving a 32 word into a 32bit 2 word register. Endianess has too be checked I've found on every compiler and the worst part is they don't always follow the endianess for all integer types.
In the example above, there is very little code produced for this line. The advantage provided by the new standard is to avoid repeating over and over the same type precision you specified when declaring your variable initially.
Well there is the issue of precedence, not sure if that is a consolation for all those who had to type their fingers off to do something simple or not (LOL).
Some features added by compilers I liked for example the property keyword in C++ builder was handy for making virtual array variables in C++. However doing things like that does not per sea make FAST code :D

Anyhow good to see someone looking at programming languages other than (big cough) JavaScript. ( I know I'll wash my mouth out later).

Have you used Python for anything by the way? I'm looking at writting a module in it for a program called KiCAD and I was wondering if you had opinions (or reasonable thoughts too) on it.

Cyb
 
Last edited:
OP
Hacktarux

Hacktarux

Emulator Developer
Moderator
Yeah, sure ! That's a really nice language.

I'm mainly using two languages at work: C++ and python.

Here's how i would choose between C, C++ and python:
- C low level data handling and of course when i need speed
- C++ when i need some abstraction for complex data and i also need speed. I'd also use if for scalable servers: BOOST ASIO is really nice.
- python for batches and anything that needs to handle of data and is not particularly cpu critical (if it is I/O critical, the language won't change much of the issue). I am also using it to write quickly a prototype when i need to test something.

I would particularly look at the generator part of the language. Many things can be written in a more natural way in python than in most other languages. For example, if i want to create an array with even numbers from 0 to 20, you can write:
Code:
myarray = [ i*2 for i in range(10) ]

That may not seem a lot but in practice this syntax alone make python programs much more concise and easy to read.
 

Narann

Graphic programming enthusiast
About this code snippet, while you talk about generators, maybe you know it but range() doesn't use generator and create a full list in memory. xrange() use an iterator.
 
OP
Hacktarux

Hacktarux

Emulator Developer
Moderator
Yes, i only wanted to show a simple thing to give an idea on the way we can write things in this language without going into details and still managed to do a mistake ;-)

Anyway, i recommand learning it Cyberman. You can be operationnal really quickly even if there will a tremendous amount of nice features you will only discover with time.
 

Toasty

Sony battery
I love C++, but lately I feel more and more like it's getting too big for its britches. More and more (admittedly useful) features get tacked on, and odd little things here and there get standardized in funny ways or left up to implementation, such that the language and its usage can really bite you if you don't really know the 'C++ way' to do things. And with how big it's become, the 'C++ way' can be quite a chore to master. C is beautifully simple by comparison, though you'll have to be a lot more verbose to get some of the same things done.

I wish there was a Java or C# that wasn't encumbered by Oracle or Microsoft respectively. (Amazingly, Microsoft seems like the lesser of those two evils lately with their open sourcing of much of .NET.) I think D shows some real promise, as it's kind of a re-imagining of C++ with most of its features included from the get-go rather than being tacked on as afterthoughts. (Meta programming in D looks so clean to me compared to C++ syntax.) Unfortunately, support for the language is moving sluggishly.
 

Narann

Graphic programming enthusiast
If you like D, you would like Rush. Personally, I like C++ but you have to limit yourself if you don't want to expect problems, specially on projects involving a lot of different peoples.

In Fabien Sanglard Treepasser's code review he talk a little about how big C++ project can became and how big it could be to maintain because of the knownledge requierement it requiere when a project "became" less "C++ way" (every big project actually). There is some cool quotes here. My personal favourite:

C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, it blows away your whole leg. — Bjarne Stroustrup

It seriously resume what I think about C++.
 

Cyberman

Moderator
Moderator
I love C++, but lately I feel more and more like it's getting too big for its britches. More and more (admittedly useful) features get tacked on, and odd little things here and there get standardized in funny ways or left up to implementation, such that the language and its usage can really bite you if you don't really know the 'C++ way' to do things. And with how big it's become, the 'C++ way' can be quite a chore to master. C is beautifully simple by comparison, though you'll have to be a lot more verbose to get some of the same things done.
I wish there was a Java or C# that wasn't encumbered by Oracle or Microsoft respectively. (Amazingly, Microsoft seems like the lesser of those two evils lately with their open sourcing of much of .NET.)
They had to open source .NET because of mono which basically did .NET stuff only BETTER. LOL (pathetic)
I think D shows some real promise, as it's kind of a re-imagining of C++ with most of its features included from the get-go rather than being tacked on as afterthoughts. (Meta programming in D looks so clean to me compared to C++ syntax.) Unfortunately, support for the language is moving sluggishly.

I believe too much fractioning and empahsis on the egocentric methods of programming have become a pit fall for all.

Honestly C is quite viable, although C++ with a few carefully choosen features is fine. I use C++ but seldom do I use "the features" people crow about.
The BEST features I have found in C++ are the operator for an object type features.
That makes the syntax of using for example fixed point less of a pain.
A perfect example of C based fixedpoint would be something like
Code:
A = fixedpt_mul(fixedpt_fromint32(B), fixedpt_fromfloat(M_PI));
which with operators would be written
Code:
A = (fp)B*(fp)M_PI;
Oddly doing the EXACT same thing (LOL) but less obscure as to what it's doing (heh).

For Fixed point multiplication one has to use saturation or the values can get out of hand (and not make sense at the same time).

I am wary of obscuring what I am doing so I try to make it obvious.

I know both sides. Currently I'm fighting with a freaking compiler that you can't turn off some of the optimizations (WTF?) Sigh. What compiler do you make that assumes IT knows what you want to do?
I know most people new too C screw up a lot of things but ... it's a pain not too be able to set a break point without having to use keywords damnit!
(I had to do something like
Code:
volatile int32_t value;
to force my break point to work after I had turned off optimization it was STILL assuming it knew everything).
Oh well I am looking at Python as my PERL replacement for now. I do use SED on occasion (which is how I, at one time got into PERL).

- - - Updated - - -

If you like D, you would like Rush. Personally, I like C++ but you have to limit yourself if you don't want to expect problems, specially on projects involving a lot of different peoples.

In Fabien Sanglard Treepasser's code review he talk a little about how big C++ project can became and how big it could be to maintain because of the knownledge requierement it requiere when a project "became" less "C++ way" (every big project actually). There is some cool quotes here. My personal favourite:



It seriously resume what I think about C++.
All I can say is "I hate it when I do that" LOL.

Most of the C++ I've used is very striped down, very few of the 'new features' are ever going to be remotely even close too be used.
C++ has become more of a project management burden. It also can be very difficult too make optimized code in depending on how you used the features of it.

At one time I was considering for example making an SQLite object class in C++ however figuring out how to make a clean object system with C++ and an SQL backend turned ugly fast. I ended up stopping before I wanted to shoot myself.

I always remember the saying "use the right language for the right purpose". PERL I used for syntax translations between low level assembler code (did a good job in PERL 4).

Surprisingly enough too make a compiler one of the best languages is not C with LEX or YACC (although use of those tools makes a very fast parser), but prolog will make a very compact compiler with a backend to generate assembly from the intermediate code.

Making compilers is an art form too itself, and a sadly undervalued one. Look at the crap MS has been churning out! (They had a long standing bug of ignoring the volatile keyword on the backend, so when people wrote drivers for windows there were strange bugs. This lead them to think THEY needed too write the drivers. NOT turned out they were optimizing register access in the hardware which was necessary for it too work despite the volatile keyword being used.)

Anyhow anyone I wonder if I can port PCSXr too ARM system hmmm....

Cyb
 
Last edited:

Cyberman

Moderator
Moderator
I am of the opinion that I will take what I like and leave the rest.

I concure use what works :D

[QOUTE]http://lkml.iu.edu//hypermail/linux/...7.3/00650.html

Cyberman will love this one :)[/QUOTE]

Their have been a lot of bugs in compilers of late I won't mention certain big companies.
Anyhow Compilers are tricky beasts to write (having had the pleasure).
GCC in particular has 2 parts essentially a basic HL code generator and the back end that does optimization along with code generation.

I think too many neophytes have had access to the backend ;) (keep your hands off my backend .. sounds like a bad joke!)
I've also noticed people standing on soap boxes (hands his to Azimer for some nice clean abstract base class code).
Anyhow if I remember correctly they are still using mostly the same base code for GCC? 4* was a bit of a rewrite but a lot of bugs due to the backend. Hmmm.

cyb
 

Cyberman

Moderator
Moderator
Just an adendume too this
People be careful. The bug Linus was refering too is something you should not have to deal with normally.
This is a caution against using the latest and greatest for things. Sometimes bugs are hardware related sometimes software related and sometimes WTF compiler related (sigh). I've had a compiler delete things due to the volatile bug (hence why I'm a bit more familiar with it than most).

Cyb
 

smcd

Active member
Just an adendume too this
People be careful. The bug Linus was refering too is something you should not have to deal with normally.
This is a caution against using the latest and greatest for things. Sometimes bugs are hardware related sometimes software related and sometimes WTF compiler related (sigh). I've had a compiler delete things due to the volatile bug (hence why I'm a bit more familiar with it than most).

Cyb

I've written some buggy code before that worked in Visual C++ "debug" mode, but puked itself in "release" mode. Fun times :( These days I'm stuck with PHP, which is enough like Perl to get you frustrated when you write things you think should work, and then don't...
 

Top