survival of c++

P

Phlip

Gianni said:
Anonymous wrote:

Which feature are you referring to ?

The feature where C++ doesn't treat classes as objects, and hence must
piggyback an entire system, templates, just to give them object-like
expressiveness in a few narrow situations.
 
I

Ioannis Vranos

Julie wrote:

Look at the standard libraries supplied w/ the language.

I don't see anything in the C/C++ libraries that support applications-level
programming.


string, vector, rand(), time() etc.

Does your own favourite application programming language have any
standard library of its own?


Right. And if you recall (if you were around, research it if you weren't),
Java was the first language to be specifically marketed to a broad audience,
*including* un/ill-informed management and above.



Ehehe, and I was starting to suspect that Java was behind this. That
means we can't reach any reasonable conclusion in this discussion.


References:


Check "Java" references: http://www.stlport.org/resources/StepanovUSA.html


Check "silver bullet" references:
http://www.stlport.org/resources/StepanovUSA.html


Check "Java":
http://www.biltek.ieee.metu.edu.tr/sayi/mayis01/bs_eng.html




A lot of the early decisions
to use Java (and hence, increase its perceived market share) was due to
misinformation and upper-management edicts that felt that Java == $$.

All of those other languages that you describe are definitely applications
level, but they have never enjoyed the marketing machinery that Java has.



And? C++ lacking any commercial backing, yet succeeded to be the first.






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys
 
B

beliavsky

I am presently working in C++ .It is flexible and efficient.But it is
not the reasons for the language to survive as hardware is running
ahead the capabilities of software(why efficiency?).Java is a cool
language and .NET too even for mobile devices and embedded
systems.Anybody can give some valid reasons so that I can understaand
C++ will survive in the coming years.

Ask someone in (for example) numerical weather prediction if he still
has a need for efficiency.

In "scientific computing", one tries to learn about the physical world
using a mathematical model -- an approximation of reality. A
computational scientist will almost always be able to get better
results, or more results, with more computational power.

For example, many calculations that scientists and engineers involve
the solution of partial differential equations (PDE). You can increase
the quality of a PDE solution by using more grid points, but that
increases the computation time.

Another field where computational demands are inexhaustible is "data
mining". There are infinitely many statistical models that can be fit
to a certain data set, and the data sets themselves are getting bigger
as memory gets cheaper.

C, C++, and Fortran are still important languages for scientific
computing, because speed still matters. Scripting languages such as
Python have a place, but are best used in conjunction with languages
like C and Fortran.
 
R

red floyd

jeffc said:
Just got done with one of those. The application is written on Windows for
a proprietary OS production environment. The application runs fine on the
Windows simulator. In production it crashes. Windows has a debugger (but
we don't need a debugger there because it works fine.) The production OS
does not have a debugger (where it is needed.) Took me 4 days to figure out
that bad boy. Turns out it was a pointer that someone forgot to initialize
to 0.

Know the feeling. Once had to debug an error that was reporting itself
as "this should never occur". Turns out it was a third order effect,
i.e. A corrupts B, corrupted B corrupts C, corrupted C causes the error
to be reported. This was on an embedded system with no memory
protection (Z8000). It also occurred 8 hours into a full bore system
interop test (requiring the services of 14 system operators). We
finally wound up jimmying a hardware ICE into the system in question,
tape recording (on analog audio tape) all (1200/2100Hz analog FSK)
communications, and playing them back. Not fun.

Turns out it was indexing an array by -1. (unchecked return code from
call) Yecch.
 
J

jimmy

Please, Please, Please, read the newsgroup articles
before worrying about C++ efficiency or life time.

I didnt mean to start a flame war Thomas,Ive already saw the FAQ,but
was not happy with it.I was expecting real time advice from
programmers.Anyhow,I havent browsed through the pages of the group for
getting this topic discussion.I am sorry if this is actually
discussed,I am quiet new to the group.
 
R

Richard Herring

[QUOTE="Julie said:
Julie wrote:
Yep, there weren't a lot of alternative languages before C# or Java.
Hmmmm, let us pause a moment and reflect on our knowledge......
.... yep, nothing like: FORTRAN, BASIC, SNOBOL, MODULA 2, Pascal, LISP,
BASIC, Logo, Smalltalk, Prolog, Algol, Ada, PL/1, OPL, ZOPLZ, Assembly,
COBOL, and more. Yep, not a lot of them. Hang on whilst I feed my
aligator, change my banjo string and add more beers to the cooler.

Maybe you have a banjo string around your neck -- we are talking about
(general) applications level languages:

FORTRAN - target: mathematical and formula analysis
BASIC - target: teaching
MODULA/Pascal - target: teaching
LIST LISP?
- target: list processing[/QUOTE]

whatever that is.

How about AI and applications programming (never heard of EMACS?
REDUCE?)
 
R

Robbie Hatley

Mr. John "Anonymous" Doe said:
... When people talk about C/C++ it is a bridge between
low level language and a high level language....

It's really a mistake to speak of C/C++. They are two
languages.

I use both at work: C for firmware, C++ for Windows-based
development.

C is great for firmware because it requires very little
run-time startup code, and C compilers are widely
available for microprocessors, whereas C++ compilers
are not. Not to mention, C is "closer to the machine",
which is important when you are counting every byte on a
execution processor with a total RAM space of 512 bytes.
No, not 512 megabytes, not 512 kilobytes... 512 BYTES.
Usage of fixed-size built-in arrays instead of fancy
containers, macros instead of functions (to avoid stack
use), and very tight code is essential on a machine like
that. C will survive for decades (or centuries) to come;
count on it.

C++, on the other hand, is great for apps to be run on
execution machines with fast processors and large
RAMs. Std. containers, std. algorithms, class hierarchies,
etc. -- I use them all. In a large program to be run on
a powerful machine, the problem isn't trying to save
resources, the problem is how to tame vast reams of
source code. I'm currently doing maintainance on a
legacy C program in excess of 650,000 lines, slowly
converting it to C++, pruning dross, simplifying,
down-sizing. Dude who wrote it should have wrote it in
C++; but he didn't, and then he got fired; so now I
(and two coworkers) have to clean up the mess, and
I'm finding conversion to C++ is key in this. C++,
too, will survive, grow, mutate, for decades to come,
I have no doubt of it.
... There is no argument that java/c# will kill
c/c++ ...

Java mostly runs on virtual machines. Interpreted,
basically. Very, very slow. I've not toyed with
programs compiled from Java to native machine language;
perhaps they're faster. But I suspect still not as
fast as C++.

C# is Microsoft-specific. It'll probably be obsolete
in a few short years, replaced by the latest MS fad.

C and C++ will survive because they're ubiquitous and
non-platform-specific. You can run them on just about
everything from the 8-bit controller chip in your
microwave oven, to a Cray supercomputer. You can't
say that about too many languages.


--
Cheers,
Robbie Hatley
Tustin, CA, USA
email: lonewolfintj at pacbell dot net
web: home dot pacbell dot net slant earnur slant
 
J

jimmy

... When people talk about C/C++ it is a bridge between
It's really a mistake to speak of C/C++. They are two
languages.

I use both at work: C for firmware, C++ for Windows-based
development.

C is great for firmware because it requires very little
run-time startup code, and C compilers are widely
available for microprocessors, whereas C++ compilers
are not. Not to mention, C is "closer to the machine",
which is important when you are counting every byte on a
execution processor with a total RAM space of 512 bytes.
No, not 512 megabytes, not 512 kilobytes... 512 BYTES.
Usage of fixed-size built-in arrays instead of fancy
containers, macros instead of functions (to avoid stack
use), and very tight code is essential on a machine like
that. C will survive for decades (or centuries) to come;
count on it.

C++, on the other hand, is great for apps to be run on
execution machines with fast processors and large
RAMs. Std. containers, std. algorithms, class hierarchies,
etc. -- I use them all. In a large program to be run on
a powerful machine, the problem isn't trying to save
resources, the problem is how to tame vast reams of
source code. I'm currently doing maintainance on a
legacy C program in excess of 650,000 lines, slowly
converting it to C++, pruning dross, simplifying,
down-sizing. Dude who wrote it should have wrote it in
C++; but he didn't, and then he got fired; so now I
(and two coworkers) have to clean up the mess, and
I'm finding conversion to C++ is key in this. C++,
too, will survive, grow, mutate, for decades to come,
I have no doubt of it.


Java mostly runs on virtual machines. Interpreted,
basically. Very, very slow. I've not toyed with
programs compiled from Java to native machine language;
perhaps they're faster. But I suspect still not as
fast as C++.

C# is Microsoft-specific. It'll probably be obsolete
in a few short years, replaced by the latest MS fad.

C and C++ will survive because they're ubiquitous and
non-platform-specific. You can run them on just about
everything from the 8-bit controller chip in your
microwave oven, to a Cray supercomputer. You can't
say that about too many languages.



Thanks John,I understood
The productivity gains of other languages may be there.But C++ is a versatile
language and it will stay.
Thanks everybody
 
T

tom_usenet

The feature where C++ doesn't treat classes as objects, and hence must
piggyback an entire system, templates, just to give them object-like
expressiveness in a few narrow situations.

By "treat classes as objects" are you talking about RTTI? What has
that got to do with generic programming? They are orthogonal features,
and some languages presumably have both (Dylan?).

Tom
 
P

Phlip

tom_usenet said:
By "treat classes as objects" are you talking about RTTI? What has
that got to do with generic programming? They are orthogonal features,
and some languages presumably have both (Dylan?).

To achieve the Prototype Design Pattern in C++, one must write a polymorphic
clone() method, make sure each derived class overrides it properly (and
trivially), and then

To achieve Prototype in Ruby, you merely pass the name of a class to a
function. The name of a class is itself an object. When you call...

klass = MyClass
x = klass.new()

....x is now an instance of MyClass, just as if you had called x =
MyClass.new()

If C++ treated classes as objects, we would not need an extra system -
templates - to pass the names of classes into functions.
 
T

tom_usenet

To achieve the Prototype Design Pattern in C++, one must write a polymorphic
clone() method, make sure each derived class overrides it properly (and
trivially), and then

To achieve Prototype in Ruby, you merely pass the name of a class to a
function. The name of a class is itself an object. When you call...

klass = MyClass
x = klass.new()

...x is now an instance of MyClass, just as if you had called x =
MyClass.new()

Yes, but this has nothing to do with generic programming and
templates.
If C++ treated classes as objects, we would not need an extra system -
templates - to pass the names of classes into functions.

Again, generic programming is not the same as RTTI. Having a "Class"
type or similar is a separate feature. RTTI happens at runtime,
templates and generic programming happens at compile time.

Obviously, in a scripting language there is no such distinction, and
all code is equally slow.

Tom
 
I

Ioannis Vranos

jimmy said:
Thanks John,I understood
The productivity gains of other languages may be there.But C++ is a versatile
language and it will stay.
Thanks everybody



Actually there are not any productivity gains of other .NET languages in
comparison to C++. What productivity gains do you have in mind?






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys
 
F

fabio de francesco

Phlip said:
Someday, JKop may get to maintain legacy code not written by someone as
non-stupid as JKop. Then JKop will appreciate learning the smell and the
feel of various kinds of mystery crashes. Oh, this one feels like an array
overrun. Oh, that one feels like a double delete.

It seems to me that C++ makes you fast to write the code and then
often hardly to read it for maintenance.

Not to mention how much time it is needed to spend with a debugger
just to find out that you made a silly error for a lack of attention.

I'm still learning C++ and I like it very much, but the
above-mentioned thoughts are some of the main reasons I sometimes
would prefer some other language where, for example (Ada95) you can't
either add an integer and/to a float or move a value too big/little to
a variable with range constraints because the compiler stops you
before it is too late.

I think that C++ will surely survive because it is a powerful
language, a lot of good professionals are out there, billions of lines
of good code have already been written and someone has to maintain and
improve them. Not to forget that there are many useful well-done
libraries that make an easier life for developers.

These are enough reasons to keep the C++ market and the language
itself alive and kicking.
I do think that none of the technical discussion brought to
demonstrate the pros and the cons of the language really matter.

Ciao,

Fabio De Francesco
 
J

Julie

fabio said:
It seems to me that C++ makes you fast to write the code and then
often hardly to read it for maintenance.

Not to mention how much time it is needed to spend with a debugger
just to find out that you made a silly error for a lack of attention.

I'm still learning C++ and I like it very much, but the
above-mentioned thoughts are some of the main reasons I sometimes
would prefer some other language where, for example (Ada95) you can't
either add an integer and/to a float or move a value too big/little to
a variable with range constraints because the compiler stops you
before it is too late.

I think that C++ will surely survive because it is a powerful
language, a lot of good professionals are out there, billions of lines
of good code have already been written and someone has to maintain and
improve them. Not to forget that there are many useful well-done
libraries that make an easier life for developers.

These are enough reasons to keep the C++ market and the language
itself alive and kicking.
I do think that none of the technical discussion brought to
demonstrate the pros and the cons of the language really matter.

Ciao,

Fabio De Francesco

If XP (extreme programming) catches on, one of the biggest impediments to
long-term C++ growth or constant market share will lie with the ability of
tools to facilitate refactoring and other similar XP practices. From what I
can tell, the biggest impediment to such tools is the preprocessor -- lose
that, and C++ may enjoy a much longer (and broader) life than with it.
 
J

JKop

fabio de francesco posted:

I'm still learning C++ and I like it very much, but the
above-mentioned thoughts are some of the main reasons I sometimes
would prefer some other language where, for example (Ada95) you can't
either add an integer and/to a float or move a value too big/little to
a variable with range constraints because the compiler stops you
before it is too late.


int main()
{
float cat = 45.6;

int dog = 72;

int blah = cat + dog;
}


All compilers I know of give a warning.


-JKop
 
F

fabio de francesco

JKop said:
fabio de francesco posted:




int main()
{
float cat = 45.6;

int dog = 72;

int blah = cat + dog;
}


All compilers I know of give a warning.

A warning about an action doesn't mean that you can't do it and often
it passes unnoticed. Anyway that was just an example of many different
problems that can be caught while compiling, like the range checking
and some more features that make you to avoid problems.

I don't want to make any comparison between these ( C++ and Ada95 )
languages, because many professionals have already written about this
issue, and as far as I am concerned I like both them.

Fabio De Francesco
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,769
Messages
2,569,582
Members
45,067
Latest member
HunterTere

Latest Threads

Top