«

Given ludicrously huge promulgation of programming languages,
platforms, OS's, embedded systems etc., in which environment C++ is
still the most useful and the predominant language choice. I am NOT
talking about the support of deprecated/outdated API, college homework
assignments, or explanation of data structure - but rather preferential
system type where C++ would be the most adequate choice.


Thanks for your opinion.

In article < .com>,
puzzlecracker <> wrote:
>Given ludicrously huge promulgation of programming languages,
>platforms, OS's, embedded systems etc., in which environment C++ is
>still the most useful and the predominant language choice. I am NOT
>talking about the support of deprecated/outdated API, college homework
>assignments, or explanation of data structure - but rather preferential
>system type where C++ would be the most adequate choice.
>
>
>Thanks for your opinion.

Name the top environments, and C++ is usually there. ??
--
Greg Comeau / Celebrating 20 years of Comeauity!
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Anywhere, where you want to write in assembly but don't want to be
arsed with the details. That covers a lot of ground in itself. There is
a lot of work I would do in C# and OCaml mostly but those are not the
bread and butter for me. I speak only for myself since asking for
*opinions* so these are not facts and never been stated as such.

It boils down to the fact that for what *I* do, other languages don't
give much incentive to switch over for the day job, except ANSI C which
is sometimes mandated by the nature of the work. OCaml is better for
some prototyping work especially. C# is cleaner for .NET Platform
specific gigs. I wouldn't do scripting in C++ either. And so on..

A nice troll but if the point was to get someone upset maybe you get
better luck with other replies.

> A nice troll but if the point was to get someone upset maybe you get
> better luck with other replies.

That is very indignant and cynical statement. I am investing a lot of
time in learning and making living of C++ and genuinely interested in
professional opinion; given you lack the latter, I will simply ignore
your comment.

"puzzlecracker" <> wrote in message
news: oups.com...
> Given ludicrously huge promulgation of programming languages,
> platforms, OS's, embedded systems etc., in which environment C++ is
> still the most useful and the predominant language choice. I am NOT
> talking about the support of deprecated/outdated API, college homework
> assignments, or explanation of data structure - but rather preferential
> system type where C++ would be the most adequate choice.

There is no such thing as predominant language of choice, I think.
Choice is limited by availability and stability of tools/run time for a
language
on a given platform.
If your target is virtual machine, then C++ wouldn't be language of choice,
since machine is already written in C++ or C

Greetings, Bane.

"puzzlecracker" <> wrote in message
news: oups.com...
> Given ludicrously huge promulgation of programming languages,
> platforms, OS's, embedded systems etc., in which environment C++ is
> still the most useful and the predominant language choice. I am NOT
> talking about the support of deprecated/outdated API, college homework
> assignments, or explanation of data structure - but rather preferential
> system type where C++ would be the most adequate choice.

I think you're asking the wrong questions.

I don't think it's helpful to try to match a language
with an environment or platform, but to a given type
of task.

IOW imo "C++ is good for Windows programs", isn't helpful,
but e.g. "C++'s OO features are useful in modeling a database
application", is.

-Mike

puzzlecracker wrote:

> Given ludicrously huge promulgation of programming languages,

You might want to distinguish that promulgation between active languages and
archived ones. Much fewer languages are leading-edge.

> platforms, OS's, embedded systems etc., in which environment C++ is
> still the most useful and the predominant language choice.

The programming world occupies a spectrum from embedded to distributed. From
bits inside registers in specific hardware, to active content like web pages
that can run in any generic device.

C++ is efficient, modular (roughly), typesafe (roughly), and more flexible &
maintainable than assembler. It is also statically-typed, and purely
compiled.

Use C++ from the embedded level to the OS level to large, performance bound
systems.

Use a higher level language to drive C++.

For example, oggle my Flea:

http://flea.sourceforge.net/balancingAct.png

That program drives OpenGL with several layers of stuff. At the lowest
layer, the microcode in the graphics chipset in my graphics card, C++ could
easily have been used to blast all the bits around in an image. C++ competes
directly with Assembly and Machine Language because programs that are easy
to read and change can be faster than programs that force you to think of
the path of each bit.

But maybe the microcode in my graphics chipset wasn't C++; the miracle of
encapsulation and drivers means I don't know if that layer is C++.

At the next layer up, the OS drivers, including OpenGL, could have been
written in C++, and again they might not have been. The odds are very high
they were written in a C language, such as Standard C or GNU C.

Next, the frame around my OpenGL is written in Qt, which is an exquisite and
elegant framework written in pristing C++...

....with one exception. Because C++ uses statically typed polymorphism
(polymorphism that requires inheritance), and because GUIs work best with
the Observer Pattern written in a dynamically typed language (a
message-based language like Smalltalk), Trolltech invented two new C++
keywords, signals and slots, and added them to your compiler.

The moral is the farther you are from the hardware, the more dynamism you
need.

In the left panel of my user interface is a snip of Ruby code, which is a
very high-level language that competes with Perl and Smalltalk - but
certainly not Assembler. My Ruby code drives the commands that generate the
graphical primitive commands sent into OpenGL. So the Ruby code generates
the shape you see, and the OpenGL code renders it.

This far from the metal, the efficiency of static typing is less important
than the flexibility of dynamic typing. So when my system uses Ruby to
generate a shape, you don't need to recompile everything just to change the
shape.

Similarily, if you write a database engine in C++, you drive it with SQL, a
soft dynamic (and declarative) language.

All modules in a program must perform a balancing act between too much
typechecking and too little. Use C++ when those benefits are obvious.

--
Phlip
http://www.greencheese.org/ZeekLand <-- NOT a blog!!!

Phlip wrote:
> puzzlecracker wrote:
>
> > Given ludicrously huge promulgation of programming languages,
>
> You might want to distinguish that promulgation between active languages and
> archived ones. Much fewer languages are leading-edge.
>
> > platforms, OS's, embedded systems etc., in which environment C++ is
> > still the most useful and the predominant language choice.
>
> The programming world occupies a spectrum from embedded to distributed. From
> bits inside registers in specific hardware, to active content like web pages
> that can run in any generic device.
>
> C++ is efficient, modular (roughly), typesafe (roughly), and more flexible &
> maintainable than assembler. It is also statically-typed, and purely
> compiled.
>
> Use C++ from the embedded level to the OS level to large, performance bound
> systems.
>
> Use a higher level language to drive C++.
>
> For example, oggle my Flea:
>
> http://flea.sourceforge.net/balancingAct.png
>
> That program drives OpenGL with several layers of stuff. At the lowest
> layer, the microcode in the graphics chipset in my graphics card, C++ could
> easily have been used to blast all the bits around in an image. C++ competes
> directly with Assembly and Machine Language because programs that are easy
> to read and change can be faster than programs that force you to think of
> the path of each bit.
>
> But maybe the microcode in my graphics chipset wasn't C++; the miracle of
> encapsulation and drivers means I don't know if that layer is C++.
>
> At the next layer up, the OS drivers, including OpenGL, could have been
> written in C++, and again they might not have been. The odds are very high
> they were written in a C language, such as Standard C or GNU C.
>
> Next, the frame around my OpenGL is written in Qt, which is an exquisite and
> elegant framework written in pristing C++...
>
> ...with one exception. Because C++ uses statically typed polymorphism
> (polymorphism that requires inheritance), and because GUIs work best with
> the Observer Pattern written in a dynamically typed language (a
> message-based language like Smalltalk), Trolltech invented two new C++
> keywords, signals and slots, and added them to your compiler.
>
> The moral is the farther you are from the hardware, the more dynamism you
> need.
>
> In the left panel of my user interface is a snip of Ruby code, which is a
> very high-level language that competes with Perl and Smalltalk - but
> certainly not Assembler. My Ruby code drives the commands that generate the
> graphical primitive commands sent into OpenGL. So the Ruby code generates
> the shape you see, and the OpenGL code renders it.
>
> This far from the metal, the efficiency of static typing is less important
> than the flexibility of dynamic typing. So when my system uses Ruby to
> generate a shape, you don't need to recompile everything just to change the
> shape.
>
> Similarily, if you write a database engine in C++, you drive it with SQL, a
> soft dynamic (and declarative) language.
>
> All modules in a program must perform a balancing act between too much
> typechecking and too little. Use C++ when those benefits are obvious.
>
> --
> Phlip
> http://www.greencheese.org/ZeekLand <-- NOT a blog!!!



Philip, interesting perspective, but you shouldn't justify the language
and its kudos based on the program you had written. Java done quite
well in 5.0 to speed graphics quite tremendously (and on some platforms
it even outruns c++), yet I am not proponent of the latter, but rather
eschew it.

C++ is my way to go, albeit slow...

Some say that new standardization won't really recover the language
from its imminent demise (relatively speaking), yet others claim just
the opposite.


will Boost boost?

Your wording (accidentally?) gives impression that you lack
professional opinion, why is that?

puzzlecracker wrote:

> Philip, interesting perspective, but you shouldn't justify the language
> and its kudos based on the program you had written.

I didn't. C++ sucks, and my program barely survived using it.

Please read what I actually wrote.

> Java done quite
> well in 5.0 to speed graphics quite tremendously (and on some platforms
> it even outruns c++), yet I am not proponent of the latter, but rather
> eschew it.

Nobody here is saying "use C++ because it renders fast graphics".