Future of C++

[kwikius]

My hunch is my posts to clc++ are disappearing down a hole, so I post here
instead.

Future of C++ thread on clc++

"Abhishek" <no************ *******@yahoo.c omwrote in message
news:g7******** **@aioe.org...

Hi All,
This is a non-technical off topic post, so please excuse me for that.

I wanted to understand from the Gurus of C++ out here about their opinion
on
the future of C++. I have spent eight plus years in the software industry
working in applications programming on C++/ Windows. My current company is
now moving big time towards Java/ J2EE based technologies. Most of the
other
companies which are writing application software are also moving (or have
alreadt moved) to J2EE or to .Net. So is there no future for C++ in
application software? What do the people on this group feel about it?

I understand that Systems side and Embedded are still the areas where C++
is
being used well. But is that all? What do the people who have invested
time
and energy in C++ should do? Learn Java or C# because a significant
majority
of other developers (apparently) could not free the pointers and found
garbage collector to be a great idea.

Thoughts/ Suggestions/ Criticism?

AFAICS C++ is very much about a "craft" approach to software development.
For one It takes a long time to get good at it. Like any craftsman, say a
carpenter it costs. Once upon a time if you wanted a new door, you asked the
carpenter and he made you one to your spec. These days doors are all
standard sizes and you buy them off the shelf at a hardware superstore. A
similar situation applies with C++ and other languages in respect to
libraries. The modern trend is towards abstracting away the hardware. This
results in a loss of performance but much greater productivity, and
critically libraries which become unofficial standards within the language.
The classic example in C++ is GUI. Often newbies ask about the C++ GUI and
they are vaguely pointed off towards various libraries. In modern languages
there are usually one or two "standard" GUI libraries that everyone uses.

Because C++ is so expressive, if you start a new library ( or even
application ) then you are presented with a huge number of decisions. Do I
use templates or RTTI, Do I use Dll or static libs, Do I worry about cross
platform or target one. This all takes a long time and results in
fragmentation. In other less complicated languages, you don't have to worry
about these things. They have been solved or abstracted away. Hence
languages like Java, and Python have huge libraries because presumably they
are easier to write once in practise. The low level problems that confront
you in C and C++ are abstracted away.

That said C++ and C will be around a long time. For windows they will be
around as long as its around I guess, but I don't see there being as much
demand for C++ programmers.

regards
Andy Little

[Pavel]

kwikius wrote:

My hunch is my posts to clc++ are disappearing down a hole, so I post here
instead.

Future of C++ thread on clc++

"Abhishek" <no************ *******@yahoo.c omwrote in message
news:g7******** **@aioe.org...

>Hi All,
This is a non-technical off topic post, so please excuse me for that.

I wanted to understand from the Gurus of C++ out here about their opinion
on
the future of C++. I have spent eight plus years in the software industry
working in applications programming on C++/ Windows. My current company is
now moving big time towards Java/ J2EE based technologies. Most of the
other
companies which are writing application software are also moving (or have
alreadt moved) to J2EE or to .Net. So is there no future for C++ in
application software? What do the people on this group feel about it?

I understand that Systems side and Embedded are still the areas where C++
is
being used well. But is that all? What do the people who have invested
time
and energy in C++ should do? Learn Java or C# because a significant
majority
of other developers (apparently) could not free the pointers and found
garbage collector to be a great idea.

Thoughts/ Suggestions/ Criticism?

AFAICS C++ is very much about a "craft" approach to software development.
For one It takes a long time to get good at it. Like any craftsman, say a
carpenter it costs. Once upon a time if you wanted a new door, you asked the
carpenter and he made you one to your spec. These days doors are all
standard sizes and you buy them off the shelf at a hardware superstore. A
similar situation applies with C++ and other languages in respect to
libraries. The modern trend is towards abstracting away the hardware. This
results in a loss of performance but much greater productivity, and
critically libraries which become unofficial standards within the language.
The classic example in C++ is GUI. Often newbies ask about the C++ GUI and
they are vaguely pointed off towards various libraries. In modern languages
there are usually one or two "standard" GUI libraries that everyone uses.

Because C++ is so expressive, if you start a new library ( or even
application ) then you are presented with a huge number of decisions. Do I
use templates or RTTI, Do I use Dll or static libs, Do I worry about cross
platform or target one. This all takes a long time and results in
fragmentation. In other less complicated languages, you don't have to worry
about these things. They have been solved or abstracted away. Hence
languages like Java, and Python have huge libraries because presumably they
are easier to write once in practise. The low level problems that confront
you in C and C++ are abstracted away.

That said C++ and C will be around a long time. For windows they will be
around as long as its around I guess, but I don't see there being as much
demand for C++ programmers.

regards
Andy Little

A couple of bare facts/observations with minimal comments:

1. A younger co-worker of mine left for Microsoft last week. What's
interesting, they took him to take part in writing their next generation
Visual Studio or whatever they will call it -- and it is going to be the
first version of it written wholly in C# (instead of C/C++, in which all
recent previous versions have been written). Maybe second next Windows
version will not be in C/C++ either? :-)

2. I received the last issues of last professional C++ magazine I knew
(C/C++ User Journal) more than a year ago (I think). I then checked on
C++ Reports that I used to read much earlier just to learn it had been
dead for quite a while already. Was not very happy about it; this
newsgroup seems to be one of very few C++ dedicated resources.

I would not mind to read a civilized discussion about where C++ is
heading and why -- and I have some ideas of my own about it -- but not
sure if such discussion is an off-topic here or whether there is enough
interest. Also the topic may be quite flame-prone. Any opinions?

-Pavel

[ebony.soft]

On Aug 6, 3:27*am, "kwikius" <a...@servocomm .freeserve.co.u kwrote:

My hunch is my posts to clc++ are disappearing down a hole, so I post here
instead.

Future of C++ thread on clc++

"Abhishek" <nospam_abhishe kpan...@yahoo.c omwrote in message

news:g7******** **@aioe.org...

Hi All,
This is a non-technical off topic post, so please excuse me for that.

I wanted to understand from the Gurus of C++ out here about their opinion
on
the future of C++. I have spent eight plus years in the software industry
working in applications programming on C++/ Windows. My current companyis
now moving big time towards Java/ J2EE based technologies. Most of the
other
companies which are writing application software are also moving (or have
alreadt moved) to J2EE or to .Net. So is there no future for C++ in
application software? What do the people on this group feel about it?

I understand that Systems side and Embedded are still the areas where C++
is
being used well. But is that all? What do the people who have invested
time
and energy in C++ should do? Learn Java or C# because a significant
majority
of other developers (apparently) could not free the pointers and found
garbage collector to be a great idea.

Thoughts/ Suggestions/ Criticism?

AFAICS C++ is very much about a "craft" approach to software development.
For one It takes a long time to get good at it. Like any craftsman, say a
carpenter it costs. Once upon a time if you wanted a new door, you asked the
carpenter and he made you one to your spec. These days doors are all
standard sizes and you buy them off the shelf at a hardware superstore. A
similar situation applies with C++ and other languages in respect to
libraries. The modern trend is towards abstracting away the hardware. This
results in a loss of performance but much greater productivity, and
critically libraries which become unofficial standards within the language.
The classic example in C++ is GUI. Often newbies ask about the C++ GUI and
they are vaguely pointed off towards various libraries. In modern languages
there are usually one or two "standard" GUI libraries that everyone uses.

Because C++ is so expressive, if you start a new library ( or even
application ) then you are presented with a huge number of decisions. Do I
use templates or RTTI, Do I use Dll or static libs, Do I worry about cross
platform or target one. This all takes a long time and results in
fragmentation. In other less complicated languages, you don't have to worry
about these things. They have been solved or abstracted away. Hence
languages like Java, and Python have huge libraries because presumably they
are easier to write once in practise. The low level problems that confront
you in C and C++ are abstracted away.

That said C++ and C will be around a long time. For windows they will be
around as long as its around I guess, but *I don't see there being as much
demand for C++ programmers.

regards
Andy Little- Hide quoted text -

- Show quoted text -

Dear Kwikius/Andy
Hello

I am not going to defend C++ blindly. I try to offer my opinions to
light up some confusions,
Of course may be I am me mistaken.
1. One thing that we should think about is: C++ is a general purpose
programming language not a complete system.
J2EE and Visual Studio .NET are systems. So in C++ "Programmin g
Language", you can't have ODBC, DAO, GUI components, ...
but using C++ (core language + standard library) and in a complete C++
programming environment,
you can implement libraries for database programming, GUI and so on/
forth. C++ is not/will not a language to bind to
relational database, GUI technology, OS ... It is and will be open and
general-purpose PL.
I think the comparison of C++ PL vs. Java system is somehow unfair.
Of course, my company uses Java rather than C++, because we use a
Trade system that was implemented
using Java technology and my company bought the software. It is not
relevant to C/C++. Programming language selection is not just a
technical issue.
2. As you know, the next revision of C++ is coming soon. It is called C
++0x. It will bring us various features in two area: programming
language
and standard library: in language area we have concepts, initializer
lists, lambda, enum classes, nullptr, programmer-controled GC, ...
and in library area we will see threads, tuples, huge statistics and
math functions, regular expressions, hash_map containers, ...
but again there are no vendor-related components and libraries.
3. Stroustrup say: The only thing that has consistently grown faster
than hardware is human expectations. I think this is absolutely
correct.
Your comment is about efficiency (performance) vs. productivity. In
all software engineering books and university classes,
it is mentioned that with such a drastic changes in hardware speeds
and abilities, the importance of efficiency was decreased.
I think the right sentence is by Kernighan and Plauger in their book:
Elements of Programming Style:
Don't sacrifice readability for small efficiency. Please note to small
adjective. Up until now, there is no feature of C++
which added to language and put unusual overhead on rest of features.
It is very difficult task. Compare the performance of
object-oriented features of C++ vs. Smalltalk. It is applicable for C+
+ vs. Java, C++ vs. Python, C++ vs. Ruby,

4. You used the door and carpenter example. It is about reusability
and as you wrote abstracting away unnecessary details.
C++ tries to do it efficiently: using string rather than char*, vector
rather than arrays, bitset rather than bit manipulations and huge
generic algorithms are some witnesses.
5. IMHO, such expressiveness is not bad thing; indeed it is good and
necessary. C++ continue
To increase in emphasis on statically verifiable type safety. If you
want type safety, you should be expressive. I believe being less
expressive lead us to script programming. As a matter of fact, C++
offer 2-3 ways for a subject to program. It is natural result of
multi-paradigm nature of the PL.

Regards,
Saeed Amrollahi

[Matthias Buelow]

eb********@gmai l.com wrote:

To increase in emphasis on statically verifiable type safety. If you
want type safety, you should be expressive. I believe being less
expressive lead us to script programming.

I don't quite understand that statement. What do you mean? Static typing
and expressiveness in a language are two distinct concepts. C++ is in
some ways more expressive than C but not as expressive as Lisp (which is
a dynamically typed language). What's got one to do with the other?

[kwikius]

On Aug 6, 5:09*pm, Matthias Buelow <m...@incubus.d ewrote:

ebony.s...@gmai l.com wrote:

To increase in emphasis on statically verifiable type safety. If you
want type safety, you should be expressive. I believe being less
expressive lead us to script programming.

I don't quite understand that statement. What do you mean? Static typing
and expressiveness in a language are two distinct concepts. C++ is in
some ways more expressive than C but not as expressive as Lisp (which is
a dynamically typed language). What's got one to do with the other?

Wel heres my take on it.

If you have strong typing you can be more expressive in comfort
because errors in expressions will be caught by the compiler, whereas
dynamic typing postpones errors till runtime and it may take much
testing to try to locate all possible errors.

IOW the dynamic language is "expressive " of many things though some
are potentially incorrect, but the static typed language is
expressive, whilst being (arguably) proved correct prior to
execution.

regards
Andy Little

[Pavel]

kwikius wrote:

On Aug 6, 5:09 pm, Matthias Buelow <m...@incubus.d ewrote:

>ebony.s...@gma il.com wrote:

>>To increase in emphasis on statically verifiable type safety. If you
want type safety, you should be expressive. I believe being less
expressive lead us to script programming.

I don't quite understand that statement. What do you mean? Static typing
and expressiveness in a language are two distinct concepts. C++ is in
some ways more expressive than C but not as expressive as Lisp (which is
a dynamically typed language). What's got one to do with the other?

Wel heres my take on it.

If you have strong typing you can be more expressive in comfort
because errors in expressions will be caught by the compiler, whereas
dynamic typing postpones errors till runtime and it may take much
testing to try to locate all possible errors.

IOW the dynamic language is "expressive " of many things though some
are potentially incorrect, but the static typed language is
expressive, whilst being (arguably) proved correct prior to
execution.

regards
Andy Little

I am not sure one language is much more expressive than the other --
IMHO it is much more dependent on the style of use than the language
itself. I have seen quite understandable code in different Assemblers
and much more of inscrutable code in all possible languages even
including Python (although it is not too easy to write something
completely misleading in Python -- maybe only on purpose). But the "cost
of complete understanding" of a C++ program was always among the highest
for me -- often, I had to pre-process a source file to understand with
certainty what's coming from where. Consider this fragment:

int i = 0;
f(i);
myprint(i);

If it is written in Java (or C, for that matter), I can tell with some
certainty that myprint() receives 0 as an argument. But to tell
something about it in C++ I have to know whether f() takes a reference
or a value and, to make things even more fun, I never know which of
possible overloaded f's is called, -- not until I pre-process the code
and line up all possible fs. IDE with a browser may help somewhat but as
it jumps to the definition or declaration of f() it dislocates my focus
-- quite an overkill especially if the only purpose of my review is to
track down where that 'i' could get changed.

To review C++ code with a reasonable speed (as compared to Java, C or
even PL/SQL code of the same functional complexity -- even FORTRAN), one
would have to put a lot of trust to the people who wrote it. I
personally got burned too many times and I do not trust anymore so I
have to bite the bullet and jump the sources back and forth like crazy.
Which brings us back to the productivity question.. it should not come
at a surprise that in a project of any considerable size a developer
spends more time reading, researching and understanding the code than
changing it. From this perspective, unexpectedly, C is so much more
productive than C++ (plus, an equivalent C program usually compiles 10
times faster than C++ -- because "smart guys" like inserting templates
and meta-programming wherever they don't need them or at least they will
include a couple of "cool" headers -- so a change/compile/debug
iteration in C is much shorter than in C++).

Not sure how to break this vicious cycle -- it seems the more powerful a
language is the more it gets abused and the more it hurts the
productivity. Java is getting there too, BTW, and C# is almost there
already (see version 3.0 of the language). I, for one, have never been
more productive than when I wrote in FORTRAN 66 in my University -- and
I can still easily read those subroutines after 25 years. I wish I could
say it of my C++ code after 25 years..

-Pavel

[kwikius]

Pavel wrote:
<...>

I am not sure one language is much more expressive than the other --
IMHO it is much more dependent on the style of use than the language
itself. I have seen quite understandable code in different Assemblers
and much more of inscrutable code in all possible languages even
including Python (although it is not too easy to write something
completely misleading in Python -- maybe only on purpose). But the "cost
of complete understanding" of a C++ program was always among the highest
for me -- often, I had to pre-process a source file to understand with
certainty what's coming from where. Consider this fragment:

int i = 0;
f(i);
myprint(i);

If it is written in Java (or C, for that matter), I can tell with some
certainty that myprint() receives 0 as an argument. But to tell
something about it in C++ I have to know whether f() takes a reference
or a value and, to make things even more fun, I never know which of
possible overloaded f's is called, -- not until I pre-process the code
and line up all possible fs.

Deducing automatically which function to call based on its arguments is
certainly an important feature in making C++ what I would call
"expressive ". Its obviously not available in C. (I cant remember if
there is an overloading scheme available in Java, but even if it is it
would be of limited use because Java is OOP and function overloading is
actually about expressions which are not part of the OOP vocabulary.
Note that Fortress Suns next generation language incorporates
overloading based on various constructs as well as many other familiar
general constructs that have been available in C++ for a long time)

I would prefer if the algorithm regarding which function is actually
called was more rigorously and concisely expressed itself. In general in
C++ you kind of hope that the expected version of a function will be
used, and thats arguably far from ideal (You can't blame C++ for its
complex and loose approach to overloading. C++ is essentially quite a
nice expressive language mixed up with C. The fact that its mixed with C
is AFAIK a major reason for its success, but also the source of many of
its problems (I think this is said somewhere by Bjarne Stroustrup)

In fact I am currently trying to find that simple algorithm regarding
expressions and their relation to types. Its important enough IMHO to be
basis of a whole language. Programming is essentially about writing
expressions. You want conciseness, intuitiveness and clarity with
generality. I am very grateful to C++ for showing me these things and
can now sit back in my armchair and see if and how to improve how C++
goes about it(but in another language, C++ is already seriously
overweight with new stuff) Standing on the giants shoulders and all
that. So can you have expressiveness, but also precision. C++ shows the
problem but not the full solution.

BTW. Note that in the example you gave, because the argument is an int
IOW an inbuilt type there are only a few functions that can be
called(unless you have brought in other namespaces!). If the argument is
a class (a user defined type or UDT) then the list grows large and if
the class involves templates the list grows even larger.

<...>

because "smart guys" like inserting templates

and meta-programming wherever they don't need them or at least they will
include a couple of "cool" headers -- so a change/compile/debug
iteration in C is much shorter than in C++).

Unfortunately I am one of those guys ;-)

http://sourceforge.net/projects/quan

I wouldnt be without quan. It heavily used everyday in my work (though I
dont maintain publicaly any more) and currently C++ is the only language
it can be written practically in.

Not sure how to break this vicious cycle -- it seems the more powerful a
language is the more it gets abused and the more it hurts the
productivity. Java is getting there too, BTW, and C# is almost there
already (see version 3.0 of the language). I, for one, have never been
more productive than when I wrote in FORTRAN 66 in my University -- and
I can still easily read those subroutines after 25 years. I wish I could
say it of my C++ code after 25 years..

Its an interesting problem. All succesful languages grow more complex. I
guess there is a solution, which is the one taken by Haskell... "Avoid
success at all costs". Its an enigmatic motto, but after many years I
finally understand it. I think its the best motto... if you want to stay
expressive ;-)

regards
Andy Little

[Bo Persson]

Pavel wrote:

kwikius wrote:

>On Aug 6, 5:09 pm, Matthias Buelow <m...@incubus.d ewrote:

>>ebony.s...@gm ail.com wrote:
To increase in emphasis on statically verifiable type safety. If
you want type safety, you should be expressive. I believe being
less expressive lead us to script programming.
I don't quite understand that statement. What do you mean? Static
typing and expressiveness in a language are two distinct
concepts. C++ is in some ways more expressive than C but not as
expressive as Lisp (which is a dynamically typed language).
What's got one to do with the other?

Wel heres my take on it.

If you have strong typing you can be more expressive in comfort
because errors in expressions will be caught by the compiler,
whereas dynamic typing postpones errors till runtime and it may
take much testing to try to locate all possible errors.

IOW the dynamic language is "expressive " of many things though some
are potentially incorrect, but the static typed language is
expressive, whilst being (arguably) proved correct prior to
execution.

regards
Andy Little

I am not sure one language is much more expressive than the other --
IMHO it is much more dependent on the style of use than the language
itself. I have seen quite understandable code in different
Assemblers and much more of inscrutable code in all possible
languages even including Python (although it is not too easy to
write something completely misleading in Python -- maybe only on
purpose). But the "cost of complete understanding" of a C++ program
was always among the highest for me -- often, I had to pre-process
a source file to understand with certainty what's coming from
where. Consider this fragment:
int i = 0;
f(i);
myprint(i);

If it is written in Java (or C, for that matter), I can tell with
some certainty that myprint() receives 0 as an argument. But to tell
something about it in C++ I have to know whether f() takes a
reference or a value

Using a better name than f() would help a lot!

Hardly a language problem.

>
To review C++ code with a reasonable speed (as compared to Java, C
or even PL/SQL code of the same functional complexity -- even
FORTRAN), one would have to put a lot of trust to the people who
wrote it. I personally got burned too many times and I do not trust
anymore so I have to bite the bullet and jump the sources back and
forth like crazy. Which brings us back to the productivity
question.. it should not come at a surprise that in a project of
any considerable size a developer spends more time reading,
researching and understanding the code than changing it. From this
perspective, unexpectedly, C is so much more productive than C++
(plus, an equivalent C program usually compiles 10 times faster
than C++ -- because "smart guys" like inserting templates and
meta-programming wherever they don't need them or at least they
will include a couple of "cool" headers -- so a
change/compile/debug iteration in C is much shorter than in C++).

As usual, "You can write bad programs in any language".

Here is an example of what you can do in C
(http://www.ioccc.org/2004/hoyle.c), hardly 10 times easier to read
than anything else.

#include <stdio.h>
#include <stdlib.h>
#include <math.h>

#define _ ;double
#define void x,x
#define case(break,defa ult) break[O]:default[O]:
#define switch(bool) ;for(;x<bool;
#define do(if,else) inIine(else)>in t##if?
#define true (--void++)
#define false (++void--)

char*O=" <60>!?\\\n"_ doubIe[010]_ int0,int1 _ Iong=0 _ inIine(int
eIse){int
O1O=!O _ l=!O;for(;O1O<0 10;++O1O)l+=(O1 O[doubIe]*pow(eIse,O1O)) ;return
l;}int
main(int booI,char*eIse[]){int
I=1,x=-*O;if(eIse){for (;I<010+1;I++)I[doubIe-1]
=booI>I?atof(I[eIse]):!O
switch(*O)x++)a bs(inIine(x))>I ong&&(Iong=abs( inIine(x
)));int1=Iong;m ain(-*O>>1,0);}else{ if(booI<*O>>1){ int0=int1;int1= int0-2*Iong/0
[O]switch(5[O]))putchar(x-*O?(int0>=inIin e(x)&&do(1,x)do (0,true)do(0,fa lse)
case(2,1)do(1,t rue)do(0,false) 6[O]case(-3,6)do(0,false) 6[O]-3[O]:do(1,false)
case(5,4)x?booI ?0:6[O]:7[O])+*O:8[O]),x++;main(++bo oI,0);}}}

Bo Persson

[James Kanze]

On Aug 8, 10:32 am, kwikius <a...@servocomm .freeserve.co.u kwrote:

Pavel wrote:
<...>

int i = 0;
f(i);
myprint(i);

If it is written in Java (or C, for that matter), I can tell
with some certainty that myprint() receives 0 as an
argument. But to tell something about it in C++ I have to
know whether f() takes a reference or a value and, to make
things even more fun, I never know which of possible
overloaded f's is called, -- not until I pre-process the
code and line up all possible fs.

That's not preprocessing. Preprocessing is something else
entirely (which C++ inherits from C). And preprocessing is a
problem: if myprint (or f, for that matter) is a macro, who
knows what the above means.

One of the evolutions of C++ with respect to C is to reduce the
need for macros---good C++ makes very, very limited use of
macros. So you should have less problems with the above in C++
than in C.

Deducing automatically which function to call based on its
arguments is certainly an important feature in making C++ what
I would call "expressive ".

Like everything which increases expressivity, it can be abused.
I'm tempted to say that if myprint is overloaded, and it matters
which instance of myprint is called, overloading has been
abused.

Of course, Pavel is right about one thing: the last line in the
above could be the declaration of a variable (which would be a
duplicate declaration, but if i were in some different scope, it
would be a legal declaration). IMHO, this goes beyond
"expressivi ty", and is frankly a defect. But it's one we
inherited from C, and the same ambiguity exists in C. (All
that's needed, in both cases, is that myprint is defined by a
typedef somewhere. And that's one ambiguity that isn't present
in Java.)

Its obviously not available in C.
(I cant remember if there is an overloading scheme available
in Java, but even if it is it would be of limited use because
Java is OOP and function overloading is actually about
expressions which are not part of the OOP vocabulary.

Never the less, Java's overloading is almost identical to that
of C++. If it's less of an issue, it's only because Java
doesn't support as many implicit conversions (another thing C++
has mainly because of C compatibility).

Note that Fortress Suns next generation language incorporates
overloading based on various constructs as well as many other
familiar general constructs that have been available in C++
for a long time)

I would prefer if the algorithm regarding which function is
actually called was more rigorously and concisely expressed
itself. In general in C++ you kind of hope that the expected
version of a function will be used, and thats arguably far
from ideal (You can't blame C++ for its complex and loose
approach to overloading. C++ is essentially quite a nice
expressive language mixed up with C. The fact that its mixed
with C is AFAIK a major reason for its success, but also the
source of many of its problems (I think this is said somewhere
by Bjarne Stroustrup)

I don't know if Stroustrup said it, but it's certainly true.
The biggest single problem in C++ is the declaration syntax,
which is inherited from C. To many implicit conversions
(especially lossy conversions) would be another inherited
problem. (And it's too many implicit conversions which makes
overload resolution so complicated.)

BTW. Note that in the example you gave, because the argument
is an int IOW an inbuilt type there are only a few functions
that can be called (unless you have brought in other
namespaces!).

Or you have classes which have non-explicit constructors which
take a single integral type.

If the argument is a class (a user defined type or UDT) then
the list grows large and if the class involves templates the
list grows even larger.

<...>

because "smart guys" like inserting templates

and meta-programming wherever they don't need them or at
least they will include a couple of "cool" headers -- so a
change/compile/debug iteration in C is much shorter than in
C++).

On the other hand, because of C++'s better type checking and
encapsulation, you normally need a lot less change/compile/debug
cycles than you would with C. Globally, development times in a
well run project are significantly less in C++ than in C (or in
Java, for that matter).

Not sure how to break this vicious cycle -- it seems the
more powerful a language is the more it gets abused and the
more it hurts the productivity.

That's why you need a development process, and to pay attention
to software engineering issues. Good code review can do wonders
in this regard. Greater expressivity does allow more ways of
screwing things up, but it also allows more effective solutions.
The trick is to manage things so you get the benefits without
the costs.

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Aug 8, 10:46 am, "Bo Persson" <[e-mail] te:

Pavel wrote:

I am not sure one language is much more expressive than the other --
IMHO it is much more dependent on the style of use than the language
itself. I have seen quite understandable code in different
Assemblers and much more of inscrutable code in all possible
languages even including Python (although it is not too easy to
write something completely misleading in Python -- maybe only on
purpose). But the "cost of complete understanding" of a C++ program
was always among the highest for me -- often, I had to pre-process
a source file to understand with certainty what's coming from
where. Consider this fragment:
int i = 0;
f(i);
myprint(i);

If it is written in Java (or C, for that matter), I can tell with
some certainty that myprint() receives 0 as an argument. But to tell
something about it in C++ I have to know whether f() takes a
reference or a value

Using a better name than f() would help a lot!

Hardly a language problem.

Yes and no. It's only a fragment; let's expand it some:

int i = 0 ;

void
myFunction()
{
f( i ) ;
myprint( i ) ;
}

Now throw in a "typedef double myprint;" before the first line.
Rather changes things, don't you think?

No matter how you consider it, the declaration syntax of C is a
mistake. A mistake which C++ inherits. It's the price we pay
for C compatibility.

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]