Why is C++ so popular

[Nick Keighley]

How about you stop feigning a topic and calling me names? "The topic"?. Make
me. Bitch.

plonk

 

[Nick Keighley]

I am wondering how else to you write a program that uses buttons on
forms which most programs use these days without
using the run time library (or what ever its called) that Windows
provides.

um. as he said "use OpenGL" or another portable or semi-portable GUI
framework

many programs do *not* have pretty GUI interfaces. I've implemented
telecomms and semi-embedded stuff and they do not have pretty GUIs.
Radars on the other hand do have pretty GUIs but they're a bit beyond
the bog-standard Visual Basic.

And Windows isn't you only option. Are you aware of mobile phone apps?

 

[Nick Keighley]

Most software today is either games or embedded.

or server based

 

[Nick Keighley]

Thanks everyone for your replies.

Some have said that C++ is portable to other platforms. I am
wondering how.

well it takes some work or up-front thought. First separate portable
from non-portable. In most application big chunks of code don't really
care what the platform (Windows, Linux, Mac etc.) is. Then wrapper the
platform specific stuff and hide it away in your own libraries. These
have to be changed when you port.

Another approach is to use a framework that runs on multiple platforms
(OpenGL, Qt etc).

Or use a very portable language like Perl and Python. You can write
quite a complex application in Python and it Just Works where ever you
want to run it.

if you wrote a program for a desktop computer and wanted the same
program to work on a mobile phone then would you load the existing
code into a compiler that creates programs for the mobile phone or
would you use the
compiler that you used to create the program for the desktop computer > and somehow tell the compiler to compile the code for a mobile phone.

depends. If you start out with a portable compiler such as gcc then
you've nothing to do. If you use Visual Studio then you're going to
have to move your project over. Perhaps some way to turn a .sln file
into make dependencies.

Android phones are usually developed in Java so if you've got C++
that's a pain. I understand you can develop Android phones in C++. I
think with iPhones you're stuck with Object C. Pay me Lots of Money
and I'll happily port your app.

I suspect you would need to modify the code to allow for a smaller
screen size that the mobile phone has.

likely. And the people who write mobile phone apps have to contend
with a huge variety of screen sizes.

The point is you have to modify the /GUI/ the bulk of the app remains
unchanged. Look up Model-View-Controller pattern

 

[BGB]

agreed C# looked a pretty good language. And I wouldn't miss multiple
inheritance much. Though I'd need some sort of Java-like interface
(I've no idea if C# has such a thing). I quite liked the safe/unsafe
(or whatever the name was) code concept (not all code needs to nasty
things with pointers).

C# does have interfaces, but the syntax isn't as clear as in Java...

typically, in C# it is more like:
class Bar:Foo,IBaz {
....
}

where IBaz is the interface.

admittedly, I slightly more like it when classes and interfaces are more
clearly distinguished at their point of use, but oh well.

actually C# being a Microsoft product put me off. they don't have a
good track record (and I program for Windows)

yeah.

I would like it much more if it were a more "open" language, and more
readily supported by more than one implementation.

there is the ECMA version, which I had considered doing an
implementation of (for my own VM), but this effort sort of fizzled out
(lack of much point).

good grief. Though I'd expect some sort slowdown for a VM like .NET

or, maybe it is just that Perl, Lua, and Python have gotten a lot faster
in recent years (partly due to most of them now using JITs).

so, one JIT vs another JIT.

part of the gap is also closed by another factor:
VMs for dynamic languages tend toward type-inference.

so, the large potential hit of the type-checking is often largely
factored out by the JIT realizing "this value is always an integer" or
"this value is always a double", ...


MS's JIT kind of suffers though as both it (and also MSVC in general)
kind of have a problem of producing not-very-good machine-code.

it is also true of MSVC, where many of the benchmarks I have seen have
its output being outperformed (slightly) by GCC's output, both of which
typically being outperformed by Intel's compiler.

however, for relative speed differences under 2x I don't really think it
is generally worth worrying about (bigger speed differences can often be
gained within a single compiler by changing optimization settings, or by
altering the code).


a JIT is fast if it is competing against an interpreter, but it is a
narrower edge if it is competing against another JIT.

they just all sort of sit around competing mostly in the 2x-10x
slower-than-native range (as opposed to the usually 10x-100x range for
threaded code, or typically over 100x slowdown typical of more
conventional interpreters, such as "big-switch" driven bytecode
interpreters, ...).


sadly... all of them (.NET, Lua, Python, ...) pretty much outperform my
stuff at this point, but oh well, performance isn't everything...

some of this would require implementing a more efficient VM core (so
that it isn't around 70-80x slower than native), but it is harder to
justify the effort (because, basically, it is "just an interpreter").

 

[Jorgen Grahn]

Conversely, if we would start to discuss which features are missing from the
C programming language, while completely ignoring C++, we would end up with
a list of features which, when implemented, would've pushed the C
programming language closer to C++. For example, the type-generic
expressions introduced in C11 look like someone desperately wanted the C
programming language to support generic programming but did their best to
avoid introducing C++ templates to C.

Not surprising. C++ is in practice a successful next version of C;
it's designed on purpose to do everything C does.

It must feel weird to work with C standardization today.

/Jorgen

 

[Jorgen Grahn]

Seeing atrocious code is no excuse to hate the language. If you showed them
atrocious C code, I bet they wouldn't think differently of C.

Well, I *did* say "semi" ...

If you're a C programmer you can see unmaintainable code, accept that
it's a mess ... but at the same time you *know* the language features
it uses are necessary.

With C++ you know the language features *aren't* necessary. You don't
see (since you're a C programmer with no real C++ experience) how very
useful they are when used properly.

/Jorgen

 

[Jorgen Grahn]

I have not found an answer to the question why C++ is the most preferred
language. I thought it would be a good question to ask in this newsgroup
that has programmers that have been using C++ for a while.
I did read that its popular because it can be transferred to other
platforms but not everyone has more than one platform.

Thanks everyone for your replies.

Some have said that C++ is portable to other platforms. I am wondering how.
if you wrote a program for a desktop computer and wanted the same program
to work on a mobile phone then would you [...]

That may be a misunderstanding. I and some others said we wouldn't
use Visual Basic because it's not portable. The *language*, not just
the programs you write in it.

When I learn a programming language, I don't want that effort to be
tied to a specific operating system or (in the case of VB) to
Microsoft's ever-changing business plans.

/Jorgen

 

[BGB]

Well, I *did* say "semi" ...

If you're a C programmer you can see unmaintainable code, accept that
it's a mess ... but at the same time you *know* the language features
it uses are necessary.

With C++ you know the language features *aren't* necessary. You don't
see (since you're a C programmer with no real C++ experience) how very
useful they are when used properly.

OTOH, a person can see and know how useful the features can be, but due
to other reasons, may still instead opt with C (as, after all, the
features aren't strictly necessary).

this of course does leave C in a semi-frozen state.

a person could instead ask which features C doesn't need, but this is
likely to raise controversy as well (say, a person proposing dropping
'enum' and bit-fields from the language, ...).

 

[Lynn McGuire]

Lynn, that you are a newbie to the spiel and that there should not be
anymore newbies, is quite disconcerting.

I have been writing software for about 40 years
now and have used about 10 software languages.
All software languages suck but C++ sucks less
really describes my feelings well.

Don't even get me started on user interface APIs.

Lynn

 

[ralph]

I have been writing software for about 40 years
now and have used about 10 software languages.
All software languages suck but C++ sucks less
really describes my feelings well.

Don't even get me started on user interface APIs.

LOL

My sentiments exactly.

I started writing C in 1977 ("before they wrote the book" was my brag.
<g>). As an early adopter of OO, cfront shortly after. Languages I
have dabbled with have come and gone, yet c\c++ remains.

Whenever a particular platform, language, script, API came up short -
out came a trusty C++ compiler. I firmly believe there is no
programming problem that can't be resolved with another layer of
indirection.

When asked why C++ is popular, useful, "better", "advisable" ... I
often tried to provide glorious prose and profound 'proofs'. I owe BGB
a debt - from now on I can simply say "It sucks less". <g>

-ralph

 

[Jorgen Grahn]

OTOH, a person can see and know how useful the features can be, but due
to other reasons, may still instead opt with C (as, after all, the
features aren't strictly necessary).

Of course, but that's a different thing. My comments above was about
people who (a) don't use C++ and still (b) complain loudly every time
it's mentioned. Not about rational reasons why people use C.

/Jorgen

 

[BGB]

LOL

My sentiments exactly.

I started writing C in 1977 ("before they wrote the book" was my brag.
<g>). As an early adopter of OO, cfront shortly after. Languages I
have dabbled with have come and gone, yet c\c++ remains.

admittedly, I haven't been around nearly so long...
(at that time, I didn't exist yet).

around 20 years later (mid/late 90s), I was in elementary and middle
school and mostly still learning the basics of programming (a lot of
this by hacking around on/around the Quake source and similar...).

I got mostly into interpreters during high-school, back in the early
2000s. this was partly due to curiosity, and partly because at one point
I tried using and then got frustrated with GNU Guile.

Whenever a particular platform, language, script, API came up short -
out came a trusty C++ compiler. I firmly believe there is no
programming problem that can't be resolved with another layer of
indirection.

When asked why C++ is popular, useful, "better", "advisable" ... I
often tried to provide glorious prose and profound 'proofs'. I owe BGB
a debt - from now on I can simply say "It sucks less". <g>

yeah.

this has mostly been my experience.


there are a few areas where C and C++ come out a little weaker (vs a
scripting language or similar), but the scripting language I use for
these cases would fall on its face if it tried to do what C and C++ are
typically used for doing (a scripting language would make a poor choice
for an implementation language).

 

[Brian]

admittedly, I haven't been around nearly so long...
(at that time, I didn't exist yet).

around 20 years later (mid/late 90s), I was in elementary and middle
school and mostly still learning the basics of programming (a lot of this
by hacking around on/around the Quake source and similar...).

I got mostly into interpreters during high-school, back in the early
2000s. this was partly due to curiosity, and partly because at one point
I tried using and then got frustrated with GNU Guile.



yeah.

this has mostly been my experience.


there are a few areas where C and C++ come out a little weaker (vs a
scripting language or similar), but the scripting language I use for
these cases would fall on its face if it tried to do what C and C++ are
typically used for doing (a scripting language would make a poor choice
for an implementation language).

And C++ is got to be better than programming in assembly language.
I started programming when I brought a TRS 80 computer 30 years ago. When
you switched it on you got a BASIC language editor so the first language I
learnt was BASIC.
To find out how programs worked I took them apart using a disassembler and
stepped through the raw machine language code. I wasn't a hacker like some
people that added a jump statement to by pass the programs protection but
just liked to find out how commercial programs such as games worked.

 

[BGB]

And C++ is got to be better than programming in assembly language.
I started programming when I brought a TRS 80 computer 30 years ago. When
you switched it on you got a BASIC language editor so the first language I
learnt was BASIC.
To find out how programs worked I took them apart using a disassembler and
stepped through the raw machine language code. I wasn't a hacker like some
people that added a jump statement to by pass the programs protection but
just liked to find out how commercial programs such as games worked.

early on, when I started messing with computers (elementary school
years), my dad had a 486, and I used it mostly to play Wolfenstein 3D
and Doom. Quake ran, but slowly, on a 486DX2.

back in these days, the internet was also really slow, and most games
ran in DOS (so it was common to need to boot into DOS mode), ...


I don't really have many clear memories from much before this point
(back this far, memories are a bit fragmentary). I generally classify
these as my early years.

this is, as opposed to now, where I am facing against advancing age and
similar (my 20s will soon be gone... this is worrying...), and also not
having a job.

I have noted occasionally that code of mine from closer to my early
years generally sucked (like, some of my code from around 2004 or so was
pretty horrid).



now, as for C++ vs ASM:

well, C++ offers a few clear advantages at least over ASM:
can get a lot more done in fewer statements;
is portable to a wide variety of systems (vs assembly which has to be
largely rewritten for each type of CPU, OS, ...), and where it isn't
usually possible to move code between one assembler and another (MASM,
NASM, GAS, ... are incompatible), ...

though, there are still a few edge-case things which can only really be
done (effectively, or at all) in ASM.

this results in programs where typically the vast majority is written in
C or C++, but some small parts will exist which are written in ASM
(which may have little or nothing to do with performance).

 

[BGB]

Of course, but that's a different thing. My comments above was about
people who (a) don't use C++ and still (b) complain loudly every time
it's mentioned. Not about rational reasons why people use C.

yes, granted.

there are people who speak out loudly the other way as well, claiming
that people being around and still writing code in C is "archaic and
stupid", ...



meanwhile, I felt curious, and tried compiling the same code (a small C
program) as either C or C++ mode (and timing it), and am only really
seeing about a 30% difference ratio (C++ mode takes about 30% longer).

this is with GCC / G++, can't really test with MSVC as 'time' isn't working.

I get a larger additional slowdown if I add an "#include <iostream>" in
there (53%), but this can't be reflected in the C mode.

adding "#include <windows.h>" doesn't make a huge difference (compile
times are larger, but the ratio is unchanged).

enabling debug or profile makes the compile times longer, but reduces
the difference (~ 20% difference).

including a large project header reduces the ratio to 16% (and 8% with
debug options). (in both seconds, compiling the file takes around 2
seconds).


I guess this shows that at least C-like C++ code does not compile
significantly slower than plain C code.

(admittedly, I suspected it would be more drastic...).

 

[Rui Maciel]

Well, I *did* say "semi" ...

If you're a C programmer you can see unmaintainable code, accept that
it's a mess ... but at the same time you *know* the language features
it uses are necessary.

With C++ you know the language features *aren't* necessary. You don't
see (since you're a C programmer with no real C++ experience) how very
useful they are when used properly.

Usefulness is subjective. Programmer A may write code for a project without
using a single function pointer, but that wouldn't mean that function
pointers weren't necessary.

The same applies to, essentially, any feature provided by C++. There might
be cases where a decision has been made to avoid using specific features,
but that doesn't mean that they aren't useful in other cases.


Rui Maciel

 

[Calum]

I have not found an answer to the question why C++ is the most preferred
language. I thought it would be a good question to ask in this newsgroup
that has programmers that have been using C++ for a while.
I did read that its popular because it can be transferred to other
platforms but not everyone has more than one platform.

In my opinion a number of events conspired to make it popular:

1. Backwards compatibility with C, which was and still is an extremely important language.
2. Historically very good performance, compared to alternatives at the time, with smaller runtime requirements
3. Multi-paradigm (not simply OO).
4. Cross platform, cross vendor.
5. Network effects - one popular, it becomes harder to displace.
6. Standardization
7. Manual memory management, giving better control at the expense of a little safety

I think we can all agree that C++ has its warts, and you may want to change parts if you could start from scratch, but that is not the world we live in.

Calum

 

[Brian]

In my opinion a number of events conspired to make it popular:

1. Backwards compatibility with C, which was and still is an extremely important language.
2. Historically very good performance, compared to alternatives at the
time, with smaller runtime requirements
3. Multi-paradigm (not simply OO).
4. Cross platform, cross vendor.
5. Network effects - one popular, it becomes harder to displace.
6. Standardization
7. Manual memory management, giving better control at the expense of a little safety

I think we can all agree that C++ has its warts, and you may want to
change parts if you could start from scratch, but that is not the world we live in.

Calum

Thanks Calum for the 7 good reasons.
I suspect when I get to know C++ better the reasons you listed will become
more clear to me.

 

[Lynn McGuire]

early on, when I started messing with computers (elementary school years), my dad had a 486, and I used it mostly to play Wolfenstein
3D and Doom. Quake ran, but slowly, on a 486DX2.

back in these days, the internet was also really slow, and most games ran in DOS (so it was common to need to boot into DOS mode), ...


I don't really have many clear memories from much before this point (back this far, memories are a bit fragmentary). I generally
classify these as my early years.

this is, as opposed to now, where I am facing against advancing age and similar (my 20s will soon be gone... this is worrying...),
and also not having a job.

I have noted occasionally that code of mine from closer to my early years generally sucked (like, some of my code from around 2004 or
so was pretty horrid).



now, as for C++ vs ASM:

well, C++ offers a few clear advantages at least over ASM:
can get a lot more done in fewer statements;
is portable to a wide variety of systems (vs assembly which has to be largely rewritten for each type of CPU, OS, ...), and where it
isn't usually possible to move code between one assembler and another (MASM, NASM, GAS, ... are incompatible), ...

though, there are still a few edge-case things which can only really be done (effectively, or at all) in ASM.

this results in programs where typically the vast majority is written in C or C++, but some small parts will exist which are written
in ASM (which may have little or nothing to do with performance).

I would not write anything in ASM nowadays. You
never know when you are going to port to another
platform.

Plus the number of ASM compilers on the pc platform
is simply amazing.

Lynn