Why is C++ so popular

[woodbrian77]

I think the most important thing you're missing is availability.

You've mentioned Visual Basic several times in this thread, but in my

world (Unix) it simply doesn't exist as a choice.



If you concentrate on languages which:

- are useful on all major platforms

- have free implementations, so others can compile/change your code

without paying first

- have a decent user base, so you can learn from others, and maybe

use it for a living

- are somewhat general-purpose (i.e. isn't JavaScript)



then the available languages are quite few: C, C++, Java(?), Perl,

Python, Ruby ... Some of the functional languages: Haskell, Erlang,

maybe LISP/Scheme. (I have certainly forgotten a few here; no need

to point them out.)



In my Unix/embedded part of the world, C++ isn't very popular. I meet

a lot of people who loudly dislike C++, and just a few who use it. The

company I work for even had a ban on its use, because of some failed

project in the 1990s.

Are 90% of the people you mention who dislike C++ using C?
Perhaps it would help to think of it like the US Marines:
the few, the proud, the C++ programmers. My experience is
that some lonely times with C++ eventually pays off.


Brian
Ebenezer Enterprises -- making programming fun again.
http://webEbenezer.net

 

[BGB]

With your class experience with C# did you find that it was a cut down
version of C++ or would you describe it in a different way?

in all, the language itself wasn't all that bad.

it was sort of like C++, but mostly lacking a few things like
multiple-inheritance and similar (not a big deal personally).

it is at least much more preferable than Java, where the core language
is pretty stripped-down and awkward, and most things that had been done
to expand on it have been via nasty kludges (with Sun/Oracle leaving the
internals hanging out).


main issues with C# were:
its ability to interface with C and C++ code was a little weak (but at
least, nowhere near as bad as Java);
it is built on top of .NET, which being a MS product, is only
well-supported (on Linux, there is Mono, but it isn't nearly as good or
well-integrated with the OS, 1).

also, .NET typically gets worse performance than native code on
benchmarks (including some other JITs, there are benchmarks where it is
being outperformed by the likes of Lua, Python, and Perl).


at least as-of a few years ago, it didn't have eval or ability to load
program-code from source-code form, ... however, since then both MS and
Mono have added (different) mechanisms to deal with this (in MS's case,
this is the Roslyn API).


1: on Windows, a person can just compile some code as C++/CLI, and have
fairly direct access both to C# land and to C and C++ land, and also
APIs exposed via C++/CLI code can be directly seen by C#.

similarly, LoadLibrary and similar can do a lot more magic (no real need
to worry about native-vs-managed libraries, ...).


on Mono, C++/CLI code doesn't work, leaving the only major (portable)
cross-language interface as P/Invoke (requires writing any structs or
function-prototypes in C#, and doesn't deal with the entire C type-system).

going the other way, requires linking against the Mono libraries, and
making use of a lot of Mono-specific API calls.

this wouldn't be as bad, except that Mono is a pain to get built on
Windows, and this would mean having to go through the hassle of having
two different sets of C# <-> C interfaces (one for MS's .NET, and
another for Mono).


I wouldn't mind things as much otherwise, and have written a few small
apps before using C#, but for my main projects, it is a problem, as I
basically have a large amount of code mostly written in C.


so, it was easier for me just to continue using/expanding my own
scripting language / VM (where the main advantage is mostly that I
control it, and can build it for whatever target I need it on, partly as
I don't really trust 3rd party dependencies).

the language isn't meant to "replace" C or C++ though, but rather to
address some use-cases which are weak areas for them, such as loading
scripts from source, ... (FWIW: dynamically compiling C code does not
make a very good scripting language... I have actually tried this...).


the main reason my script language ended up with a lot of ActionScript3
syntax was partly itself due to C#:
my script language was originally based on JavaScript;
C# had some features that I wanted, but the syntax wouldn't fit as well
on JS;
AS3 had a lot of similar features, but was also JS-based and had better
meshing syntax designs.

so, I ripped off a lot more of AS3's syntax (though the actual semantics
and feature-set are more varied).

(actually, the language reintroduces a lot of stuff from C as well, and
also has some C++ influenced features as well, ...).


for example, does it really matter the exact syntax used for, for
example, get/set properties, or overloaded operators, or more just that
the language has get/set properties and overloaded operators?...

example:
public int foo { get { return foo_i; } set { foo_i=value; } };
vs:
public function get foo():int { foo_i }
public function set foo(value:int) { foo_i=value; }

likewise:
public function operator+(x:Foo, y:Foo):Foo { x.add(y) }


both the JVM and .NET have had some influences on the VM architecture as
well though. (not feeling like going too much into specifics at the
moment though, and doubt that it is all that relevant...).


not that I expect anyone else would want to use it, this is just how
things go.


or such...

 

[BGB]

From what I understand a program written in Java needs a web browser to run
it and I think that might be true for some other languages. However I could
be wrong.

no, it does not.

Java can run in a browser, but more often, it is used for standalone apps.

 

[BGB]

Are 90% of the people you mention who dislike C++ using C?
Perhaps it would help to think of it like the US Marines:
the few, the proud, the C++ programmers. My experience is
that some lonely times with C++ eventually pays off.

in my case, I am more of a C developer, but also use C++ somewhat.

the main merit C++ has is that it has a lot of features beyond those
available in plain C.


the main drawback C++ has is that the syntax, language features, and
ABI, are sufficiently complex to make low-level interfacing at this
level problematic (it is much easier to write tools that can parse and
work with C than deal with C++ at its own level).

(it is easier for "mere mortals" to write a reasonably correct C parser
than for them to write a reasonably correct C++ parser...).


historically, there were often problems with GNU G++ as well, ...


there are also differences with compilation speeds (C++ code compiling
slower than C code), ... (not exactly like C code compiles quickly
either... but shaving down compile times may be relevant...).


so, even if the code is not as pretty sometimes, C may still be a plenty
usable option.

a lot depends on tradeoffs...


or such...

 

[BGB]

fix/add:
C# is more sort of "part-way" between Java and C++.
semantically, it is more like Java, but some syntactic elements more
resemble those in C++.

main issues with C# were:
its ability to interface with C and C++ code was a little weak (but at
least, nowhere near as bad as Java);
it is built on top of .NET, which being a MS product, is only
well-supported (on Linux, there is Mono, but it isn't nearly as good or
well-integrated with the OS, 1).

correction: well-supported on Windows...

its support on Linux kind of sucks...

 

[Ian Collins]

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.

Most software (excluding Web applications) today doesn't use buttons on
forms, nor does it run on windows.

 

[Jorgen Grahn]

Are 90% of the people you mention who dislike C++ using C?

Unix C programmers, yes. There's some kind of sibling rivalry
going on. And some semi-rational reasons too: we've all seen
atrocious C++ code.

/Jorgen

 

[Rui Maciel]

Unix C programmers, yes. There's some kind of sibling rivalry
going on. And some semi-rational reasons too: we've all seen
atrocious C++ code.

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. A programming
language is, in that aspect, just like any foreign language: it isn't
automatically better or worse just because someone is seen saying silly
things in it.


Rui Maciel

 

[Ian Collins]

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. A programming
language is, in that aspect, just like any foreign language: it isn't
automatically better or worse just because someone is seen saying silly
things in it.

In kernel land bigotry and FUD are big players.

 

[Rui Maciel]

the main merit C++ has is that it has a lot of features beyond those
available in plain C.

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.


Rui Maciel

 

[Brian]

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 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. I suspect
you would need to modify the code to allow for a smaller screen size that
the mobile phone has.

 

[Brian]

Most software (excluding Web applications) today doesn't use buttons on
forms, nor does it run on windows.

But if you don't click on a button or select from a pull down menu then how
do you tell the program what you want to do. Apart from some utils that run
in DOS most of my programs use buttons on a form.

 

[Ian Collins]

But if you don't click on a button or select from a pull down menu then how
do you tell the program what you want to do. Apart from some utils that run
in DOS most of my programs use buttons on a form.

Most software today is either games or embedded.

 

[BGB]

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.

could be.

(fantasy land here).


I would probably opt for:
type-inferred variables;
maybe something akin to operator overloading (possibly with some special
and named operators, 1);
possibly, function overloading (likely including return type, 2).
maybe closures (or at least anonymous functions, 3);
scope delegation (4);
....

1: something akin to a copy-constructor and destructor;
maybe a type-conversion operator (so it is possible to declare
conversions to/from other types).

2: typically, only the argument types are considered and the return type
is ignored, preventing cases of overloading with a single value type but
multiple return types. in certain cases though (such as with overloaded
operators), this could be useful.

the compiler could reject cases though where this would lead to an
unresolved ambiguity, basically where the both the expression and target
have ambiguous types (the main alternative being to have "best guess"
semantics).

3: preferably full closures, which can also be used as normal function
pointers, although this case introduces a semantic edge case (there
would be either a memory leak or a need for a garbage collector).

alternatively, mechanisms could be provided to aid building these
easier, but it is unclear how to go about doing this without making it
as awkward as is using current means (creating a struct to hold the
captured variables and using an API call to construct a closure using a).

a simpler solution would be to introduce a non-closure block (or
anonymous nested function), and then use this as a means to construct
such a closure (via an API call or overloaded operator).

say:
_Fun { body... }

is the same as a function declared as:
void whaterver() {body...}
....
whatever

and
_Fun functype {body...}
would allow declaring args and a return-type, where functype is
essentially a function-pointer type.

say:
_Fun int(*)(int x, int y) { return x+y; }
_Fun foo_cb_t { return x+y; }
....


4: this is going off into obscure land, but C already has a very
limited form as a common compiler extension: unnamed structs or unions.
the change would be to allow a case whereby the struct or union can
still have a name and be referenced, but the compiler may look into the
struct if trying to resolve a name (declared within the struct);

example:
typedef struct
{
int x, y;
}Foo;

typedef struct
{
Foo xy;
int z;
}Bar;

_Delegate Foo *foo;

"foo" refers to the struct pointer as before.
"x" may also be used, and implicitly be understood as "foo->x".

Bar *foo;

"foo->x;" is the same as "Foo->xy.x;"

....


and I can solidly expect none of this...



combining some of this, a person could then write a closure something like:
struct {
int x, y;
}_Delegate *vars=gcalloc(sizeof(*vars));
x=3; y=4;
return(dyllWrapClosure(vars, "()i",
_Fun int(*)(typeof(vars) vars) { return(x+y); } )

which is a bit ugly, but still slightly better than the present
situation (and doesn't introduce any implicit runtime dependencies).


or such...

 

[Jan G]

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.

While I am going to read the replies and "play along", I am not going to
call you "a troll", because if I did that, I would be as much a hypocrit as
<your favorite example of hypocrisy>. That said, your "inflamatory" subject
title is, of course (?), "the rub": C++ is... well, after this "very
important" thread, surely.

 

[Jan G]

It's multi-paradigm which seems to be good in programming
languages since one paradigm alone can be restricting. C++
is mainly OOP language and I think OOP is the best paradigm
we have at the moment.

C++ has a good, clear syntax even it's "long" and some people
think it requires too much writing. Still, some programming
languages to me look like this: q+05,C-/(-Ae),"hello":r)
which explains why they are not as preferred. C++ is quite
easy to read if it's well written and don't have any fancy
programming magic.

C++ is also fast, a feature that can't be underestimated.
Most programs work better if they have that extra speed
coming from the simple low level structure of C++ executable.

You win, the BOOBY prize: first to respond and ready to show your
"competence". (If war is such a good thing, why doesn't anyone smart
enlist?). Could it be that C++ is actually a BAD programming language? (Not
that it is in any way a reflection on it's creator (if it is bad). While
that COULD be so, I would instantly dismiss anyone suggesting such). That
said, if it is GOOD, did he just get lucky? Then I say, "good for you, you
were lucky". That said, isn't it a said state of affairs, I mean, if it was
that someone had to "get lucky"? I know a lot about luck, because I don't
have any (OK, I actually don't even like "luck").

 

[Jan G]

because it sucks less than the other options?...

Surely because YOUR language did not "take off" because you were
discriminated against because of your refusal to write even one full
sentence? Surely you are just waiting to say "I told you so!". If what you
have is so good, you wouldn't need to TRICK people into "finding" it. You
don't have "nothing" (everyone has some worth, any engineer ... well, don't
draw conclusions), (I hypothesize), but what you have is not apparent (not
that I ask you to make it so). Don't reply to this post, for it is not your
"lotto ticket".

 

[Jan G]

+1

Lynn

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

 

[Jan G]

yes but that's just a feeling.

Prove it. The poster you responded to "had a feeling" that, well what he
said, but you COUNTERED with "yes but that's just a feeling".

YOU, Mr., are on THIN ice. Not to be timid, I am of course saying: Put up or
shut up.

 

[Jan G]

BGB wrote:

[his same old spiel: "my java virtual machine-like thing and reflectory
bombasitcalistic heterohomongenous syntactical stratocaster-based ... um, I
forget, what was he "on" about in his youth?]