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
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
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