A modern application is software developed for a platform such as PC in today's times. Typically such applications tend to grow complex.Originally Posted by whiteflags
That is how it's defined by my book anyway.
A modern application is software developed for a platform such as PC in today's times. Typically such applications tend to grow complex.
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
Just going back to your comment here Bubba. I did a short search yesterday and I found things like:
north.londonmet.ac.uk
http://www.codeproject.com/KB/cpp/oopuml.aspx
And this was quite interesting from Bruce Eckells who gives a more critical angle:
http://www.artima.com/weblogs/viewpo...?thread=115101
Do you have any other recommendations about books or websites that give a good introduction to these ideas?
Microsoft, like anything else, that size, is divided into numerous departments and similar, as you probably know. Therefore it is completely illogical to expect the developers of C#(Anders Hejlsberg and his cohorts) to have anything to do with any code in the microsoft operating systems, except, of course, the .NET framework part of it.
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.
"What's up, Doc?"
"'Up' is a relative concept. It has no intrinsic value."
Ugh. They need to be shot and burned.
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.
Procedural programming is much more readable for examples, where the point is to illustrate the use of a function or method, not to produce the fastest most elegant code. Sometimes I think people confuse procedural methods with C, even though C++ can also be written procedurally and OOP is not incompatible with the procedural style.
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.
Last edited by abachler; 11-29-2008 at 08:26 AM.
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....delaying the project, and possibly lockign out potential improvements.
What's so bad about type-safety and garbage collection?
"What's up, Doc?"
"'Up' is a relative concept. It has no intrinsic value."
Slow.
There should be minimum run-time penalties and maximum compile time safety.
People are supposed to collect their own garbage. It's better to write code that doesn't leave garbage in the first place.
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.
"The Internet treats censorship as damage and routes around it." - John Gilmore
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.
