The Future of C++ ?
blangela
told you that its future was assured for many years to come. Recently,
I have been starting to wonder.
I have been teaching C++ at a local polytechnical school here in
Vancouver, Canada for approximately 8 years. Six years ago, at the
height (or should I say volume?) of the internet bubble, I had 80+
students per semester in my C++ course. Now I am fortunate to have 15
students per semester. What has changed? I believe that students are
no longer interested in learning C++. They would rather learn .NET
languages or Java (my colleages who teach these courses seem to be very
busy!). I believe it is because these other languages are easier to
learn and/or are perceived to be more relevant today.
I do believe that C++ is more difficult to learn than many of these
other languages. Despite my best efforts to make them exciting, I see
the eyes of my students start to glaze over when I start explaining
pointers. When I ask them to tokenize an english sentence (using the
strtok() function) and print the token in reverse order (they need to
declare an array of type char * and save the addresses of the tokens in
this array), I experience near panic from many of my students. But
these concepts need to be taught in a responsible C++ course. As was
pointed out to me recently, Microsoft still requires applicants to
demonstrate a very good knowledge of string manipulation using C-style
strings (none of these fancy string class objects!) when recruiting C++
programmers.
The ironic part is there is still a large demand for C++ developers
here in Vancouver. In fact, the company that I believe employs the
most developers here in Vancouver, employs almost entirely C++
programmers. This company, Electronic Arts (if you have not heard of
them, I guarantee that your kids have -- they create video games) is
only one of several gaming companies here in Vancouver that employ
primarily C++ programmers. Other companies like Kodak, MDSA, Nokia,
MDSI, etc. also employ large numbers of C++ programmers. Not
surprisingly, I have talked to several companies here in Vancouver who
are complaining that they are having difficulty finding C++ developers
and are looking at trying to recruit from abroad (eastern Europe
primarily).
I believe that many of these companies will be forced to migrate away
from C++ in the near future, simply because they will not be able to
find C++ programmers in the future. Soon the baby boomer C++
programmers will begin to retire, then the proverbial @@@@ will really
start to hit the fan!
Please tell me I am wrong, and paint me a view of the future which
includes C++.
Alf P. Steinbach
> If you had asked me 5 years ago about the future of C++, I would have
> told you that its future was assured for many years to come. Recently,
> I have been starting to wonder.
>
> I have been teaching C++ at a local polytechnical school here in
> Vancouver, Canada for approximately 8 years. Six years ago, at the
> height (or should I say volume?) of the internet bubble, I had 80+
> students per semester in my C++ course. Now I am fortunate to have 15
> students per semester. What has changed? I believe that students are
> no longer interested in learning C++. They would rather learn .NET
> languages or Java (my colleages who teach these courses seem to be very
> busy!). I believe it is because these other languages are easier to
> learn and/or are perceived to be more relevant today.
>
> I do believe that C++ is more difficult to learn than many of these
> other languages. Despite my best efforts to make them exciting, I see
> the eyes of my students start to glaze over when I start explaining
> pointers. When I ask them to tokenize an english sentence (using the
> strtok() function)
There you have it: you're teaching the hard C parts first. Am I right
that these students who're choosing between Java, C# and C++ have no
programming background? I then think learning C# (or even JavaScript!)
first is a good idea wrt. learning programming, and learning Java a good
idea wrt. learning something helpful in getting a job without learning
more first.
> and print the token in reverse order (they need to
> declare an array of type char * and save the addresses of the tokens in
> this array), I experience near panic from many of my students. But
> these concepts need to be taught in a responsible C++ course. As was
> pointed out to me recently, Microsoft still requires applicants to
> demonstrate a very good knowledge of string manipulation using C-style
> strings (none of these fancy string class objects!) when recruiting C++
> programmers.
Again, teach 'em use of standard library classes first. std::string
isn't fancy. Show that C++ can be a productive language at that level.
After learning "high level" C++, teach them in a separate course about
the C subset.
Course e.g. entitled "The C subset of C++: pointers & other hairy
stuff", where for example you can go into why two-phase initialization
isn't a very bright idea in general, but why it's necessary on some
limited platforms such as Symbian C++ (lacking C++ exceptions).
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Phlip
> Please tell me I am wrong, and paint me a view of the future which
> includes C++.
Modern C++ is a very powerful language, and the existing literature and
corpus of example software lags far behind its capacities.
Java and .NET thrive due to "management by magazine". Because the price of
C++ is a high risk of bugs, marketects can advertise Java (and its direct
clone) as "safer and more robust".
Programmers who actually learn C++ are directly competitive with the VM
languages. Those languages typically _reduce_ their available features, to
make code appear easier to make right. This generally causes you to write
more cruft in those languages.
A C++ programmer will deliberately but _voluntarily_ reduce their set of
working techniques, till they are using ones with matching robustness.
(Note, Java-philes, I did _not_ say smart pointers are the equivalent of
Java references. Each has different robustness profiles.)
The distinction is C++ programmers have the _option_ to get closer to the
metal, when they need it.
Contrarily, the majority of programming these days is high-level; trivially
gluing applications together from large-scale components, such as GUIs and
databases. The GUIs and databases themselves should be slowly written once,
in C++. The high-level code should be rapidly written in a safer and more
flexible scripting language.
There may not always be a world for average C++ coders, but there will
always be a world for the C++ code itself.
--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
shabbir
gain.
I am a C++ programmer myself and havent had any training or havent read
any book of C# but I am doing job in C# for 8-9 months now without
facing any real problem and thats because I was good at C++.
When they run for one technology they become lame in a sense that its
temporary and C++ is more or less the base and so its permanent.
As we see now C# has descendant like F# and so you cannot be learning
each of them but if you have the base you can opt for anything anytime
and so still I think C++ is the future.
Thanks
Shabbir
--
www.cfanatic.com - Community discussing C and its derivatives like
Win32, C++, MFC, C# tutorials
Chris Thomasson
> (Note, Java-philes, I did _not_ say smart pointers are the equivalent of
> Java references. Each has different robustness profiles.)
Java references (e.g., strong thread-safe reference counting) in C++? No
problem:
http://appcore.home.comcast.net/vzoom/refcount/
This can be used as an alternative to Boost shared_ptr, which is only basic
thread-safe....
Any thoughts?
loufoque
> Java references (e.g., strong thread-safe reference counting) in C++? No
> problem:
>
> http://appcore.home.comcast.net/vzoom/refcount/
Refcounting is not the same as a GC.
loufoque
> When I ask them to tokenize an english sentence (using the
> strtok() function) and print the token in reverse order (they need to
> declare an array of type char * and save the addresses of the tokens in
> this array), I experience near panic from many of my students.
Maybe students just don't come because they think your course is bad.
They want to learn C++, not C.
> As was
> pointed out to me recently, Microsoft still requires applicants to
> demonstrate a very good knowledge of string manipulation using C-style
> strings (none of these fancy string class objects!) when recruiting C++
> programmers.
Thankfully, Microsoft is not the only company where you can do programming.
Plus Microsoft isn't really doing C++ anyway, more like C with classes.
Chris Thomasson
news:455edb8e$0$5411$426a...@news.free.fr...
You can get very similar guarantees' wrt strong atomic thread-safety
level... And, as you know, one can always get around cyclic references via.
clean/coherent synchronization scheme, or custom and/or "built-into-details"
weak pointer logic...
http://groups.google.com/group/comp.programming.threads/browse_frm/thread/f2c94118046142e8
(more on true atomic refcounting... interesting thread indeed... ?)
I would argue that a coupling of clean synchronization interface in which
cyclic references are rare, with some lightweight weak-pointer scheme would
give you strong guarantees' of Java references, in C++, but at a
lower-level... You have more control over the atomic operations and memory
barrier operations, and you don't need to tie yourself to a VM "system"
API...
Humm...
Roland Pibinger
>I have been teaching C++ at a local polytechnical school here in
>Vancouver, Canada for approximately 8 years. Six years ago, at the
>height (or should I say volume?) of the internet bubble, I had 80+
>students per semester in my C++ course. Now I am fortunate to have 15
>students per semester. What has changed? I believe that students are
>no longer interested in learning C++.
>
>other languages.
IMO, that's the main reason. C++ is unnecessarily and unproductively,
sometimes even ridiculously complex (see e.g.
http://www.bookpool.com/ct/98031). There has been no effort in the
last 10 or so years to make it easier and more accessible. Quite the
contrary, an influential group of people even tries to 'boost' C++ by
continuously introducing yet another level of complexity.
>Despite my best efforts to make them exciting, I see
>the eyes of my students start to glaze over when I start explaining
>pointers.
>But
>these concepts need to be taught in a responsible C++ course. As was
>pointed out to me recently, Microsoft still requires applicants to
>demonstrate a very good knowledge of string manipulation using C-style
>strings (none of these fancy string class objects!) when recruiting C++
>programmers.
C++ is a highly fragmented language. When C++ is discussed one must
always ask: Which C++? Visual C++ (MFC), Embedded C++, Qt C++, C with
classes (the most popular C++), Boost C++, Addison Wesley C++, Game
Programmer C++, ...? This confusing fragmentation is sometimes
reinterpreted as advantage and C++ is touted as 'multiparadigm'
language.
>The ironic part is there is still a large demand for C++ developers
>here in Vancouver. I have talked to several companies here in Vancouver who
>are complaining that they are having difficulty finding C++ developers
>and are looking at trying to recruit from abroad (eastern Europe
>primarily).
There is still demand for C++ developers but currently there is higher
demand for developers in other languages, esp. Java (until the bubble
bursts again).
>I believe that many of these companies will be forced to migrate away
>from C++ in the near future, simply because they will not be able to
>find C++ programmers in the future. Soon the baby boomer C++
>programmers will begin to retire, then the proverbial @@@@ will really
>start to hit the fan!
AFAIK, you can program games today in any language, preferably C#.
The real solution would be C++2, a new version of the C++ language
(not an extension of the current language). I should avoid the
numerous traps, pitfalls and wrong defaults of the current language.
C++2 could be compatible with (but not a superset of) current C and
C++ (through a compatibility mode). Of course, that's a futile
proposal. That kind of language evolution happens in Python, Ruby,
PHP, ... but not in C++.
Best regards,
Roland Pibinger
loufoque
> C++ is a highly fragmented language. When C++ is discussed one must
> always ask: Which C++? Visual C++ (MFC), Embedded C++, Qt C++, C with
> classes (the most popular C++), Boost C++, Addison Wesley C++, Game
> Programmer C++, ...? This confusing fragmentation is sometimes
> reinterpreted as advantage and C++ is touted as 'multiparadigm'
> language.
Looks like you didn't get it at all. They're just frameworks. Libraries.
It's the same C++ but the libraries are designed differently and use
different language features.
Java, for example, also has multiple frameworks, even for one unique
thing (GUI, game development...)
The multiparadigm aspect isn't related to that at all. C++ is said to be
multiparadigm because it has supports for various kinds of programming
paradigms : imperative, object-oriented, generic, and possibly more.
> AFAIK, you can program games today in any language, preferably C#.
Games is one of the key domains that really need an efficient language
like C++...
> The real solution would be C++2, a new version of the C++ language
> (not an extension of the current language). I should avoid the
> numerous traps, pitfalls and wrong defaults of the current language.
> C++2 could be compatible with (but not a superset of) current C and
> C++ (through a compatibility mode).
The main traps and pitfalls in C++ are from its compatibility with C.
Phlip
> Refcounting is not the same as a GC.
In terms of language advocacy, C++ gives you the tools to build whatever
quasi-GC system you want (including a true GC). It doesn't bend you over and
stuff the One True Garbage Collector up your butt.
hardi....@gmail.com
On Nov 18, 7:25 am, "blangela" <Bob_Langel...@telus.net> wrote:
> If you had asked me 5 years ago about the future of C++, I would have
> told you that its future was assured for many years to come. Recently,
> I have been starting to wonder.
> .. snip ..
> Please tell me I am wrong, and paint me a view of the future which
> includes C++.
Imho .NET will finally fall, as the open-source will knock it down, but
.NET is making it's final breaths... You just need to wait
Frederick Gotham
> What has changed? I believe that students are
> no longer interested in learning C++. They would rather learn .NET
> languages or Java (my colleages who teach these courses seem to be very
> busy!). I believe it is because these other languages are easier to
> learn and/or are perceived to be more relevant today.
I think that a prerequisite to being a decent programmer is to have above
average intelligence. A minority of people have above average intelligence,
and so a minorty of people aspire to be an actual bonafide programmer
programming in languages such as C and C++.
For the less bright among us, there's Java.
> Electronic Arts (if you have not heard of
> them, I guarantee that your kids have -- they create video games) is
> only one of several gaming companies here in Vancouver that employ
> primarily C++ programmers.
Computer games should be fast, and C++ can give performance.
> Not
> surprisingly, I have talked to several companies here in Vancouver who
> are complaining that they are having difficulty finding C++ developers
> and are looking at trying to recruit from abroad (eastern Europe
> primarily).
We've the same situation with medical doctors here in Ireland.
--
Frederick Gotham
blangela
I see a fair amount of responses to my initial post, but very few
people willing to go out on a limb and predict the future of C++.
Perhaps we will just have to wait and see.
In response to those people who were critical of my C++ course (the
post was not meant to get opinions on my course) I will mention the
following facts:
- I use as my primary text "C++ - How To Program" 5th edition by
Deitel & Deitel which is by far the most popular college C++ text in
the world! My favorite C++ text is actually "C++ Primer" 4th edition
by Lippman and company, but it is difficult to use as an introductory
C++ text - I do reference several sections from the text in my courses.
- Students are supposed to have taken the Java BlueJ courses (2 - 12
week courses, 3 hours/week including labs) as a prerequisite to my C++
courses. Thus I can expect that they already have experience with OOP.
- Classes are introduced in the first lecture of my course. So also
is the string class. I do not introduce pointers until the 8th
lecture. I suspect the text does so at that point so we can start
working with dynamically created objects (using the new and delete
operators). I could show how to assign a dynamically created object to
a reference rather than to a pointer, but this might lead students to
think this is the norm, which in my experience is not the case (I
wonder why it is not done more often?).
Cheers,
Bob
E. Robert Tisdale
> If you had asked me 5 years ago about the future of C++,
> I would have told you that its future was assured for many years to come.
> Recently, I have been starting to wonder.
> [snip]
> Please tell me I am wrong
> and paint me a view of the future which includes C++.
The design of Java, C# and other such languages
sacrifice performance and efficiency for simplicity and convenience.
C++ is a larger and more difficult language because Bjarne Stroustrup
refused to compromise performance and efficiency --
he was targeting C programmers.
The Java designers realized that most applications didn't require
the performance and efficiency offered by C (and C++) and very carefully
calculated the trade-offs for simplicity and convenience.
The success of Java (and C#) have vindicated these trade-offs.
The future of C++ appears to be secure
where performance and efficiency count.
According to Bjarne Stroustrup, there are no viable competitors yet.
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
blangela
E. Robert Tisdale wrote:
.
.
.
> The future of C++ appears to be secure
> where performance and efficiency count.
> According to Bjarne Stroustrup, there are no viable competitors yet.
>
But can there be C++ without C++ programmers?
Gianni Mariani
...
>
> Please tell me I am wrong, and paint me a view of the future which
> includes C++.
C++ is a very large language with many many uses. It will persist for a
considerable time.
The biggest advantage for Java is that they have many useful
standardized libraries as part of the standard distribution. C++ has a
plethora of non standard libraries that do vastly more than Java but it
takes a significant amount of knowledge to navigate.
Boost has been an attempt to consolidate the C++ world and there are others.
The nice thing about some of the stuff I have seen is that the number of
amazing libraries I see showing up in C++ land are significantly better
than the Java or .NET systems and are probably more "robust" than Java
or .NET.
I have also met a number of Java coders who have migrated over to C++
because they're frustrated with Java.
If I was teaching C++ today, I would avoid C-isms in the "101" course
and only introduce the ones that "helped".
I would have a wrapper over main ...
int main( const std::vector< std::string > & args )
{
std::cout << "Hello world\n";
return 0;
}
Bo Persson
No, but there is a lot off difference between "go away" and not being the
most popular language at the moment.
Both Java and .NET have large companies behind them, using millions and
millions for promotion. Of course they are popular, "the best thing since
sliced bread".
Bjarne can never compete with that. Even though he is right!
Bo Persson
Steve Pope
>IMO, that's the main reason. C++ is unnecessarily and unproductively,
>sometimes even ridiculously complex (see e.g.
>http://www.bookpool.com/ct/98031). There has been no effort in the
>last 10 or so years to make it easier and more accessible. Quite the
>contrary, an influential group of people even tries to 'boost' C++ by
>continuously introducing yet another level of complexity.
I don't think that C++ is too large and complex, yet, but
I do see possibly too much feature-creep via the standards process.
Standards activities tend to become spoiled by their own
success. Not to say that those involved aren't doing a
superb job, but standards work is very difficult (much more
difficult than development).
I have known of software managers to move away from C++
due to a concern it is getting too large and uncontrollable.
A better approach, I think, would be to use C++ but impose
some discipline as to what libraries are used (and perhaps even,
what (non-library) language features are routinely used, but
there I think the concern is smaller).
Steve
Phlip
> I don't think that C++ is too large and complex, yet, but
> I do see possibly too much feature-creep via the standards process.
Oh, totally, a new version once per decade is just blowing us all down.
E. Robert Tisdale
> Both Java and .NET have large companies behind them,
> using millions and millions for promotion.
> Of course they are popular,
> "the best thing since sliced bread".
>
> Bjarne can never compete with that. Even though he is right!
Bjarne certainly could compete.
But he has moved on to bigger and better things.
The first big problem with Java and .NET is that
they are not publicly owned standards like C++.
The language definitions can (and do) change without notiece.
This usually isn't a problem because the typical application
written in Java (or the Microsoft equivalent) has a very short life.
A better question is, "What is the future of Java?"
Computer programming languages tend to become more complex
in order to deal with ever more complex applications.
Eventually, Java may be as complex as C++
and the advantages will disappear.
BobR
Bo Persson wrote in message <4s9c3mF...@mid.individual.net>...
>
>Both Java and .NET have large companies behind them, using millions and
>millions for promotion.
....and suppression. Buy the competition, and shut it down!
[ goodbye Tex Murpjy. ;-{ ]
Fortunately, GNU ain't for sale.
--
Bob R
POVrookie
Tony
"Alf P. Steinbach" <al...@start.no> wrote in message
news:4s7lvvF...@mid.individual.net...
> After learning "high level" C++, teach [students] in a separate course
> about the C subset.
Ha! As if that was even a possibility considering the first thing they
encounter is main()!
Tony
Noah Roberts
blangela wrote:
> If you had asked me 5 years ago about the future of C++, I would have
> told you that its future was assured for many years to come. Recently,
> I have been starting to wonder.
>
> I have been teaching C++ at a local polytechnical school here in
> Vancouver, Canada for approximately 8 years. Six years ago, at the
> height (or should I say volume?) of the internet bubble, I had 80+
> students per semester in my C++ course. Now I am fortunate to have 15
> students per semester. What has changed? I believe that students are
> no longer interested in learning C++. They would rather learn .NET
> languages or Java (my colleages who teach these courses seem to be very
> busy!). I believe it is because these other languages are easier to
> learn and/or are perceived to be more relevant today.
Hey, that's great news. Less cheap labor competition makes me a more
expensive commodity. It also makes my life easier when I don't have to
deal with the bozos comming out of college these days. Let them write
horrible crap in C# or Java. I win either way...I can't loose, no way
is C++ going away any time soon, so this can only be good news.
I say make your course tougher. Weed out the idiots for us.
Paul M. Dubuc
> ...
> The Java designers realized that most applications didn't require
> the performance and efficiency offered by C (and C++) and very carefully
> calculated the trade-offs for simplicity and convenience.
> The success of Java (and C#) have vindicated these trade-offs.
> ...
I think Java may have become harder to learn than C++
http://tinyurl.com/yaxr9p
So much for simplicity.
--
Paul M. Dubuc
Noah Roberts
That "article" doesn't offer anything but hearsay. It's like an
article quoting Bob Villa saying, "Pine sucks."
gn
First of all I have to excuse my very bad english, but I hope
everything comes clear.
In my opinion C++ has a very safe future. Important points like speed
and the possibility of low-level manipulations were already mentioned,
but not the main advantage of C++.
It is the possibility of generic programming using Templates and
Template-Metaprogramming (As an introduction to this topic I read
"Modern C++ Design" by Andrei Alexandrescu -- a book that no C++
Programmer should miss!). People getting used with it will realize that
these programming techniques are just at the very beginning and will
develop over the next years.
A main problem talking about C++ is that still most of todays C++
programmers have started with C and that they still do not understand
that a C++ program using things like makros or printf is a bad C++
programm. There is of course still a need of low-level C-functions but
they should always be capsuled (I don't know the correct term here in
english) in a generic library. Coming from other languages I just
started learning C++ in 2005. But it's my daily work now since one
year and even for trivial little things I am no longer using other
languages. As an introduction I had a course at our university (Marburg
- Germany) together with about 35 other computer scientists. Here in
Germany Java is a mandatory topic in the first semester of each
computer scientist, but all of them who are planning to become a
programmer will take a facultative C++ course. If you ask one of them
why, everybody would answer that java is a nice thing to play around a
little bit, but real programmers use C++.
I think it will take some years until people are really programming C++
(and not C with classes like most people currently do). There is also
much to do in the compiler development (but that is another topic).
Another point is that I absolutely don't think that C++ is a
complicated or hard to learn language. There are of course some things
that seem to be a bit confusing. In that case read Bjarne's book "The
C++ programming language". You will fastly learn to think like Bjarne
thinks and everything will come clear.
Best regards,
gn
Phlip
> First of all I have to excuse my very bad english, but I hope
> everything comes clear.
> In my opinion C++ has a very safe future. Important points like speed
> and the possibility of low-level manipulations were already mentioned,
> but not the main advantage of C++.
> It is the possibility of generic programming using Templates and
> Template-Metaprogramming (As an introduction to this topic I read
> "Modern C++ Design" by Andrei Alexandrescu -- a book that no C++
> Programmer should miss!). People getting used with it will realize that
> these programming techniques are just at the very beginning and will
> develop over the next years.
The part of template-metaprogramming that will never go away is the
incredible optimizations it provides.
However, template-metaprogramming should never be considered a programmer
convenience. A program often must use templates to achieve "duck typing" -
if it waddles like a duck and quacks like a duck, it's a duck.
Other languages provide that in their basic object model, without the need
for a whole new syntax superimposed on top of the existing system. So
template's edge in optimization only represents the compilers for these
languages catching up to C++.
> ...If you ask one of them
> why, everybody would answer that java is a nice thing to play around a
> little bit, but real programmers use C++.
And Java is not the "other languages" I have in mind. Java was invented to
take market share from C++ class libraries - such as MFC. So the language's
marketing pitch is it's safer than C++ - you can't run off the end of an
array, for example.
Actually, it's just harder to run off the end of the array. It's also harder
to get work done, because Java takes much away from C++ while adding almost
nothing back.
gn
Phlip schrieb:
> gn wrote:
...
> The part of template-metaprogramming that will never go away is the
> incredible optimizations it provides.
>
> However, template-metaprogramming should never be considered a programmer
> convenience. A program often must use templates to achieve "duck typing" -
> if it waddles like a duck and quacks like a duck, it's a duck.
>
> Other languages provide that in their basic object model, without the need
> for a whole new syntax superimposed on top of the existing system. So
> template's edge in optimization only represents the compilers for these
> languages catching up to C++.
>
Yes, you are absolutely right if you say that the template concept
could be realized with a much easier synthax. But that kind of
programming can only be done by a language using a real compiler (the
thing with templates is to be generic without loosing speed --
therefore the costs of being generic are shifted to compile time). So I
would agree that a language providing these powers with an easier
synthax might be the language of the future.
But the other languages discussed here were java and .net languages
which can principly not provide this feature.
> And Java is not the "other languages" I have in mind. Java was invented to
> take market share from C++ class libraries - such as MFC. So the language's
> marketing pitch is it's safer than C++ - you can't run off the end of an
> array, for example.
I am just interested -- do you have a special language in mind, that
also maybe a candidate for future standards?
Actually I am not using normal arrays very often. Real C++ is a very
safe language if you have a good design. If I make a mistake I am
realizing it instantly. Things like memory leaks are not possible if
you follow some simple rules. (In had them more often in python than in
C++).
Tony
"Phlip" <phli...@yahoo.com> wrote in message
news:vaY8h.14201$Sw1...@newssvr13.news.prodigy.com...
> Other languages provide that in their basic object model, without the need
> for a whole new syntax superimposed on top of the existing system.
Now there's something interesting. Would you please expound a bit on that
and offer up the languages you had in mind?
> And Java is not the "other languages" I have in mind. Java was invented to
> take market share from C++ class libraries - such as MFC.
And I thought it was invented so that application programs could be
delivered
on demand via a web browser! Silly me.
Tony
Phlip
> Now there's something interesting. Would you please expound a bit on
> that and offer up the languages you had in mind?
See my other post - use one method to pass arguments to functions, not two.
Some arguments are classes.
> And I thought it was invented so that application programs could be
> delivered
> on demand via a web browser! Silly me.
That's the only reason it became popular and got notice. The reason everyone
tries to use it for "enterprise" stuff is the "management by magazine"
effect; defeating the specter of C++'s bugs.
And it doesn't seem dominant in the
Phlip
> Yes, you are absolutely right if you say that the template concept
> could be realized with a much easier synthax.
I mean an easier syntax can eliminate the need for the entire concept of
generics. If everything is an object, including classes, then you can pass a
class name into a function: foo(MyClass). Then you declare the function as
foo(klass), and to get an object you use MyClass.new(). This provides the
entire Prototype Pattern, built-into the language.
That's a little better than having two different systems to pass arguments
into functions: template<typename aClass> int foo(Object & anObject).
That is redundancy and cruft. Why can't we just write int foo(typename
aClass, Object & anObject)?
> But that kind of
> programming can only be done by a language using a real compiler (the
> thing with templates is to be generic without loosing speed --
> therefore the costs of being generic are shifted to compile time). So I
> would agree that a language providing these powers with an easier
> synthax might be the language of the future.
We allow our compilers to have an easy time of optimizing because we
over-specify everything, so all static types resolve at compile time. Yet
this is nothing but coddling our compiler. A more powerful compiler wouldn't
need it, and 'template' may someday just get in the way, the same as
'register' just gets in the way now.
> But the other languages discussed here were java and .net languages
> which can principly not provide this feature.
That's because some people want to compare C++ to other languages and the
first thing they think of is Java and its derivatives. Java may be the
competition with respect to business, but it's not the competition with
respect to technology.
> I am just interested -- do you have a special language in mind, that
> also maybe a candidate for future standards?
Uh, Python, Ruby, and Smalltalk?
(I think Smalltalk is the language of the future, and it always will be!)
> Actually I am not using normal arrays very often. Real C++ is a very
> safe language if you have a good design. If I make a mistake I am
> realizing it instantly. Things like memory leaks are not possible if
> you follow some simple rules. (In had them more often in python than in
> C++).
Right. But every programmers' boss you will ever meet has bad memories of
losing millions of dollars, and programmers blaming crufty C++ code that's
full of memory-corrupting bugs. That's where the Java marketing machine
starts. (And .NET is nothing but a clone.)
Kai-Uwe Bux
> gn wrote:
>
>> Yes, you are absolutely right if you say that the template concept
>> could be realized with a much easier synthax.
>
> I mean an easier syntax can eliminate the need for the entire concept of
> generics. If everything is an object, including classes, then you can pass
> a
> class name into a function: foo(MyClass). Then you declare the function
> as foo(klass), and to get an object you use MyClass.new(). This provides
> the entire Prototype Pattern, built-into the language.
>
> That's a little better than having two different systems to pass arguments
> into functions: template<typename aClass> int foo(Object & anObject).
>
> That is redundancy and cruft. Why can't we just write int foo(typename
> aClass, Object & anObject)?
I take it that you then have template-classes take a type object as a
parameter during construction?
How would you mimmick partial specialization?
Best
Kai-Uwe Bux
Phlip
> How would you mimmick partial specialization?
The point: You just don't need to.
Partial specialization fixes a symptom, not the root cause...
Kai-Uwe Bux
> Kai-Uwe Bux wrote:
>
>> How would you mimmick partial specialization?
>
> The point: You just don't need to.
I don't buy that.
> Partial specialization fixes a symptom, not the root cause...
And in addition, it open new venues for programming.
Don't get me wrong. I have oftentimes missed being able to do
void f ( type A ) {
A a;
...
}
and I would welcome an extension of C++ in this direction (although
overloading the dot operator should have priority). However, such an
extension would be by and large unrelated to the C++ template mechanism and
by no means a substitute. There are areas where both methods could compete,
but not every use of templates is of that type.
Best
Kai-Uwe Bux
gn
> gn wrote:
>
> > Yes, you are absolutely right if you say that the template concept
> > could be realized with a much easier synthax.
>
> I mean an easier syntax can eliminate the need for the entire concept of
> generics. If everything is an object, including classes, then you can pass a
> class name into a function: foo(MyClass). Then you declare the function as
> foo(klass), and to get an object you use MyClass.new(). This provides the
> entire Prototype Pattern, built-into the language.
So far -- yes.
But again --- Each type of language may have a easy syntax providing
the ability to be generic, but the point is to be generic without
loosing speed and that is only possible with a compiler language not
with interpreters or just in time compilers. Of course there are
examples where templates are just used to compensate the insufficiency
of C++. First a popular example for that. For vectors a,b,c,d you may
write: a = b + c + d
The main reason why e.g. Fortran is faster on that than C++ (without
templates) is that Fortran is just summing up the vector components and
assigns them to a. In contrast C++ creates an object for c+d and then
adds the components of this temporary object to b leading to a new
temporary object whose components are assigned to a. Using templates it
is possible to get the same behavior for C++ as in Fortran and in fact
to get the same speed (there are publications on that). So this is as I
said an example where templates are used to cure insufficiencies of
C++, but thats not always the case. Also a simple example for that: In
my daily work I am often using a class for n-dimensional grids (with
variable size for each dimension), where I need several different
iterator-classes e.g. for iterating over a specific grid-shell. Of
course there are mathematical rules to calculate the step the iterator
must take from one grid-point to the next one depending on the number
of dimensions and the size of each dimension. But these values (the
step-size) are calculated at compile time giving an advantage in speed
that could not be realized by an interpreter. You can't build in
specializations for such specific tasks into a language.
> > I am just interested -- do you have a special language in mind, that
> > also maybe a candidate for future standards?
>
> Uh, Python, Ruby, and Smalltalk?
>
> (I think Smalltalk is the language of the future, and it always will be!)
>
Smalltalk is something I definitly have to try out (I never had a look
on a smalltalk program until now.).
But Python is something I am really used with (I have heard that they
solved the huge bugs in the garbage collection for version 2.5 -- is
this right?). But I encountered the frontiers of python very early that
forced me to switch to C++ (today I am very happy that I have
switched). I still think it's a nice language to do little tasks if you
have not much time. In fact it doesn't take a week to learn Python -
that's a feature. Of course for me it is now principly unsufficient,
because I am doing scientific programming and there speed matters. My
programs that I ported from Python to C++ are faster by a factor
between 160 and 220. So for me it's just a 2 days calculation what
needs one year in python.
Best regards,
gn
gn
Kai-Uwe Bux schrieb:
> And in addition, it open new venues for programming.
>
I'd just like to say it again here. I think we are just at the
beginning to understand what is possible with the template concept.
"Modern C++ Design" broadened my horizon concerning this topic :)
Best regards,
gn
Earl Purple
E. Robert Tisdale wrote:
>
> The first big problem with Java and .NET is that
> they are not publicly owned standards like C++.
> The language definitions can (and do) change without notiece.
> This usually isn't a problem because the typical application
> written in Java (or the Microsoft equivalent) has a very short life.
Not necessarily.
And most applications written in C++ more than 5 years ago look very
dated. Especially anything written pre-1998.
> A better question is, "What is the future of Java?"
> Computer programming languages tend to become more complex
> in order to deal with ever more complex applications.
> Eventually, Java may be as complex as C++
> and the advantages will disappear.
No I will tell you a problem I have had that is not a problem in Java.
I have an application that has to link with a 3rd party library, and
this 3rd party produces binaries for C++ in the form of shared object
libraries or DLLs. For Java they produce .jar files.
Now their .jar files work anywhere. The shared objects and DLLs do not,
so they have to build for each platform.
If that's not enough, their build for Solaris requires your own client
code to be compiled with the Sun Solaris compiler. Which is a problem
because it's non-standard - certain amounts of my code failed to
compile due to their disabling of template member functions in STL, a
major problem with std::pair's constructors for one thing. I had to
replace a (probably more efficient) vector.insert() with a std::copy
using back_inserter. (vector.insert is far more likely to optimise).
Then of course I need slightly different makefiles when we finally port
this to Linux where I will be using gnu compiler because that's the
standard there.
Even if everyone builds for GNU only (unlikely to happen) it still
means that you might have a problem keeping up with the versions.
Bo Persson
>
> No I will tell you a problem I have had that is not a problem in
> Java.
>
> I have an application that has to link with a 3rd party library, and
> this 3rd party produces binaries for C++ in the form of shared
> object libraries or DLLs. For Java they produce .jar files.
>
> Now their .jar files work anywhere. The shared objects and DLLs do
> not, so they have to build for each platform.
>
> If that's not enough, their build for Solaris requires your own
> client code to be compiled with the Sun Solaris compiler. Which is
> a problem because it's non-standard - certain amounts of my code
> failed to compile due to their disabling of template member
> functions in STL, a major problem with std::pair's constructors for
> one thing. I had to replace a (probably more efficient)
> vector.insert() with a std::copy using back_inserter.
> (vector.insert is far more likely to optimise).
>
So you are telling us that Sun's Java works better than Sun's C++? :-)
And that that is a language problem?
Bo Persson
Earl Purple
Bo Persson wrote:
>
> So you are telling us that Sun's Java works better than Sun's C++? :-)
>
> And that that is a language problem?
So you're suggesting that Solaris are refusing to change their C++ to
be compliant by default to push more people into Java? Wouldn't put it
past them.
It's the issue that library vendors only need to make one build of a
.jar and it runs anywhere that has a VM.
Anyway, where I work, which is actually a fairly big company that
you've probably heard of, most of the development has switched from C++
to Java over the last few years, particularly servers, and with the
issues I have had I can clearly see why.
Tony
> gn wrote:
>
>> Yes, you are absolutely right if you say that the template concept
>> could be realized with a much easier synthax.
>
> I mean an easier syntax can eliminate the need for the entire concept of
> generics. If everything is an object, including classes, then you can pass
> a class name into a function: foo(MyClass). Then you declare the function
> as foo(klass), and to get an object you use MyClass.new(). This provides
> the entire Prototype Pattern, built-into the language.
Better to keep the syntax as ugly as possible to disuade usage of it as much
as
possible (IMO).
Tony
Tony
"gn" <gneu...@web.de> wrote in message
news:1164281409.3...@k70g2000cwa.googlegroups.com...
>
> Kai-Uwe Bux schrieb:
>
>> And in addition, it open new venues for programming.
>>
>
> I'd just like to say it again here. I think we are just at the
> beginning to understand what is possible with the template concept.
I hope not. Sigh.
Yes, I believe templates are overused and cause a lot of "bad" programming.
Because, very few people know how to use templates judiciously and
sparingly. I guess that's because the STIL isn't very good at teaching good
template usage. Many view it as a mechanism as common as the 'for loop'.
I wouldn't teach anyone templates until they've programmed a few years.
(Just a tad facetious to make the point in that last sentence).
Tony
gn
> No I will tell you a problem I have had that is not a problem in Java.
>
> I have an application that has to link with a 3rd party library, and
> this 3rd party produces binaries for C++ in the form of shared object
> libraries or DLLs. For Java they produce .jar files.
>
> Now their .jar files work anywhere. The shared objects and DLLs do not,
> so they have to build for each platform.
>
> If that's not enough, their build for Solaris requires your own client
> code ...
>
> Even if everyone builds for GNU only (unlikely to happen) it still
> means that you might have a problem keeping up with the versions.
Well - The problem here is that there is one java against many
different C++ compilers. Normally one should think that if you are
programming C++ conform to the standard (and of course capsulating (I
still don't know the right word here in english) system functions) your
programs should compile at every platform where you have a C++
compiler. In reality thats not the case because many compilers are not
conform with the standard, especially concerning templates.
Additionally people who are using things like visual C++ or Borland C++
Builder are often not aware of using non standard libraries. You are
also right with the different GNU versions where I had some problems
with my template syntax.
But all this is not a problem of C++, but of the compiler developers
(let's see what the next standard brings and how fast they are in
implementing it to all compilers). There are also many other things
that I am missing in current compilers (e.g. return value optimization
for recursive functions). I really think that C++ will become much
faster in the future because there are many such things to optimize
that is to complicated for todays compilers.
In the end everything depends on the specific tasks. For my field of
work (computational chemistry) it's simply no question to use anythingh
else than C++ or Fortran, because those quantum chemical calculations
are still to slow even on huge clusters and even for small molecules. I
also think for bigger projects in the software companies it should be
no problem to have C++ and java programmers working on the same
project. It's no problem if you have a good design.
Best regards,
gn
gn
Tony schrieb:
Ok - perhaps I don't have the right to talk about this because I'm
definitly no expert on programming and relativly new to C++. But in my
projects the template part is perhaps 0.5%. I'm only using them for
speed critical parts as libraries for matrix calculations and for those
parts I'm spending much more time than for other parts in planning and
implementing it, to be sure that it really works in an optimal way. So
I really don't think I'm overusing this concept. Of course, if you also
count the usage of the STL then I am overusing it.
Best regards,
gn
Earl Purple
can link against that with any C++ code we like. If they provided a C++
wrapper it would mean we didn't have to write our own but at least we
didn't have the same issues.
One solution would be a standard C++ runtime library (per machine), so
that vendors can write C++ libraries which would simply link against
the standard C++ runtime library installed on the system, the same way
that C code links against the native C runtime library.
On UNIX machines this should include any POSIX extensions (which were
often in the headers like <time.h> and are now in <ctime>).
Standard name-mangling (per platform) would also help.
peter koch
Kai-Uwe Bux skrev:
[snip]
> Don't get me wrong. I have oftentimes missed being able to do
>
> void f ( type A ) {
> A a;
> ...
> }
>
> and I would welcome an extension of C++ in this direction
Am I the only one failing to see whats wrong with
template<typename A>
void f() {
A a;
...
}
What problems does the above function have which your solution solves?
/Peter
gn
There is no problem with the above function!
But for constructs like:
template<template<class foo1> class foo2>
class foo3 : public foo2<inst1>
{...};
and more complicated expressions I'd really like to have a more
readable syntax. In fact I have no good idea how to simplify this in
the best way.
Best regards,
gn
swe...@post.sk
> Yes, I believe templates are overused and cause a lot of "bad" programming.
> Because, very few people know how to use templates judiciously and
> sparingly. I guess that's because the STIL isn't very good at teaching good
> template usage. Many view it as a mechanism as common as the 'for loop'.
> I wouldn't teach anyone templates until they've programmed a few years.
> (Just a tad facetious to make the point in that last sentence).
>
> Tony
I believe that developers are using templates too few.
The book I suggest to C++ beginners is Accelerated C++. I didn't
actually read it because by the time I found out about it I didn't need
it anymore. But I had a quick look through it to evaluate whether it's
good for my less experienced [ex]colleagues. And I think that Bob
Langelaan could use it to improve the course too, following the
suggestion of Alf P. Steinbach to start with standard library classes.
One of the more remarkable facts about the book is that template
functions are introduced in chapter 8 while classes are left for the
chapter 9. I think it's not because they are more important than
classes, but rather because they are easier to learn and they can
simplify your code.
In your OOP orientation you fail to see that you often need helper
functions to simplify the code and improve its readability. Otherwise
you end up with the classic spaghetti code. If these functions do not
use the object's data, making them private member functions seems
wrong to me as this exposes the class's implementation details to the
user of the class and introduces unwanted dependencies. (And the Pimpl
idiom is not suitable for all situations.)
Template functions have the additional advantage of avoiding the
copy-paste bugs and reducing the amount of code in general.
Less code means less opportunities to make bugs, doesn't it?
And template classes are even better in this regard, you don't
need to rewrite std::vector for each type you use it with. And
that's just the beginning.
Bluntly put, if you avoid using templates, you avoid one of the best
features of C++. You can work around that to some degree using
inheritance and virtual function overriding, but this introduces
unwanted dependencies, some (usually unimportant) performance
hit and you also lose some advantages of the static typing in the
process.
Regards,
Vladimir Marko
Bo Persson
> Bo Persson wrote:
>>
>> So you are telling us that Sun's Java works better than Sun's C++?
>> :-)
>>
>> And that that is a language problem?
>
> So you're suggesting that Solaris are refusing to change their C++
> to be compliant by default to push more people into Java? Wouldn't
> put it past them.
I suggest that Sun puts a lot more effort into their Java implementation
than into their C++.
At the same time, they seem to have to resort to using an amazing amount of
C++ code in their HotSpot VM.
Wonder why? How do they manage to port that to new machines?
Bo Persson
APNel...@gmail.com
blangela wrote:
> I have been teaching C++ at a local polytechnical school here in
> Vancouver, Canada for approximately 8 years.
I think it is important to note that because a C++ course is becoming
smaller in Vancouver, Canada does not mean that the C++ language as a
whole is dying. Who knows, it could be that the University has less
students as a whole. Also, this is an introductory course so people
may be taking other languages to start out and then moving up to C++
later.
Greg
> blangela:
>
> > What has changed? I believe that students are
> > no longer interested in learning C++. They would rather learn .NET
> > languages or Java (my colleages who teach these courses seem to be very
> > busy!). I believe it is because these other languages are easier to
> > learn and/or are perceived to be more relevant today.
>
>
> I think that a prerequisite to being a decent programmer is to have above
> average intelligence. A minority of people have above average intelligence,
> and so a minorty of people aspire to be an actual bonafide programmer
> programming in languages such as C and C++.
There is no question that programming in C++ requires above average
intelligence. What is very much open to question, however, is whether
that intelligence is needed for programming per se, or whether the
additional intelligence is needed solely to master the complexities of
C++ itself. In other words, is programming difficult, or is it just
that C++ makes it so? The fact that individuals are able to program
productively in other languages that lack C++'s complexity does lend
support to the latter point of view.
Moreover, isn't it possible that the complexity is self-perpetuating -
that it is in no one's interest for C++ to be any less complicated than
it is? Doesn't the complexity of C++ really work to the economic
benefit of professional C++ programmers? After all, the degree of
intelligence needed to become a C++ programmer presents a significant
barrier to entry into the profession. Therefore one could argue that
the supply of C++ programmers is being constrained to such a degree
that the number of C++ programmers cannot meet the demand. Such a
shortfall in the marketplace, the thinking goes, allows C++ programmers
to command higher salaries than their work is worth economically - and
they can thank C++'s complexity for the entire difference.
It may be instructive to draw some parallels between programming
languages and car transmissions. Programming in C++ is a lot like
driving a car with a manual transmission - both require "above average"
skill than the alternative available technology requires: be it
programming in a managed language or driving a car with an automatic
transmission.
Both automatic transmissions and managed languages are viewed as
alternatives that came along only after the original technology had
been developed. The first generation of cars had only manual
transmissions - meaning that only those skilled enough to shift gears
by hand were able to drive a car. Now the question asked about C++
above can also be asked here: was it the case that driving required
such skills or was it simply that the manual transmission made driving
more difficult than it otherwise had to be?
Similarly, was the development of the automatic transmission a good or
bad development? One could criticize the automatic transmission because
it put a great number of "less skilled" drivers on the road -
individuals who would otherwise not be driving. Certainly, the
higher-skilled drivers would likely see it that way. But for those
driving around in cars with automatic transmissions, the development of
the automatic transmission would have to be seens as an unalloyed good.
The automatic transmission gave these individuals the freedom to drive
themselves and to do so at less cost than hiring a driver.
The tradeoffs involved in both technologies also have similarities.
Like a program written in a managed language versus one written in C++,
a car with an automatic transmissions tends to be less efficient and
not go as fast as one with a manual transmission. But even though an
automatic transmission simplifies driving, the automatic transimission
itself is much more complicated than the manual transmission.
Similarly, the greater simplicity of programming in a managed language
derives from the greater complexity of the underlying "virtual machine"
or "runtime" that enables the simplification. The fundamental
difference here - whether it be programming languages or car
transmissions - is how best to apply advances in technology (or how
best to apply increases in processor speed).
With C++ the philosophy is simple: every increase in a computer's
processing power goes directly toward making the C++ program run
faster. If C++ built cars, every technological advance would go
directly into the car. Managed languages for their part take a more
nuanced approach and invest some portion the increased processing power
not just to run the program faster but to make programming in that
language easier as well. An automatic transmission is an example of
technological advancements applied to the benefit the driver (even to
the detriment of the car), C++ is an example of the opposite:
advancements benefit only the C++ program directly, and the C++
programmer benefits only indirectly (by having a faster, more efficient
- but no less dangerous or any easier to drive - car than they had
before.
Neither approach is necessarily "wrong" and in fact both make sense in
their own way. A C++ programmer does not need a simpler language in
order to program, just as someone who can drive a manual transmission
does not need an automatic transmission in order to drive. So both the
C++ programmer and the skilled driver are likely to prefer to have a
faster program (or a faster car). Whereas everyone else - those who
lack the skills to program in C++ or to drive with a stick shift -
would prefer that technological advances be used to produce a
programming language they could program in - or car they could actually
drive.
Greg
kwikius
Greg wrote:
> Moreover, isn't it possible that the complexity is self-perpetuating -
> that it is in no one's interest for C++ to be any less complicated than
> it is?
I'm sure you don't mean nobodies interest. It is certainly in the
interest of newcomers trying to get to grips with the language. Its
stated somewhere in the C++ committee manifesto that we encourage
libraies designed to make programming easier or something For example
Concepts should in theory provide useful error messages and help
debugging. Of course OTOH when you read the Concepts proposals:
http://www.generic-programming.org/languages/conceptcpp/
you can also argue that in fact this is just yet another layer of
complexity, and so the only way to make the language simpler is to
write another language, extracting the 'useful' parts of C++.. hence
Java and C#.
At the language level, there is only one way for C++ to go and that is
to become even more complicated as you can't remove features of course.
Eventually it will become so complicated that no one will be able to
write a compiler for it.
A big problem is the libraries. There are often questions on
comp.lang.c++ regarding Graphics and a GUI on the one hand and also
vehement responses on the other that C++ doesnt need a standard GUI or
graphics libraries There seems to be powerful interests at work. It is
surely in some peoples interests that C++ does become ever more
complicated with out any actual usability features (e.g libraries for
common tasks) and more and more newcomers will simply stick with Java
and C# and so on, where they can get the libraies off the nearest
shelf.
Every programming language has a prime life time and every programming
language is eventaully superceded. C++ is no exception to the rule. C++
did it to C after all.
There is no money behind C++ except from companies and maybe many of
their interests lie elsewhere. Its the lack of good libraies that will
kill C++ AFAICS.
And BTW. I am putting my time where my mouth is and currently working
on a C++ GUI library to fill the gap. I'm not making any code public as
babykilling is too simple of a pastime.
regards
Andy Little
Frederick Gotham
> Such a shortfall in the marketplace, the thinking goes, allows C++
> programmers to command higher salaries than their work is worth
> economically - and they can thank C++'s complexity for the entire
> difference.
But that's how all professions work! If just anyone could design space
shuttles, then NASA would pay peanuts.
> It may be instructive to draw some parallels between programming
> languages and car transmissions. Programming in C++ is a lot like
> driving a car with a manual transmission - both require "above average"
> skill than the alternative available technology requires: be it
> programming in a managed language or driving a car with an automatic
> transmission.
I live in Ireland and 99% of cars here are manual transmission. There's a
learning curve to it, sure, but even the most stupid person can learn to
drive manual transmission (and yes I've seen some utterly dumb people drive
a manual transmission car just fine).
> Both automatic transmissions and managed languages are viewed as
> alternatives that came along only after the original technology had
> been developed. The first generation of cars had only manual
> transmissions - meaning that only those skilled enough to shift gears
> by hand were able to drive a car. Now the question asked about C++
> above can also be asked here: was it the case that driving required
> such skills or was it simply that the manual transmission made driving
> more difficult than it otherwise had to be?
One more thing: You have to consider how comfortable people are with manual
transmission. I've often thought that the most difficult things I've ever
had to learn are walking and talking. There must have been a _massive_
learning curve. Now though, they're second nature to me.
I've been driving manual transmission for about three years now, and it's
second nature to me now. Of course, there was a learning curve at first,
but I got the hang of it.
In my part of the world, people are perfectly happy with manual
transmission. In fact, most people don't like automatic transmission over
here -- if you've driven manual for a while, then you feel as though you've
been deprived of power and control which you once had. Of course though,
there's the ease and simplicity of driving automatic, but, for me, it
doesn't make up for the loss of control.
I myself hate automatic -- give me manual any day of the week.
> Similarly, was the development of the automatic transmission a good or
> bad development? One could criticize the automatic transmission because
> it put a great number of "less skilled" drivers on the road -
> individuals who would otherwise not be driving. Certainly, the
> higher-skilled drivers would likely see it that way. But for those
> driving around in cars with automatic transmissions, the development of
> the automatic transmission would have to be seens as an unalloyed good.
> The automatic transmission gave these individuals the freedom to drive
> themselves and to do so at less cost than hiring a driver.
Ah yes, but if all they know is automatic transmission, then they haven't
experienced the brilliance of driving manual transmission.
For instance, let's say I'm driving fast, but there's a bend up ahead. I
want to get through that bend as quickly as possible. Driving an automatic,
I'll break as I approach the bend, then turn, then accelerate once I'm
through the turn. Driving a manual, I'll drop a gear as I approach the
bend, then the car will slow as I re-engage the engine dragging the revs
up, then I'll turn, then when I'm through the turn, I'll slip the clutch
and acclerate. The automatic method is certainly simpler, but the manual
method is far more efficient.
> The tradeoffs involved in both technologies also have similarities.
> Like a program written in a managed language versus one written in C++,
> a car with an automatic transmissions tends to be less efficient and
> not go as fast as one with a manual transmission.
Hear Hear! :)
If I couldn't drive, and if I was given the choice of an automatic or a
manual, then I'd stop a think: "Hmm, I could get driving the automatic
straight-away, but then I wouldn't experience the brilliance of manual".
Being an elitist, I go for the superior method from Day 1.
Maybe we can categorise people as follows:
(1) They go for manual transmission from Day 1.
(2) They start off with automatic transmission, then move on to manual
transmission.
(3) They start off with automatic transmission and stay with it their whole
life.
I'm firmly placed in Category 1. Give me C++.
--
Frederick Gotham
Bo Persson
> Greg:
>
>> The tradeoffs involved in both technologies also have similarities.
>> Like a program written in a managed language versus one written in
>> C++, a car with an automatic transmissions tends to be less
>> efficient and not go as fast as one with a manual transmission.
>
>
> Hear Hear! :)
>
If we leave the cars behind, and instead compare programmers to other
skilled craftsmen, tools like a nailgun or a chainsaw are very productive in
the hands of someone who can handle them. The fact that a newbie doesn't
immediately see how to use them properly, isn't a reason to remove them
from the toolbox of a professional.
Even if the hardware store sells more hammers, that only means that it is
more popular, not that it is the best tool for everyone.
Bo Persson
blangela
I notice that I have not seen a single post in this thread from an
instructor stating that their C++ classes are increasing in size, or
even maintaining their size. I know that I get students from UBC (one
of the 2 large local uniiversites, the other being SFU) who want to
learn C++. They complain that it is no longer available at UBC. Also,
when I first started teaching C++, there were several other local
colleges doing the same. Now I believe only BCIT (where I teach) is
still doing so.
Bob
Frederick Gotham
> I notice that I have not seen a single post in this thread from an
> instructor stating that their C++ classes are increasing in size, or
> even maintaining their size.
Programming instructors don't tend to be of the highest proficiency.
--
Frederick Gotham
blangela
They are usually able to read and write! That's all it takes to post
on this forum.
Tony
"Greg" <gre...@pacbell.net> wrote in message
news:1164536442....@n67g2000cwd.googlegroups.com...
> Frederick Gotham wrote:
> In other words, is programming difficult, or is it just
> that C++ makes it so? The fact that individuals are able to program
> productively in other languages that lack C++'s complexity does lend
> support to the latter point of view.
The second statement above is not necessarilly true: C++ can mean
"programming close to the bare metal" which can be more difficult.
The nice thing about C++ is that it let's one program at that level if
they want to. One can just as easily program at a higher level by
using libraries that abstract the underlying complexity. Consider
for example that one can purchase a bullet-proof library of internet
protocols and interact with servers out on the internet without
knowing or having to implement such stuff. Granted, knowing how
it works is usually important, but one doesn't have to be the
architect of such software in order to use it. As a developer (no, I'm
not exclusively that!), I don't like languages that do it all for me and
don't allow me to do it on my own or my way if I want to. My analogy
is the English language. I'll use it as I wish (C++) and not be constrained
by "political correctness" (java?). I'll make my point how _I_ want to.
And if I want to use STL or not is my choice. If I want garbage
collection, I can have it, or not! :)
Your post has a lot of questions/concerns that people who haven't used
C++ I think. I don't think C++ is too complex. I won't think so unless
it starts imposing policies on what I can or cannot do with the language.
Sure all the template stuff is getting "real evolved" (complex), but if
you don't use or need that, it doesn't make requirements of you as the
developer.
Overall, if one "does C++ by the book", yeah, I'd agree, there's a lot
to know. Over time, one discovers what one needs and when and
breaks away from the newbie programmer "everything all the time"
programming "model".
Tony
(For me, switching to a programming language away from C++ or asking
me to consider such, would be like asking me to trade English for another
language (read: I don't have that much time left on the planet and I have
better things to do!))
Tony
"Greg" <gre...@pacbell.net> wrote in message
news:1164536442....@n67g2000cwd.googlegroups.com...
> Frederick Gotham wrote:
> Doesn't the complexity of C++ really work to the economic
> benefit of professional C++ programmers?
And don't forget the tool builders!
Tony
Tony
"Greg" <gre...@pacbell.net> wrote in message
news:1164536442....@n67g2000cwd.googlegroups.com...
> Frederick Gotham wrote:
> It may be instructive to draw some parallels between programming
> languages and car transmissions.
And maybe not! ;)
Tony
Tony
"Greg" <gre...@pacbell.net> wrote in message
news:1164536442....@n67g2000cwd.googlegroups.com...
> Frederick Gotham wrote:
> One could criticize the automatic transmission because
> it put a great number of "less skilled" drivers on the road -
> individuals who would otherwise not be driving.
Anyone so criticizing is not very smart: the less one has to do during
driving
the better. Your example is akin to saying that those who can drive and
talk and dial on their cellphones are "safer" since they can/are doing more
things at once (unecessary things), which of course is opposite of the
truth. "less skilled", perhaps, but "less skilled in unecessary tedium and
therefore more attentive to the driving task" is more correct.
I think you just took your analogy too far and tried to draw too many
parallels.
Tony
(P.S. Not to even mention that the "4 on the floor" crowd are the hotrodders
on
the street! So if safety is the goal, I'd opt for more of the auto-trans
people on
the roads.)
Tony
"Greg" <gre...@pacbell.net> wrote in message
news:1164536442....@n67g2000cwd.googlegroups.com...
> Frederick Gotham wrote:
> Like a program written in a managed language versus one written in C++,
"managed language"?? You've been watching too much TV! LOL,
"managed language". Even the chosen MS terminology is repulsive.
Using a word that to programmers means "repressed", is pretty stupid
marketing, don't ya think?
Tony
Tony
"Greg" <gre...@pacbell.net> wrote in message
news:1164536442....@n67g2000cwd.googlegroups.com...
> Frederick Gotham wrote:
> Neither approach is necessarily "wrong" and in fact both make sense in
> their own way. A C++ programmer does not need a simpler language in
> order to program, just as someone who can drive a manual transmission
> does not need an automatic transmission in order to drive. So both the
> C++ programmer and the skilled driver are likely to prefer to have a
> faster program (or a faster car). Whereas everyone else - those who
> lack the skills to program in C++ or to drive with a stick shift -
> would prefer that technological advances be used to produce a
> programming language they could program in - or car they could actually
> drive.
_I_ think you have used analogy (or euphemism?) in the wrong way. The
only time using such is good is if someone isn't understanding what you
said and you give "a kinda like". But to go deeper into the parallels, which
almost never relate, is perilous.
So, I'd say, if you want talk cars, talk cars. If you wanna talk programming
languages talk those. There is no need to talk around every element via
remote abstraction (and it's even "incorrect" to do so in that is doesn't
help anything).
Tony
(The other time when analogy is wrong is in counter to a preceding analogy
which of course is just USENET analogy war material and has nothing to
do with the original point at all (read: it's a pissing contest!)).
Phlip
>> Like a program written in a managed language versus one written in C++,
>
> "managed language"?? You've been watching too much TV! LOL,
> "managed language". Even the chosen MS terminology is repulsive.
> Using a word that to programmers means "repressed", is pretty stupid
> marketing, don't ya think?
Absolutely. Programmers should be free to write whatever they feel like, and
mantain their own servers, without people around them telling them what to
write and keeping their servers up for them.
--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
Tony
"kwikius" <an...@servocomm.freeserve.co.uk> wrote in message
news:1164540036.3...@l39g2000cwd.googlegroups.com...
>
> Greg wrote:
>
>> Moreover, isn't it possible that the complexity is self-perpetuating -
>> that it is in no one's interest for C++ to be any less complicated than
>> it is?
>
> I'm sure you don't mean nobodies interest. It is certainly in the
> interest of newcomers trying to get to grips with the language.
If I was an instructor at a university, I would NOT put templates into a
first semester class. That's an advanced and additional paradigm and
requires choice to "buy into" IMO. I view C++ as a smorgasbord: I'll
eat what I want and like (no sushi for me!).
Actually, even before C++, it would probably be better to take a
general studies course on programming paradigms! Then students can
take C++ as an course tailored to their needs. (No, that won't work,
cuz students by definition can't make that choice). Oh well, something
like that then.
Tony
(Templates are KINDA like sushi, for me)
Tony
"kwikius" <an...@servocomm.freeserve.co.uk> wrote in message
news:1164540036.3...@l39g2000cwd.googlegroups.com...
> you can also argue that in fact this is just yet another layer of
> complexity, and so the only way to make the language simpler is to
> write another language, extracting the 'useful' parts of C++.. hence
> Java and C#.
No. No need to extract. Just use what you need, ignore the rest. The other
facilities are there if/when you need/want them. No need to throw the
baby out with the bath water (or whatever the appropriate cliche is...
hey, isn't English HARD?!).
Tony
Tony
"kwikius" <an...@servocomm.freeserve.co.uk> wrote in message
news:1164540036.3...@l39g2000cwd.googlegroups.com...
> At the language level, there is only one way for C++ to go and that is
> to become even more complicated as you can't remove features of course.
But C++ doesn't force you to use those things. The only time you'd be
concerned with the complexity of the entire body of C++ is if you wanted to
produce a conforming implementation (compiler).
Tony
Tony
"kwikius" <an...@servocomm.freeserve.co.uk> wrote in message
news:1164540036.3...@l39g2000cwd.googlegroups.com...
> A big problem is the libraries. There are often questions on
> comp.lang.c++ regarding Graphics and a GUI on the one hand and also
> vehement responses on the other that C++ doesnt need a standard GUI or
> graphics libraries There seems to be powerful interests at work. It is
> surely in some peoples interests that C++ does become ever more
> complicated with out any actual usability features (e.g libraries for
> common tasks) and more and more newcomers will simply stick with Java
> and C# and so on, where they can get the libraies off the nearest
> shelf.
Someone else please chime in on the availability of C++ libraries. There is
a lot of them available. I think what you are saying is that you don't want
to shop/evaluate/choose from a number of them (?).
Tony
Tony
"kwikius" <an...@servocomm.freeserve.co.uk> wrote in message
news:1164540036.3...@l39g2000cwd.googlegroups.com...
> Every programming language has a prime life time and every programming
> language is eventaully superceded. C++ is no exception to the rule. C++
> did it to C after all.
That's conjecture. In a previous post, I said that I'm as like to switch
from
C++ as I am from English!
Tony
(Or maybe not EVEN conjecture: facetiousness/pessimistic optimism/or...
the dreaded "manager making decisions on shallow/one-point data! Try
trend analysis instead, it may serve you better.)
Tony
"kwikius" <an...@servocomm.freeserve.co.uk> wrote in message
news:1164540036.3...@l39g2000cwd.googlegroups.com...
> There is no money behind C++ except from companies and maybe many of
> their interests lie elsewhere.
Whatever that means.
> Its the lack of good libraies that will kill C++ AFAICS.
Example please. What area is missing "good libraries" and what would,
for you, make it a "good" library? (Perhaps FREE?)
> And BTW. I am putting my time where my mouth is and currently working
> on a C++ GUI library to fill the gap. I'm not making any code public as
> babykilling is too simple of a pastime.
>
> regards
> Andy Little
I know that name. The Minix newsgroup?
Tony
Tony
"Frederick Gotham" <fgot...@SPAM.com> wrote in message
news:Eehah.16391$j7.3...@news.indigo.ie...
> Greg:
>
>> Such a shortfall in the marketplace, the thinking goes, allows C++
>> programmers to command higher salaries than their work is worth
>> economically - and they can thank C++'s complexity for the entire
>> difference.
>
>
> But that's how all professions work! If just anyone could design space
> shuttles, then NASA would pay peanuts.
A loooong time ago, I worked in a place where there were union workers.
That's where I learned the concept "job security". Not that _I_ ascribe to
such strategy (I feel there is an infinite amount of stuff to do after
tackling
what I'm currently working on) but some actually LIKE the "mundane,
repetitive, non-cognitive" work. But to milk it like that is probably
"wrong".
And the only reason I bring up that concept, is because.. well we've all
seen products that are produced just to make money right? Where is
C++ at this juncture along those lines? I dunno, but if "it" ever turns a
corner and starts imposing policy or paradigm, I'll stop using it and
call it proprietary.
Tony
Tony
<swe...@post.sk> wrote in message
news:1164417813....@f16g2000cwb.googlegroups.com...
> Tony wrote:
>> Yes, I believe templates are overused and cause a lot of "bad"
>> programming.
>> Because, very few people know how to use templates judiciously and
>> sparingly. I guess that's because the STIL isn't very good at teaching
>> good
>> template usage. Many view it as a mechanism as common as the 'for loop'.
>> I wouldn't teach anyone templates until they've programmed a few years.
>> (Just a tad facetious to make the point in that last sentence).
>>
>> Tony
>
> I believe that developers are using templates too few.
Well you're obviously wrong. ;)
> The book I suggest to C++ beginners is Accelerated C++.
That's a fine book. I have it in my bookshelf also. It's title though
says "advanced", and I think there it should stay. It's not first course
material or entry-level programmer stuff. I highly recommend that
book though: it really teaches the underlying themes/mechanisms.
> I didn't
> actually read it
Well it more of a research book than a book to read.
> One of the more remarkable facts about the book is that template
> functions are introduced in chapter 8 while classes are left for the
> chapter 9. I think it's not because they are more important than
> classes, but rather because they are easier to learn and they can
> simplify your code.
I didn't really like the examples either. The whole student/grades thing
is so boring.
> In your OOP orientation you fail to see that you often need helper
> functions to simplify the code and improve its readability.
No, that's an assumption you are making (and assumptions are most
often wrong you know).
> Bluntly put, if you avoid using templates, you avoid one of the best
> features of C++.
Templates are optional. "Use them if you are lazy". ;) (No, I won't
expound on that, so don't ask).
Tony
Tony
"Frederick Gotham" <fgot...@SPAM.com> wrote in message
news:Eehah.16391$j7.3...@news.indigo.ie...
> Maybe we can categorise people as follows:
>
> (1) They go for manual transmission from Day 1.
> (2) They start off with automatic transmission, then move on to manual
> transmission.
> (3) They start off with automatic transmission and stay with it their
> whole
> life.
Stop this stuff already, puh-leese!
Tony
(An analogy taken too far is like two in the bush. Let me explain... well,
it's
like rock-n-roll guitar "music": it's not really music, it's masturbation!).
Tony
"blangela" <Bob_La...@telus.net> wrote in message
news:1164563711.4...@j72g2000cwa.googlegroups.com...
Well note too that the bookstores are dumbing down the book selection to
commercial product manuals rather than computer science stuff. Today's
generation of "programmers" are closer to assembly line workers than
their predecessors.
Tony
Tony
"Frederick Gotham" <fgot...@SPAM.com> wrote in message
Those who can DO, those who can't TEACH?
Tony
kwikius
Tony wrote:
> "kwikius" <an...@servocomm.freeserve.co.uk> wrote in message
> news:1164540036.3...@l39g2000cwd.googlegroups.com...
>
> > There is no money behind C++ except from companies and maybe many of
> > their interests lie elsewhere.
>
> Whatever that means.
>
> > Its the lack of good libraies that will kill C++ AFAICS.
>
> Example please. What area is missing "good libraries" and what would,
> for you, make it a "good" library? (Perhaps FREE?)
"Standard". GUI, graphics, dlls, IPC, concurrency.
regards
Andy Little
Phlip
> Stop this stuff already, puh-leese!
Tony, you are being successfully trolled. Let it have the last word.
kwikius
I don't and more to the point beginners to the language don't or rather
won't. They will and do already use another language where those
libraries are available. Supermarkets are more successful than
specialists. Why, because people havent got the time to go around all
the specialist shops individually. Most things people want in a
supermarket are similar and 'good enough', and there is nothing
stopping them going to a speciailist if they wish. Further in the
supermarket everything is compatible "generic" (e.g barcodes), feedback
on one product can be used for others. cross fertilisation occurs
formally and informally The supermarket is also a meeting place for
people who want different products, so you can usually get advice from
someone in there as to whether some product is good or not.
Go ask in the specialist shop and their particular product is bound to
be marvellous of course.
regards
Andy Little
blangela
I agree with you on this point. I know of a Java instructor at my
school who feels it is a waste of time to teach students data
structures or sorting algorthms -- Java provides different container
classes and sorting algorthms to select from, so why should the student
need to learn these topics. I disagree. I feel that there is still
room for the "science" in "computer science".
blangela
Tell that to Einstein. I read somewhere that he taught for many years.
Chris Thomasson
>
> Tony wrote:
>> "blangela" <Bob_La...@telus.net> wrote in message
>> news:1164563711.4...@j72g2000cwa.googlegroups.com...
>> >
>> > APNel...@gmail.com wrote:
>> >> blangela wrote:
>> >> > I have been teaching C++ at a local polytechnical school here in
>> >> > Vancouver, Canada for approximately 8 years.
[...]
>> Well note too that the bookstores are dumbing down the book selection to
>> commercial product manuals rather than computer science stuff. Today's
>> generation of "programmers" are closer to assembly line workers than
>> their predecessors.
>>
>> Tony
>
> I agree with you on this point. I know of a Java instructor at my
> school who feels it is a waste of time to teach students data
> structures or sorting algorthms -- Java provides different container
> classes and sorting algorthms to select from, so why should the student
> need to learn these topics. I disagree. I feel that there is still
> room for the "science" in "computer science".
I completely disagree with the Java instructor as well. Data-structures and
sorting algorithms' are fundamental! Its sad that the current trend in
computer science seems to be aimed at very high-level languages which
abstract fundamental methods and techniques away to a dangerous point. It
can lead to a scenario in which a Java programmer might not now how to
create or even sort a linked list. The Java programmer might not even now
how to create a dynamic array from scratch... I feel your pain!
Ian Collins
>
>>Tony wrote:
>
>>>Well note too that the bookstores are dumbing down the book selection to
>>>commercial product manuals rather than computer science stuff. Today's
>>>generation of "programmers" are closer to assembly line workers than
>>>their predecessors.
>>>
>>>Tony
>>
>>I agree with you on this point. I know of a Java instructor at my
>>school who feels it is a waste of time to teach students data
>>structures or sorting algorthms -- Java provides different container
>>classes and sorting algorthms to select from, so why should the student
>>need to learn these topics. I disagree. I feel that there is still
>>room for the "science" in "computer science".
>
>
> I completely disagree with the Java instructor as well. Data-structures and
> sorting algorithms' are fundamental! Its sad that the current trend in
> computer science seems to be aimed at very high-level languages which
> abstract fundamental methods and techniques away to a dangerous point. It
> can lead to a scenario in which a Java programmer might not now how to
> create or even sort a linked list. The Java programmer might not even now
> how to create a dynamic array from scratch... I feel your pain!
>
As an field grows, one either has to specialise in a niche, or become a
generalist.
If they haven't done so already, CS degrees will follow that path.
--
Ian Collins.
Earl Purple
gn wrote:
> Earl Purple schrieb:
>
> Well - The problem here is that there is one java against many different C++ compilers.
Java 5 has some significant changes in it.
> Normally one should think that if you are
> programming C++ conform to the standard (and of course capsulating (I
> still don't know the right word here in english) system functions) your
> programs should compile at every platform where you have a C++
> compiler. In reality thats not the case because many compilers are not
> conform with the standard, especially concerning templates.
Well we are dealing with 3 situations:
- Open-source libraries. They need to build in your compiler but once
you've built it you can link it with your code easily. I much prefer
using open-source libraries. The only issue is when they're written in
macros because of all the different compilers they might be dealing
with, and particularly if they require you to set some define just to
have it compile standard C++. The situation should be that those who do
not have standard-complliant compilers should be the ones who have to
define something.
- Pre-built libraries. Now you have to get the binaries from the
vendor, and usually there are a certain number of header files but they
are basic enough to work for any compiler. The clash now comes with
linking against run-time libraries.
- Hybrids which could have the worst of both worlds, i.e. you need
compiler-specific defines and have to build with the correct runtime
library. Visibroker is the actual one I had problems with.
> Additionally people who are using things like visual C++ or Borland C++
> Builder are often not aware of using non standard libraries. You are
> also right with the different GNU versions where I had some problems
> with my template syntax.
It is incredible how many are still using VC6. Problem is of course, a
lot of their code would break on VC7/8 because it's full of "wrong" C++
that VC6 would compile.
The same is true for any modern C++ compiler, although GNU usually
allows specific switches for backward compatibility.
> But all this is not a problem of C++, but of the compiler developers
> (let's see what the next standard brings and how fast they are in
> implementing it to all compilers). There are also many other things
> that I am missing in current compilers (e.g. return value optimization
> for recursive functions). I really think that C++ will become much
> faster in the future because there are many such things to optimize
> that is to complicated for todays compilers.
Runtime performance is not the main issue. Java has improved in that it
has improved its runtime performance to be adequate enough. Whether it
matches C++ is not always relevant, as long as it is adequate for the
task in hand. (In some cases Java can match C++ perfectly well or even
out-perform it).
The big issue here seems to be portability. C++ badly lacks a standard
runtime library in the way C has one, and a standard demangler so that
you can link GNU libraries with VC8 or Solaris ones on their specific
platforms without requiring a "C" interface.
In addition, I still feel that the reluctance of C++ to have a standard
for a network, threads, file-system, graphics device etc is something
serious lacking as part of its portability, even if there are 3rd party
libraries for many of these things, even open-source ones.
> In the end everything depends on the specific tasks. For my field of
> work (computational chemistry) it's simply no question to use anythingh
> else than C++ or Fortran, because those quantum chemical calculations
> are still to slow even on huge clusters and even for small molecules. I
> also think for bigger projects in the software companies it should be
> no problem to have C++ and java programmers working on the same
> project. It's no problem if you have a good design.
For this there is always JNI which allows Java to interact with C. The
"D" programming language can also interact with C libraries. Once again
C++ is left out of the equation.
Earl Purple
Tony wrote:
>
> If I was an instructor at a university, I would NOT put templates into a
> first semester class. That's an advanced and additional paradigm and
> requires choice to "buy into" IMO. I view C++ as a smorgasbord: I'll
> eat what I want and like (no sushi for me!).
I would. Collections would be one of the first subjects I would teach.
One of the least important features of C++ is cin. I do not have a
single cin in any of my C++ production code. Yet it seems to be the
first thing programmers seem to learn.
> Actually, even before C++, it would probably be better to take a
> general studies course on programming paradigms! Then students can
> take C++ as an course tailored to their needs. (No, that won't work,
> cuz students by definition can't make that choice). Oh well, something
> like that then.
Surely paradigms though must include handling collections.
Earl Purple
Greg wrote:
>
> It may be instructive to draw some parallels between programming
> driving a car with a manual transmission - both require "above average"
> skill than the alternative available technology requires: be it
> programming in a managed language or driving a car with an automatic
> transmission.
>
>
> Greg
A better analogy would be between building a car in Java or building
one in C++.
In Java, you would get all the components and put them together,
including the wheels.
In C++ though there is no standard for a wheel because there are some
vehicles, i.e .boats, don't have wheels so there is no need for a
standard. So you have to "reinvent the wheel" or fit one from a 3rd
party manufacturer, the only problem with that being that getting their
wheels to fit your vehicle is not always an simple matter, at least not
as straightforward as it is to fitting a standard one, because the
diagnostics of the wheels are such that they have side effects on the
rest of the manufacture of your car.
Earl Purple
> actually read it because by the time I found out about it I didn't need
> it anymore. But I had a quick look through it to evaluate whether it's
> good for my less experienced [ex]colleagues.
Unfortunately what looks great teaching material by those who know the
language well does not always prove to be the case. You have to try it
out on students and see how well they pick it all up.
> And I think that Bob
> Langelaan could use it to improve the course too, following the
> suggestion of Alf P. Steinbach to start with standard library classes.
>
> One of the more remarkable facts about the book is that template
> functions are introduced in chapter 8 while classes are left for the
> chapter 9. I think it's not because they are more important than
> classes, but rather because they are easier to learn and they can
> simplify your code.
What do they teach in chapters 1-7? Writing console apps with a lot of
cin statements?
> Bluntly put, if you avoid using templates, you avoid one of the best
> features of C++. You can work around that to some degree using
> inheritance and virtual function overriding, but this introduces
> unwanted dependencies, some (usually unimportant) performance
> hit and you also lose some advantages of the static typing in the
> process.
That is true but templates can also be used in the wrong place.
Template classes are often written where only a small proportion has
"dependent" code (i.e. code dependent on the template type). Such a
template should often be refactored to have a non-template handle the
non-dependent code.
Earl Purple
blangela wrote:
>
> I notice that I have not seen a single post in this thread from an
> instructor stating that their C++ classes are increasing in size
Ah, they are getting cleverer at not writing monolithic classes
anymore. Better refactoring
> I know that I get students from UBC (one
> of the 2 large local uniiversites, the other being SFU) who want to
> learn C++. They complain that it is no longer available at UBC. Also,
> when I first started teaching C++, there were several other local
> colleges doing the same. Now I believe only BCIT (where I teach) is
> still doing so.
Course in Java: Here is a computer. We will learn to write applications
that use all the modern features: GUI, hey we can run even in a
browser. Networking - no problem. And we can process concurrently...
Java is very useful because a lot of companies are writing brand new
software in it.
Course in C++: Here is a computer. Now let's get a DOS shell up and
write a console app. And even when you ask the user to type in a
number, there is no method to intercept the key as the user hits it, so
if the user types in "Blah" you have to go back and say "sorry that's
not a number". If we're lucky we might even write our source with the
vi editor where you have to carefully switch between modes because
there's no such thing as Ctrl or Alt so characters mean different
things at different times. C++ is very useful because there's lots of
legacy code out there written in it, usually very badly, and you can
get a job maintaining it.
Now if you are student which do you choose?
On the subject of maintaining a legacy app, yes it makes economic sense
to do so rather than go for the rewrite. You could say the same for the
language itself. Better to maintain it and even add some new features
rather than go back and write a new one from scratch which is simply
much better.
Now everyone in the C++ market seems to be claiming that the language
is used for device drivers or the "embedded" world. Now where is the
university course saying "here is a robot, now we are going to program
some C++ into its microchip". Might just be the way to make it a bit
more exciting. People would like to learn how to program robots. They
look modern. Instead of writing "hello world" and some horrible console
app with cin, we could program it to make us a cup of tea.
Earl Purple
Frederick Gotham wrote:
> blangela:
>
> > I notice that I have not seen a single post in this thread from an
> > even maintaining their size.
>
>
> Programming instructors don't tend to be of the highest proficiency.
They should be excellent teachers. The best programmers are usually out
there programming in it, not teaching it. But the best programmers
aren't necessarily good teachers either.
Alf P. Steinbach
Except -- for robots specialized control languages are better than
C++. And in the embedded world one uses restricted dialects of C++ that
aren't really C++. For example, when you remove exceptions from the
language you also remove the whole point of constructors, and what's
left isn't much more than a simple syntactical device (writing p->foo()
rather than p->vt->foo( p ) or CALL( p, foo, () )).
If I were to teach C++ today (I did many years ago) I'd focus on Windows
applications.
E.g., I imagine it's slightly difficult to do a Windows system tray icon
in Java, unless someone has made a C++ library for that for Java.
I think Windows applications comprise the last bastion of C++.
And it's crumbling: most new Windows applications will be .NET based,
and then better written in C#. That leaves C++ as a "glue" language,
e.g. writing those Java platform libraries. Oh well.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Mirek Fidler
> problem:
>
> http://appcore.home.comcast.net/vzoom/refcount/
>
>
> This can be used as an alternative to Boost shared_ptr, which is only basic
> thread-safe....
You got me interested. I briefly visited the site, but missed any
description on how to do that.
Can you point me in the right direction? (I guess we both understand
that using atomic operations to increment/decrement reference count is
far from lock free ;)
Mirek
Chris Thomasson
news:1164633250.0...@j44g2000cwa.googlegroups.com...
>
> blangela wrote:
>>
>> I notice that I have not seen a single post in this thread from an
>> instructor stating that their C++ classes are increasing in size
>> or even maintaining their size.
>
> Ah, they are getting cleverer at not writing monolithic classes
> anymore. Better refactoring
>
>> I know that I get students from UBC (one
>> of the 2 large local uniiversites, the other being SFU) who want to
>> learn C++. They complain that it is no longer available at UBC. Also,
>> when I first started teaching C++, there were several other local
>> colleges doing the same. Now I believe only BCIT (where I teach) is
>> still doing so.
>
> And we can process concurrently...
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Java memory model is so damn strict that it makes it impossible to create
any high-end synchronization algorithms. Period. But then, does the average
Java programmer even know this fact? I bet 99% do not. Simple example of how
learning Java first can, and will, burn you:
Java teacher: Now we are going to learn about arrays. Java has this class
you see...
Student: How does Java actually implement that class?
Java teacher: I don't know. But, it works so lets start learning!
Student: What a fuc#king rip off!
>
> Course in C++:
[...]
> C++ is very useful because
I can use it with Assembly Language to create a high-end synchronization
algorithms. I can use to create a full blown Java VM... I can use C++ to
prototype virtually anything for that matter. Can't use Java for any of
that.
> there's lots of
> legacy code out there written in it, usually very badly, and you can
> get a job maintaining it.
I hope you don't think that the reason C++ is still around is because of
legacy code?
> Now if you are student which do you choose?
C++ for sure! You should learn the fundamentals before you choose to
sacrifice yourself to very high-level language that is governed under a
"private" standard.
Chris Thomasson
> you see...
>
>
> Student: How does Java actually implement that class?
>
>
> Java teacher: I don't know. But, it works so lets start learning!
>
>
> Student: What a fuc#king rip off!
Smart-Ass-C++-Student:
I know how they implemented the array class... They used C/C++ dip shit!!
lol...
;^)
Mirek Fidler
Phlip wrote:
> loufoque wrote:
>
> > Refcounting is not the same as a GC.
>
> In terms of language advocacy, C++ gives you the tools to build whatever
> quasi-GC system you want (including a true GC). It doesn't bend you over and
Uh, no not really. Best you can hope for AFAIK is some sort of
conservative GC.
Mirek
Kai-Uwe Bux
> "Earl Purple" <earlp...@gmail.com> wrote in message
[snip]
>> Course in Java: [...]
>
>> And we can process concurrently...
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Java memory model is so damn strict that it makes it impossible to create
> any high-end synchronization algorithms. Period. But then, does the
> average Java programmer even know this fact? I bet 99% do not. Simple
> example of how learning Java first can, and will, burn you:
>
>
> Java teacher: Now we are going to learn about arrays. Java has this class
> you see...
>
>
> Student: How does Java actually implement that class?
>
>
> Java teacher: I don't know. But, it works so lets start learning!
>
>
> Student: What a fuc#king rip off!
C++ teacher: Now we are going to learn about variable length arrays. C++ has
for instance the deque<> template, you see ...
Student: How does C++ actually implement that template?
C++ teacher: That is implementation defined according to the standard. All I
can tell you for sure are the following guaranteed complexity bounds...
Weak Student: What the heck, who cares about -- what did you call way too
complex bounds?
Strong Student: Cool, but (a) that does not answer my question and (b) why
are there no bounds on space?
>>
>> Course in C++:
> [...]
>
>> C++ is very useful because
>
> I can use it with Assembly Language to create a high-end synchronization
> algorithms. I can use to create a full blown Java VM... I can use C++ to
> prototype virtually anything for that matter. Can't use Java for any of
> that.
I would like to see the C++ course completion of which will enable you to
create a full blown Java VM. Do you seriously suggest that, say, as a term
paper?
>
>
>> there's lots of
>> legacy code out there written in it, usually very badly, and you can
>> get a job maintaining it.
>
> I hope you don't think that the reason C++ is still around is because of
> legacy code?
>
>
>
>
>> Now if you are student which do you choose?
>
> C++ for sure! You should learn the fundamentals before you choose to
> sacrifice yourself to very high-level language that is governed under a
> "private" standard.
And you should learn to make screws from blocks of metal before you learn to
assemble chairs your order online.
Best
Kai-Uwe Bux
Earl Purple
Chris Thomasson wrote:
>
> > there's lots of
> > legacy code out there written in it, usually very badly, and you can
> > get a job maintaining it.
>
> I hope you don't think that the reason C++ is still around is because of
> legacy code?
>
Of course it is. C++ beat all the other OO languages of its generation
because it supported all the company's existing C source. Read
Stroustrup's pages about the history of the language.
> > Now if you are student which do you choose?
>
> C++ for sure! You should learn the fundamentals before you choose to
> sacrifice yourself to very high-level language that is governed under a
> "private" standard.
And then you'd need to learn assembly too plus deep amounts of
electronics to know how all the hardware works.
What if, however, you are the typical student for whom university is
really only the unfortunately necessary and costly step between school
and getting a job, and that your primary aim of university is to be
trained to get a job afterwards, especially since you'll probably have
a big loan to pay off.
And it's the "private standard" that has allowed them to advance Java
to where it is, introducing generics (really templates) in the latest
standard, plus the equivalent of a foreach which looks a lot cleaner
than the 3 C++ options of having to either
1. write a loop
2. write a functor
3. try to create a functor on the spot with some horrible looking
syntax, involving binds, addresses of member functions and possibly
some funny looking _1 symbol.
Phlip
> Phlip wrote:
>> loufoque wrote:
You are responding to someone who said "C++ gives you the tools to build any
kind of GC system imaginable".
Mirek Fidler
Phlip wrote:
> Mirek Fidler wrote:
>
> > Phlip wrote:
>
> >> loufoque wrote:
>
> >> > Refcounting is not the same as a GC.
>
> >> In terms of language advocacy, C++ gives you the tools to build whatever
> >> quasi-GC system you want (including a true GC). It doesn't bend you over
> >> and
>
> > Uh, no not really. Best you can hope for AFAIK is some sort of
> > conservative GC.
>
> You are responding to someone who said "C++ gives you the tools to build any
> kind of GC system imaginable".
Ah, you mean building GC in C++ for Java? Or what?
Actually, I got impression that you suggest that you can build true GC
a library solution for C++. I argue that you cannot (at least not
without special C++ compiler, but that would be equal to adding GC to
language definition).
Mirek
Chris Thomasson
news:1164634716....@j44g2000cwa.googlegroups.com...
>> Java references (e.g., strong thread-safe reference counting) in C++? No
>> problem:
>>
>> http://appcore.home.comcast.net/vzoom/refcount/
>>
>>
>> This can be used as an alternative to Boost shared_ptr, which is only
>> basic
>> thread-safe....
>
> You got me interested. I briefly visited the site, but missed any
> description on how to do that.
Well, you can't use it as a 100% drop in replacement right now because the
interface is a little different. However, it does provides two smart
pointers:
ptr::global - used for strong atomic references
ptr::local - used for basic atomic references
Here is some brief info on their semantics:
http://article.gmane.org/gmane.comp.lib.boost.devel/149813
http://article.gmane.org/gmane.comp.lib.boost.devel/149818
You can start to experiment and tinker around when them now. However, the
library is in pre-alpha status... I would not use it for production code
yet. Experiments fine, production, wait for version 1 to come out... Oh
crap, I just noticed that I am going to be a little late for a meeting!
Damn, I need a couple of pots of coffee!
> Can you point me in the right direction?
I have no time to say what I want to say right now, so here are some quick
links to relevant information:
http://search.gmane.org/?query=&author=chris+thomasson&group=gmane.comp.lib.boost.devel&sort=relevance&DEFAULTOP=and&xFILTERS=Gcomp.lib.boost.devel-Achris+thmasson---A
(deeper descriptions of how my refcount algorithm works)
http://groups.google.com/group/comp.programming.threads/browse_frm/thread/f2c94118046142e8
(lock-free patents...)
http://atomic-ptr-plus.sourceforge.net/
(Joe Seighs excellent work)
http://groups.google.com/group/comp.programming.threads/browse_frm/thread/4e8717d3bcdedfe9
(initial idea; pseudo-code)
http://groups.google.com/group/comp.programming.threads/msg/2f21a151d3916592
(mostly lock-free...)
http://groups.google.com/group/comp.programming.threads/msg/0022ef08ae26e2f3
(async-signal-safe aspects of my algorithm)
http://groups.google.com/group/comp.programming.threads/msg/667b1867c19e6288
(async-signal...)
http://groups.google.com/group/comp.programming.threads/msg/9ee468f341a33ee2
(adding more async-signal-safety characteristics'...)
http://groups.google.com/group/comp.programming.threads/msg/64a46f3ef24b786a
http://groups.google.com/group/comp.programming.threads/msg/e363f874241bcaf4
(possible improvements...)
Other that that... When I get back from the meeting, we should include c.p.t
in this conversation.
Well, got to go!
Noah Roberts
Frederick Gotham wrote:
> blangela:
>
> > What has changed? I believe that students are
> > no longer interested in learning C++. They would rather learn .NET
> > languages or Java (my colleages who teach these courses seem to be very
> > busy!). I believe it is because these other languages are easier to
> > learn and/or are perceived to be more relevant today.
>
>
> I think that a prerequisite to being a decent programmer is to have above
> average intelligence. A minority of people have above average intelligence,
> and so a minorty of people aspire to be an actual bonafide programmer
> programming in languages such as C and C++.
No. Programming requires a certain thinking type, that is all. There
are plenty of brilliant people out there that can't program and will
never be able to program beyond the very basics.
>
> For the less bright among us, there's Java.
Actually, for the less bright among us there's language bigotry.
Java programmers are not stupid. If you want to call people stupid you
should have a look at people that purposfully use the least productive
and secure components of a language when not necissary. Those that do
not make use of the tools at their disposal to make themselves more
productive and better programmers.
Earl Purple
Alf P. Steinbach wrote:
>
> Except -- for robots specialized control languages are better than
> C++. And in the embedded world one uses restricted dialects of C++ that
> aren't really C++. For example, when you remove exceptions from the
> language you also remove the whole point of constructors, and what's
> left isn't much more than a simple syntactical device (writing p->foo()
> rather than p->vt->foo( p ) or CALL( p, foo, () )).
The ideal solution in my opinion is a "one-exception-type" exception.
That would probably reduce a lot of the overhead of exceptions. You can
then examine the exception if you want to do different things based on
what the error was.
> If I were to teach C++ today (I did many years ago) I'd focus on Windows
> applications.
>
> E.g., I imagine it's slightly difficult to do a Windows system tray icon
> in Java, unless someone has made a C++ library for that for Java.
>
> I think Windows applications comprise the last bastion of C++.
>
> And it's crumbling: most new Windows applications will be .NET based,
> and then better written in C#. That leaves C++ as a "glue" language,
> e.g. writing those Java platform libraries. Oh well.
So you are admitting that C++ is effectively dying as an application
programming language but will probably remain for the low-level systems
program for a non-embedded platform.