http://www.osnews.com/story/11166/C_in_2005 Exploring the Future of Computing en-us Copyright 2001-2012, David Adams adam+nospam@osnews.com Thu, 16 Feb 2012 03:38:21 GMT http://www.osnews.com/images/osnews.gif http://www.osnews.com http://www.osnews.com/thread?2288 http://www.osnews.com/thread?2288 Nice article. I love C++.

> "The most commonly requested new feature for C++ is a standard GUI. The technical, economical, and political odds against that happening are immense."

IMO standard GUI is danger because: 1) there are very different GUI API/protocols (X-Window, Win32, etc.); 2) complex to implement and maintain (consequence of the previous one); 3) there are other areas with different needs and wishes (specific widgets, 3D, GUI threading, theming, and so on); 4) there are currently useful portable open source C++ toolkits (i.e. FLTK, Qt, FOX). Mon, 11 Jul 2005 03:36:00 GMT donotreply@osnews.com (Anonymous) Comments http://www.osnews.com/thread?2300 http://www.osnews.com/thread?2300 ... 'cause I prefer it to all other langs, when there is a reasonable choice.

still IMHO it is time to overhaul the whole thing ... including OS (for how many more years are we going to be constrained by unix circa 70s).

now it looks like model T chassis burdened with ... everything! ... from anti-lock brakes to turbo to GPS navigation.

and long gone are the days when simple things can be done simply. ie on 70s system helloworld was done by 3 lines. on XXI century system helloworld (gui) - jesus!

regards Mon, 11 Jul 2005 04:27:00 GMT donotreply@osnews.com (ssme) Comments http://www.osnews.com/thread?2302 http://www.osnews.com/thread?2302 because sometime it can be really hard to read and compile.

and I hope it wont be something like Java or c#. they are trying to be type safe and be more productive and I hate that as a programmer sometime I want to take seg fault and solve it. compiler should not try to fix me.

and of course keywords. that two languages for being OO there are a lot of keywords its boring to read and use them sometime. and can confuse people mind especially project managers they loose their time on documentation for clearify everything. Mon, 11 Jul 2005 04:34:00 GMT donotreply@osnews.com (opakdil) Comments http://www.osnews.com/thread?2303 http://www.osnews.com/thread?2303 still IMHO it is time to overhaul the whole thing ... including OS (for how many more years are we going to be constrained by unix circa 70s).

Forever. There is no money in building better solutions, and there is no academic interest in getting together and building a complete system, instead of random system fragments.

The computer world could be significantly better than it is. Existing systems are broken in sometimes fundemental ways, and the fixes to those problems have been well known for awhile now. But they'll never get built --- the pieces are all there, but there is no will to bear the risk of taking them and putting them together. Mon, 11 Jul 2005 04:37:00 GMT donotreply@osnews.com (rayiner) Comments http://www.osnews.com/thread?2309 http://www.osnews.com/thread?2309 And no, it doesn't need a overhaul and it won't as pointed out by the article.

C++ still does the job that these virtual machine and dynamic languages can't do - and that's high performance without much baggage. Mon, 11 Jul 2005 05:03:00 GMT donotreply@osnews.com (Lumbergh) Comments http://www.osnews.com/thread?2312 http://www.osnews.com/thread?2312 No, I think the issue with a standard widget kit would be this; you would have the majority of the companies support it, then Microsoft would want to embrace and extend it.

The best alternative, however, it GTK and GTKmm - although not perfect, I am sure with some decent money thrown at it, it can be cleaned up, better documented, and a nicer RAD tool can be developed for it. Mon, 11 Jul 2005 05:31:00 GMT donotreply@osnews.com (kaiwai) Comments http://www.osnews.com/thread?2315 http://www.osnews.com/thread?2315 no offence, but you just have repeated (some) arguments of opponents of OOP from 80s.

do you remember "Real Programmers don't use Pascal" ?
http://www.pbm.com/~lindahl/real.programmers.html Mon, 11 Jul 2005 05:59:00 GMT donotreply@osnews.com (ssme) Comments http://www.osnews.com/thread?2317 http://www.osnews.com/thread?2317 c++ is no big leap over c in my opinion.

I know a little of both.

Why do some of you like c++ so much ? Mon, 11 Jul 2005 06:06:00 GMT donotreply@osnews.com (Anonymous) Comments http://www.osnews.com/thread?2319 http://www.osnews.com/thread?2319 since you only know "a little" of c and c++, why should i give 2 shits about your opinion? Mon, 11 Jul 2005 06:16:00 GMT donotreply@osnews.com (Anonymous) Comments http://www.osnews.com/thread?2320 http://www.osnews.com/thread?2320 Why do some of you like c++ so much ?

easy: C++ can be anything: from C to Pascal to Smalltalk (well, almost). whatever you want. to me C++ is synonym of freedom and power of programming. Mon, 11 Jul 2005 06:19:00 GMT donotreply@osnews.com (ssme) Comments http://www.osnews.com/thread?2322 http://www.osnews.com/thread?2322 Like separating the presentation format of the code from the compiler format. IDE's and simple processing scripts could handle it, in terms of implementation. But say an s-expression/xml/whatever storage format with the programmer seeing regular old C++ would be nice. This would likely involve some syntax cleanup, but that'd be welcome anyways.

This would make it easier and faster to parse, not to mention make it infinitely easier to do code refactoring and intellisense features.

With that one could do more interesting things with the pre-processor for setting up various things. Far too often people have to roll out their own RTTI, it'd be easier to develop if one could at least do compile time queries with ease in a platform independent way.

Adding extensions to the language which make it more safe and sane like others, but allow for overriding and shutting these constructs would be nice as well. So one could have the "baggage" as default but replace it when it becomes baggage or turn it off out right. Mon, 11 Jul 2005 06:24:00 GMT donotreply@osnews.com (Saem) Comments http://www.osnews.com/thread?2323 http://www.osnews.com/thread?2323 So one could have the "baggage" as default but replace it when it becomes baggage or turn it off out right

other way around would be more , er, C++ish, don't you think ? Mon, 11 Jul 2005 06:33:00 GMT donotreply@osnews.com (ssme) Comments http://www.osnews.com/thread?2325 http://www.osnews.com/thread?2325 this is my life and it is ending one second at a time.

howdy, folks! i've been programming c++ for two decades
and i can say - it never get any better than this! Mon, 11 Jul 2005 06:34:00 GMT donotreply@osnews.com (Anonymous) Comments http://www.osnews.com/thread?2327 http://www.osnews.com/thread?2327 c++ is no big leap over c in my opinion.

Then you probably never looked at a larger application coded in C. I suggest that you look e.g. at GIMP's source code, which is written in C. Then look at some decent program written in C++. I think it will be quite obvious where the advantages of C++ are. Mon, 11 Jul 2005 06:40:00 GMT donotreply@osnews.com (Anonymous) Comments http://www.osnews.com/thread?2331 http://www.osnews.com/thread?2331 Perhaps for low-level drivers and other code that needs a bit more performance, c++ is a worthy language.

Kind of like you get the old Clint Eastwood out of retirement to shoot some nasty bandits.

For most uses in the modern world, you do not need a nasty old man with an attitude problem.

It would be great if Bjarne used his sense of pragmatic design to make something that is "the c++ of c++". A young Clint Eastwood for today's challenges. Mon, 11 Jul 2005 07:05:00 GMT donotreply@osnews.com (pravda) Comments http://www.osnews.com/thread?2340 http://www.osnews.com/thread?2340 Why should GTK (a C libary) be the basis for a C++ GUI library? GTKmm may be nice, but it willstill build kludges upon a C library. Rather, the lib should be something designed for C++ from the beginning. Qt could be that library but it would need some adaption to fit into the standard.

However, the chances of a GUI lib being standardized for a while are pretty slim. Mon, 11 Jul 2005 08:06:00 GMT donotreply@osnews.com (chakie) Comments http://www.osnews.com/thread?2341 http://www.osnews.com/thread?2341 Qt would require everything that interfaces to it use the Qt system (signals/slots) and custom preprocessor (MOC) for handling events. This is not realistic.

There are many C++ UI frameworks floating around. I'm sure one could be found that does not have Qt's dependencies on proprietary extensions. Mon, 11 Jul 2005 08:16:00 GMT donotreply@osnews.com (pravda) Comments http://www.osnews.com/thread?2342 http://www.osnews.com/thread?2342 to have c++ performance with java/c# like programming style. pointers are cool, but sometimes u could get lost when debugging Mon, 11 Jul 2005 08:31:00 GMT donotreply@osnews.com (Mr. Tan) Comments http://www.osnews.com/thread?2389 http://www.osnews.com/thread?2389 C++ has drifted towards becoming an "expert friendly" language. In a gathering (in person or on the Web) of experts, it is hard to build a consensus (or even interest) for something that "just" helps novices.
The general opinion (in such a gathering) is typically that the best we can do for novices is to help them become experts. But it takes time to become an expert and most people need to be reasonably productive
during the time it takes. More interesting, many C++ novices have no wish or need to become experts in C++. If you are a physicist needing to do a few calculations a week, an expert in some business processes involving software, or a student learning to program, you want to learn only as many language facilities as you need to get your job done. You don't want to become a language expert—you want to be (or become) an expert in your own field and know just enough of some programming language to get your work done. When supported by suitable libraries, C++ can be used like that—it is widely used like that. However, there are traps, pitfalls, and educational approaches that make such "occasional use" of C++ unnecessarily difficult.

This is the fundamental problem with C++. There is such an abundance of features, all of which inter-relate to a certain extent, that you really need to do a lot of hard work within the language to become productive in it. Note, the difficulty is not in learning the initial feature set, it's in learning to avoid the pitfalls that occur when you you start to use all these features in a significant way (e.g. pointers or references? how to use templates, typedefs and structs together? etc.).

This is why so many people use Delphi, Java or C# instead: by simply picking what they hope will be the best features that users need, they minimise the training time, and crucially, minimise the number of potential issues that affect users.

With a modest effort, C++0x can do much better in this area.

This however, is something that I can't agree with. I think C++'s problems are a consequence of fundamental design decisions made early on, and an over-willingness to cater for the C programmers who were afraid to make the OOP leap. It's notable that only now are fully OOP languages like C# and Ruby becoming available. Mon, 11 Jul 2005 10:17:00 GMT donotreply@osnews.com (BryanFeeney) Comments http://www.osnews.com/thread?2408 http://www.osnews.com/thread?2408 For the love of God, could someone tell him to add type inference. At least for local variables. Mon, 11 Jul 2005 11:04:00 GMT donotreply@osnews.com (seguso) Comments http://www.osnews.com/thread?2414 http://www.osnews.com/thread?2414 Replace "a friend can touch your private parts" with "a friend can touch your protected parts". This would make the intent of a many class designs clearer. A little too late for that though, I'm afraid.

Paul G Mon, 11 Jul 2005 11:22:00 GMT donotreply@osnews.com (Anonymous) Comments http://www.osnews.com/thread?2418 http://www.osnews.com/thread?2418 I spoke too soon in my previous post. I just saw the auto keyword, which allows to define a variable without specifying its type (type inference). If implemented, this would finally make C++ a good prototyping language, almost as much as Python. Mon, 11 Jul 2005 11:39:00 GMT donotreply@osnews.com (seguso) Comments http://www.osnews.com/thread?2433 http://www.osnews.com/thread?2433 You're confused. I said nothing against OOP or dynamic languages. In fact I'd rather avoid C++ if possible and am playing around with Ruby on Rails right now

Listen, its just fact that something like Java has massive memory requirements and still doesn't really come close to C++ in performance when you throw out toy benchmarks; not that Java is slow.

Just look at core KDE. There's really no other language that could you give that performance and elegance for the framework.

C++ templates are a very powerful, albeit a bit messy tool.

And the C++ compilers have gotten a lot better over the past decade. Mon, 11 Jul 2005 12:43:00 GMT donotreply@osnews.com (Lumbergh) Comments http://www.osnews.com/thread?2451 http://www.osnews.com/thread?2451 Qt would require everything that interfaces to it use the Qt system (signals/slots) and custom preprocessor (MOC) for handling events. This is not realistic.

Well, if you read what I wrote you'd see that I said it "would need some adaption to fit into the standard". That sentence would cover implementing the signals/slots in some way that fits the C++ standard.

But, it's not going to happen, so this discussion is mostly academic anyway. Mon, 11 Jul 2005 13:32:00 GMT donotreply@osnews.com (chakie) Comments http://www.osnews.com/thread?2462 http://www.osnews.com/thread?2462 I said nothing against OOP or dynamic languages.

sorry, let me explain my remark: in late 80s - beginning 90s when the programming was moving to OOP, its opponents claimed that all that OOP is just un-needed overhead, "baggage", and performance deterioration compared to C languages.

today, as programming moves toward managed environs, i cannot help but notice your using the same arguments.

Java.

IMHO do not through away an idea just because of bad implementation. Mon, 11 Jul 2005 14:08:00 GMT donotreply@osnews.com (ssme) Comments http://www.osnews.com/thread?2480 http://www.osnews.com/thread?2480 so if a genius arises among us and makes impossible - abstacts gui and creates a standard - you would say "no" just because you grew accustomed to some other gui implementation and like it, yes ?

the power of C++ is that it does not force you ... you don't like anything - you don't use it. what's the problem ? Mon, 11 Jul 2005 14:44:00 GMT donotreply@osnews.com (ssme) Comments http://www.osnews.com/thread?2532 http://www.osnews.com/thread?2532 C++ is an excellent evolution of C. It makes a very good portable assembler. It can also be a really sucky Scheme (functional template methods), a really sucky Lisp (template metaprogramming), or a really sucky Smalltalk (MOC preprocessing). Mon, 11 Jul 2005 16:08:00 GMT donotreply@osnews.com (rayiner) Comments http://www.osnews.com/thread?2535 http://www.osnews.com/thread?2535 Yes! This is especially necessary in the land of metaprogramming, where types no longer have human-readable names! Mon, 11 Jul 2005 16:10:00 GMT donotreply@osnews.com (rayiner) Comments http://www.osnews.com/thread?2970 http://www.osnews.com/thread?2970 I believe that C++ is very poor Language, especially because the "native" String type is C char[] and the std::string is just an "addon", why for gods sake can't there be a builtin String datatype that doesn't suck, every other language that claimes to be a "high level" language has a such a thing.

Then the "template" thingy, I have never understood this concept, but it's syntax looks messy enough to avoid it right away. I never actually had the need to use something like this in one of my programs.

However I use C++ as one of my primary Development Tools, why? In a word: FLTK, the fast and light Toolkit, it's just the best GUI Toolkit for my needs and there are no alternatives available for Languages like OCaml or the D (http://digitalmars.com/d/), that I'd prefer over C++ right away. Tue, 12 Jul 2005 14:42:00 GMT donotreply@osnews.com (oracle2025) Comments