Applications of C++

  • Thread starter magnus.moraberg
  • Start date
M

magnus.moraberg

Hi,

I wish to do a masters in C++ since I enjoyed very much programming
with it in my bachelor program.

In what sectors are C++ programmers most in use today?

Thanks,

Magnus
 
P

Pascal J. Bourguignon

I wish to do a masters in C++ since I enjoyed very much programming
with it in my bachelor program.

In what sectors are C++ programmers most in use today?

Low level, embedded software.
 
R

Rui Maciel

I wish to do a masters in C++ since I enjoyed very much programming
with it in my bachelor program.

Masters in C++? Could you please elaborate on that?


Rui Maciel
 
V

Victor Bazarov

[..]
In what sectors are C++ programmers most in use today?

"Programmer most in use"? Did you mean "programs/programmes"? Then all
kinds of sectors where one can use out-of-the-box solutions. AFAICT, no
medium- to large-scale commercial (shrink-wrap) software that has a long
legacy is going to be rewritten in C# any time soon :)

V
 
O

osmium

Rui Maciel said:
Masters in C++? Could you please elaborate on that?

That was my reaction too. The OP seems to be in Stockholm, Sweden. I think
it might be a Swedish -> English problem.
 
J

James Kanze

I wish to do a masters in C++ since I enjoyed very much
programming with it in my bachelor program.
In what sectors are C++ programmers most in use today?

It would probably be easier to list areas where it isn't used;
almost all large scale applications today are developed in C++.
I work mainly on large scale servers, where C++ is really the
only language used... except for one case of Cobol that I'm
familiar with. At the other end, it's also used for a
considerable amount of system programming, although for
historical reasons, C still sees a lot of use there as well. It
shows up a lot in larger real time systems: telephone routing
and such.

However: if you're working for a masters, you probably shouldn't
worry about the language. In fact, you should learn several,
with different paradigms: at least one functional language, C++,
but probably also Java, probably at least one assembler, and
certainly some smaller, scripting languages. (In the last year
or so, I've probably written more lines of code in AWK than in
C++.)
 
J

James Kanze

Low level, embedded software.

Actually, C still seems to hold sway there, although I can't
figure out why. There are some exceptions, and the OS in your
cell phone is probably written in C++. But C++ is more widelly
used in very large, high level software, particularly where
reliability is important: large scale servers, high level
network management, etc. It's also widely used where
performance is an issue: games and such (and a lot of other
numeric software).
 
J

James Kanze

(e-mail address removed) wrote:

Most high-level interface stuff can be done in higher
languages such as C#, but 3D engines and most gameplay related
functionality is still done in C++ because it's fast and
portable.

Not sure about that. There are a lot of thin clients done in
C#, of course, but anything server side quickly reaches the
limits of Windows, and will run under Unix or on a mainframe.
And C# isn't widespread in those environments.
 
J

James Kanze

I think the means that (as you can in Belgium too) continue
after your Bachelor's degree to get a Masters degree and
specialize in a certain field. In his case I would expect
advanced (C++) programming.

Advanced programming (at the masters level---for that matter,
even at the bachelors level) would not be concerned with a
single language. Certificates in a specific language are more
often the result of some much lower industrial training courses.
 
J

James Kanze

(e-mail address removed) wrote:

[...]
One place C++ falls down badly is for run-time
metaprogramming. I have yet to find a good solution for this.
Java seems to offer the most popular compromise between static
typing and run-time introspection ("reflection"), if not
outright metaprogramming. Lisp and Smalltalk both seem to
have better support, but lack popularity in industry, possibly
because they lack static typing.

Exactly. It's a question of reliability: the more errors that
can be caught by the compiler, the less escape into the actual
program. I work mainly on systems where high reliability is
important. For those, even Java is too "dynamic", and C++ (or
Ada 95) seem to be about right. Note that the size of the
application is an issue as well. The more people collaborating
on the coding, the more static checking becomes important as
well.
In the past, I've had success mixing Perl and C++, though I'm
rapidly replacing Perl with Ruby.

I'm afraid I show my age. For small things (and connecting
software), I use Bourne shell, with AWK and sed.
Another shortcoming of C++ is that the code is extremely
verbose,

I've not noticed this. Verbose compared to what?
unless you've got a special-purpose library
specifically designed to make the task at hand convenient.
Well-written C++ applications often comprise a bunch of DSELs,
stitched together by lowest-common-denominator syntax. The
seams should be pretty minimal. Developing this kind of thing
takes a lot of time, so C++ is not necessarily the quickest
language in which to get something flexible up and running.

That's part of the trade off. Flexibility vs. reliability. C++
is one of the quickest languages to get something large up and
running reliably. With an accent on the "large" and the
"reliably": for fairly small projects, there are likely better
languages, and if you need flexibility more than reliability,
Smalltalk or some of the Lisp dialects (Scheme?) probably beat
it even today.
 
P

Pascal J. Bourguignon

James Kanze said:
(e-mail address removed) wrote:
[...]
One place C++ falls down badly is for run-time
metaprogramming. I have yet to find a good solution for this.
Java seems to offer the most popular compromise between static
typing and run-time introspection ("reflection"), if not
outright metaprogramming. Lisp and Smalltalk both seem to
have better support, but lack popularity in industry, possibly
because they lack static typing.

Exactly. It's a question of reliability: the more errors that
can be caught by the compiler, the less escape into the actual
program. I work mainly on systems where high reliability is
important. For those, even Java is too "dynamic", and C++ (or
Ada 95) seem to be about right. Note that the size of the
application is an issue as well. The more people collaborating
on the coding, the more static checking becomes important as
well.

I think there's a conceptual error in thinking that the compiler will
help catch the errors that matter. The compiler is constrained by the
language, and by the processing of the single file it is given.

I think it would be better to consider static analysis tools in
general, that would be able to do not only checks at the file level,
but also global checks.

These global analysis tools can work as well on dynamic languages than
on static languages.


A dynamically typed function ("duck"-typed), is after all but a kind
of generic function with statically infered types, once you've done
the global analysis.
 
I

Ian Collins

James said:
Actually, C still seems to hold sway there, although I can't
figure out why.

There is a shift away from C to C++ embedded. I moved my first company
over to C++ in 2002. I've been consulting with another large local
client who are currently making the switch (even for the their DSP code,
which was a first for me). The team I currently manage will make the
change in the near future. A lot of embedded development these days is
Linux based, so gcc is the common compiler.

The usual reason for not making the change is lack of in house C++
skills. One factor driving the change (at least around here) is
developers who want to learn or use C++ leaving to follow that path.
 
J

joshuamaurice

There is a shift away from C to C++ embedded.  I moved my first company
over to C++ in 2002.  I've been consulting with another large local
client who are currently making the switch (even for the their DSP code,
which was a first for me).  The team I currently manage will make the
change in the near future. A lot of embedded development these days is
Linux based, so gcc is the common compiler.

The usual reason for not making the change is lack of in house C++
skills.  One factor driving the change (at least around here) is
developers who want to learn or use C++ leaving to follow that path.

I'm curious, do you turn of RTTI and exception support? Do you use
exceptions? How does the (possibly imaginary) code bloat affect your
decision to use C++, or some of the newer features of C++? (With
virtual memory, such code bloat from RTTI and exceptions generally
does not matter. Embedded is different.)
 
M

Michael Doubez

I'm curious, do you turn of RTTI and exception support? Do you use
exceptions? How does the (possibly imaginary) code bloat affect your
decision to use C++, or some of the newer features of C++? (With
virtual memory, such code bloat from RTTI and exceptions generally
does not matter. Embedded is different.)

The C++ compilers for embedded system I have seen (IAR, and ARMCC)
don't implement RTTI and exceptions. There isn't ostream as well and
if there was, I suppose the codecvt would be removed since it tends to
bloat the code.

There used to be an embedded-C++ standard initiative but it seems
(thankfully) dead today; they even removed namespace for some obscure
reasons (perhpas because of the size of name mangling).
 
I

Ian Collins

I'm curious, do you turn of RTTI and exception support? Do you use
exceptions?

No and it depends. Some compilers are better with exceptions than
others. One I used was so bad we had to remove exceptions from our
code. I would use them (or any other language feature) unless there was
an obvious issue.
How does the (possibly imaginary) code bloat affect your
decision to use C++, or some of the newer features of C++? (With
virtual memory, such code bloat from RTTI and exceptions generally
does not matter. Embedded is different.)

Again, exception process is compiler dependant. Code bloat is often an
imaginary issue. Embedded tool chains tend to be better than most at
optimising for size by factoring out duplicated code.
 
U

undefined operator

James said:
> On May 4, 2:00 pm, (e-mail address removed) wrote:
>
>
>
> It would probably be easier to list areas where it isn't used;

Please do so.

Why, for instance, would one choose to use Java instead (assuming they
knew both languages well)? Or a scripting language like Python?

Not talking cell phones, or anything janky like that.
 
J

James Kanze

James Kanze wrote:
Please do so.
Why, for instance, would one choose to use Java instead
(assuming they knew both languages well)?

Any number of reasons. Some valid, others not. The most
frequent valid reasons I see Java used is support in the
infrastructure, or the presense of specific libraries in the
standard version.
Or a scripting language like Python?

I'll use AWK or the Bourne shell for anything processing text,
up to about 500 lines of code.

More generally, if there's a language specialized for what you
want to do, it will probably be a better choice than C++ (which
is very general).
 
J

James Kanze

Almost any newer language, particularly scripting languages.
(Of course, the code isn't really doing the same thing, but
the end result is often the same.)

As you say, the code isn't doing the same thing. For very small
programs (up to, say, 500 lines of code), yes. C++ is more
verbose than, say, AWK or Python. And in fact, for such things,
I use AWK, and not C++. For larger projects, however, the
"verbosity" of C++ fulfills an important function---keeping the
interface specification separate from the implementation code.
While I think C++ is probably a little more verbose than Ada 95,
I don't think that the difference is significant. And I don't
know of any other language which provides comparable features,
and which could really be used for the sort of projects C++
would typically be used for.
 
J

James Kanze

James Kanze said:
(e-mail address removed) wrote:
[...]
One place C++ falls down badly is for run-time
metaprogramming. I have yet to find a good solution for
this. Java seems to offer the most popular compromise
between static typing and run-time introspection
("reflection"), if not outright metaprogramming. Lisp and
Smalltalk both seem to have better support, but lack
popularity in industry, possibly because they lack static
typing.
Exactly. It's a question of reliability: the more errors
that can be caught by the compiler, the less escape into the
actual program. I work mainly on systems where high
reliability is important. For those, even Java is too
"dynamic", and C++ (or Ada 95) seem to be about right. Note
that the size of the application is an issue as well. The
more people collaborating on the coding, the more static
checking becomes important as well.
I think there's a conceptual error in thinking that the
compiler will help catch the errors that matter.

All errors matter. And an error caught by the compiler costs
significantly less to correct than one caught by unit tests, or
even one caught by code review.
The compiler is constrained by the language, and by the
processing of the single file it is given.

I don't see anything restricting the analysis to a single file.
All of the C++ compilers I know do detect a certain number of
errors between files.
 

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
474,159
Messages
2,570,881
Members
47,418
Latest member
NoellaXku

Latest Threads

Top