That is how it's defined by my book anyway.
I think you are forgetting about embedded systems. A great deal of that code is 'modern' even though the hardware it's on is far less than modern.
Perhaps. Not much experience with those things.
But typically any modern hardware, embedded or not, requires complex code.
And then I would say it is good to have a modern language.
It is supposed to make things easier, after all, so it can't hurt.
But your definition of a modern language depends entirely upon the application: how complex it is and when it was shipped (or written). Therefore anything used to write a 'modern' application according to you is a modern language. Including C? Could you maybe be more specific? Or maybe we could drop the subject? ;)
Dropping the subject sounds good to me. I would not deem a language modern or antiquated based on any of the criteria that have been mentioned.
And my advice to the OP was not a ploy to get them to use C++. I don't care what language they use. Using C++ does not make you an object oriented programmer any more than walking into McDonald's makes you a hamburger.
We could drop the subject, if you want ;) It doesn't really matter to me.
And this was quite interesting from Bruce Eckells who gives a more critical angle:
Do you have any other recommendations about books or websites that give a good introduction to these ideas?
You might be right - perhaps their programmers' C++-fu is weak due to way too much exposure to imperative programing, but the minds behind C# and its sibling languages in the .NET framework are, in my opinion, some of the greatest minds to shine their light on the programming world, ever.
C# and Microsoft's .NET crap is worst thing that has happened.
Majority of code is done in native, still today, yet all we hear is managed, managed, managed, managed, managed! It annoys me to no end. I don't want crap-managed.
Yes, in school you are taught to use OOP exclusively while learnign OOP, just like painters are taught to use a particular brush while learnign to use that brush, but to restrict yourself on real projects is to reject applying the most useful method for the task at hand, delaying the project, and possibly lockign out potential improvements. Mixing of 'pure' programming styles produces much better results than trying to paint a picture using only one size of brush and a single color.
While it is true you do not want to do this it is also true that you do not want to create a maintenance nightmare. C++ done procedurally becomes just that and is also hard to componentize later. I do not see it a lot except for in most of Microsoft's sample code so perhaps they are just trying to illustrate a concept and 'get it done' so to speak. Their DXUT is absolutely a mess and there are far better frameworks out there to begin with. After looking at DXUT I will not be recommending it to anyone but my worst enemies.Quote:
...delaying the project, and possibly lockign out potential improvements.
There should be minimum run-time penalties and maximum compile time safety.
Type-safety is often a nuisance since I have to use many typecasts to do a simple operation - a very annoying thing for people who do a little bit of low-level stuff.
Spoken like a true C programmer...
I like type-safety. Less chance to do many errors.
It works very well with high-level design, and using proper types and constructors, even low-level stuff.