"Linus Torvalds Was (Sorta) Wrong About C++"

[Lynn McGuire]

"Linus Torvalds Was (Sorta) Wrong About C++"
http://news.dice.com/2015/03/10/linus-torvalds-was-sorta-wrong-about-c/

"With all the new (and new-ish) languages out there, you might wonder why it’s still worth learning C++, a language first invented in
1983. Wedged amidst lower-level languages such as C, C++ went through a spike in popularity in the mid-‘90s, when developers realized
it was easily translatable to assembly language; but today’s higher-level languages abstract the processor even further away."

"Systems-level programming probably still needs C, but for high-level applications, C++ is a great choice. And judging by the number
of C++ jobs today, the language is not going away anytime soon. Now is still a great time to learn this older programming language;
don’t let the famous naysayers and their profane soliloquies about inelegance dissuade you."

Lynn

[Scott Lurndal]

Lynn McGuire <l...@winsim.com> writes:

>"Systems-level programming probably still needs C, but for high-level applications, C++ is a great choice. And judging by the number
>of C++ jobs today, the language is not going away anytime soon. Now is still a great time to learn this older programming language;
>don’t let the famous naysayers and their profane soliloquies about inelegance dissuade you."
>

There is really no reason that systems-level programming cannot
also be done in C++. I've two operating systems and two hypervisors
to prove it...

[Greg Martin]

Much of what Torvalds has said on the subject was designed to get the
people who were pestering him to switch to /their/ choice of a language
to go away, at least that was what I took away from it when I read the
thread it occurs in. He is happy with the choice of C for git and the
Linux kernel and doesn't wish to switch; end of story.

--
http://www.softsprocket.com

[Johannes Bauer]

On 11.03.2015 18:45, Scott Lurndal wrote:

> There is really no reason that systems-level programming cannot
> also be done in C++. I've two operating systems and two hypervisors
> to prove it...

It's besides the point. Nobody -- especially not Linus -- is arguing
that it cannot be done. Of course it can be done. Hell, I can write a
complete DBMS in Itanium assembly or I can write a C++ compiler in GWBasic.

All Linus is saying is that he WON'T. Judging from the amount of
extrodinarily shitty C++ code I have seen in my life, I kind of
understand why.

Cheers,
Johannes

--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
- Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1...@speranza.aioe.org>

[Wouter van Ooijen]

Johannes Bauer schreef op 11-Mar-15 om 7:12 PM:

> On 11.03.2015 18:45, Scott Lurndal wrote:
>
>> There is really no reason that systems-level programming cannot
>> also be done in C++. I've two operating systems and two hypervisors
>> to prove it...
>
> It's besides the point. Nobody -- especially not Linus -- is arguing
> that it cannot be done. Of course it can be done. Hell, I can write a
> complete DBMS in Itanium assembly or I can write a C++ compiler in GWBasic.
>
> All Linus is saying is that he WON'T. Judging from the amount of
> extrodinarily shitty C++ code I have seen in my life, I kind of
> understand why.

That's like saying that paper is generally used for wiping your ****, so
something written on paper must be shitty.

I sort of agree that C++ is a crappy language, but as that is mostly due
to its C legacy, I am not gona take such insults from a C lover!

(For the record: C++ is may favourite language, crappy or not, for
resource-constrained work. For other work I tend to use Python (which
has its own unqiue share of crappyness.)

Wouter van Ooijen

[JiiPee]

On 11/03/2015 17:45, Scott Lurndal wrote:
> Lynn McGuire <l...@winsim.com> writes:
>
>> "Systems-level programming probably still needs C, but for high-level applications, C++ is a great choice. And judging by the number
>> of C++ jobs today, the language is not going away anytime soon. Now is still a great time to learn this older programming language;

>> don’t let the famous naysayers and their profane soliloquies about inelegance dissuade you."

>>
> There is really no reason that systems-level programming cannot
> also be done in C++. I've two operating systems and two hypervisors
> to prove it...

if a hardware has very little memory, creating a C array is:

char a[10];

Thats 10 bytes

in C++ it might be:

array<int> a(10);

Which take objects allocation (couple of bytes) plus 10. So C makes
shorter executable what many want.

[Mr Flibble]

Wrong. The size of "char a[10]" will likely be the same as the size of
"std::array<char> a;". A std::array does not perform any allocations;
it's storage is inline just like for a C style array.

/Flibble

[Mr Flibble]

Er, I of course meant "std::array<char, 10> a;".

/Flibble

[Christian Gollwitzer]

Am 11.03.15 um 19:46 schrieb JiiPee:

> if a hardware has very little memory, creating a C array is:
>
> char a[10];
>
> Thats 10 bytes
>
> in C++ it might be:
>
> array<int> a(10);
>
> Which take objects allocation (couple of bytes) plus 10. So C makes
> shorter executable what many want.

Are you sure this is correct? My understanding of std::array vs.
std::vector is that the latter gives you dynamic memory with it's
benefits (dyanamic growth etc.) and drawbacks (overhead), while the
former gives you zero overhead compared to a C-style overhead but static
type safety.

Christian

[JiiPee]

On 11/03/2015 18:56, Mr Flibble wrote:

ok sorry, might be.... then it was:
std::vector<int> which takes extra allocation for the object. And now..
dont say this is not true as I have definitely tested it myself!!! :)

and in real life we really most of the time need that vector-system. So
dynamical C-array is smaller

[JiiPee]

okey, array maybe not, but vector<int> for sure. there is an object overhead

[Christopher Pisz]

did you use std::vector::reserve in your test?

> and in real life we really most of the time need that vector-system. So
> dynamical C-array is smaller

char a[10]; is not a _dynamic_ array.


--
I have chosen to troll filter/ignore all subthreads containing the
words: "Rick C. Hodgins", "Flibble", and "Islam"
So, I won't be able to see or respond to any such messages
---

[JiiPee]

Flibble.... i just faced this issue recently when somebody asked me to
change their C-code to C++. Its a music hardware which has only like 64K
memory. He wanted to save every byte. I first said "well, I would use
std::vector.... lets install std stuff". But later I started to agree
with him that plain old C-array takes less space and he does not need
really that vector there (well, was it vector or array i dont remember,
but anyway.. the idea that objects take more space).

Although now as am thinking, he created many other classes and objects
willingly, surely they also take extra memory... so its not so obvious
which is best.

[Christopher Pisz]

Who cares what Linus Torvalds says about anything other than the Linux
Kernel?

[Paavo Helde]

JiiPee <n...@notvalid.com> wrote in news:Mu0Mw.986362$fD1.5...@fx37.am4:

> ok sorry, might be.... then it was:
> std::vector<int> which takes extra allocation for the object. And now..
> dont say this is not true as I have definitely tested it myself!!! :)
>
> and in real life we really most of the time need that vector-system. So
> dynamical C-array is smaller

You need std::vector in real life because you want dynamic resizing or
maybe because the array is just too large to allocate on stack. In both
cases this can be done in C as well, but then you need an additional
pointer and maybe also another variable to hold the array size - which
again produces about the same overhead than std::vector!

In the extreme case where each byte must be conserved, I agree that with C-
style arrays and lots of work one can win some bytes. But as C is a proper
subset of C++, the same code can then be used as C++ code and still have
better type-checking and other goodies.

hth
Paavo

[JiiPee]

yes, and thats what I did with one of my clients... we did a lot of C
code, but added type checking with C++ style as much as possible (or at
least I recommend them)

[JiiPee]

On 11/03/2015 19:35, Paavo Helde wrote:

like they were using
#define MY_VARIABLE 6

and i said "this really must be:
const int MY_VARIABLE = 6;

"

he first hesitated because he was worried it takes more memory, but he
googled and found that not....so he accepted :)

[Ian Collins]

JiiPee wrote:
> On 11/03/2015 19:11, Christian Gollwitzer wrote:
>> Am 11.03.15 um 19:46 schrieb JiiPee:
>>> if a hardware has very little memory, creating a C array is:
>>>
>>> char a[10];
>>>
>>> Thats 10 bytes
>>>
>>> in C++ it might be:
>>>
>>> array<int> a(10);
>>>
>>> Which take objects allocation (couple of bytes) plus 10. So C makes
>>> shorter executable what many want.
>> Are you sure this is correct? My understanding of std::array vs.
>> std::vector is that the latter gives you dynamic memory with it's
>> benefits (dyanamic growth etc.) and drawbacks (overhead), while the
>> former gives you zero overhead compared to a C-style overhead but static
>> type safety.
>

> okey, array maybe not, but vector<int> for sure. there is an object overhead

No more or less than the overhead for a dynamic array in C.

--
Ian Collins

[Mr Flibble]

The "object overhead" of std::vector<int> is constant (O(1)) so becomes
insignificant as n increases; the space complexity of std::vector,
dynamic C arrays and static C arrays is identical: O(n).

If you have lots of vectors of small n you are probably doing it wrong.

/Flibble

[JiiPee]

On 11/03/2015 19:39, Ian Collins wrote:
>
>> okey, array maybe not, but vector<int> for sure. there is an object
>> overhead
>
> No more or less than the overhead for a dynamic array in C.

std::vector<int> a;
std:: cout << sizeof(a) << std::endl;

prints 12

int* b = nullptr;
std:: cout << sizeof(b) << std::endl;

prints 4

So an empty vector seems to take 12 bytes, and empty C-array 4 bytes

[Mr Flibble]

to be equivalent you also need to record the size of the C-array which
is an extra 4 bytes and also an extra 4 bytes if you want to support
vector's capacity which makes 12 bytes.

/Flibble

[JiiPee]

if the size is the same for different types of variables, then only one
variable would do the job instead of multiple.
like:

int size = 10;
int* a = new int[size ];
float* b = new float[size ];
double* c = new double[size ];

so in C we need total : 4 bytes overhead

in C++:
vector<int> a = ...10);
vector<float> b = ...10);
vector<double> c = ..10).;

would need total: 36 bytes of overhead

[JiiPee]

On 11/03/2015 19:33, Christopher Pisz wrote:
> On 3/11/2015 12:29 PM, Lynn McGuire wrote:
>> "Linus Torvalds Was (Sorta) Wrong About C++"
>> http://news.dice.com/2015/03/10/linus-torvalds-was-sorta-wrong-about-c/
>>
>> "With all the new (and new-ish) languages out there, you might wonder
>> why it’s still worth learning C++, a language first invented in 1983.
>> Wedged amidst lower-level languages such as C, C++ went through a spike
>> in popularity in the mid-‘90s, when developers realized it was easily
>> translatable to assembly language; but today’s higher-level languages
>> abstract the processor even further away."
>>
>> "Systems-level programming probably still needs C, but for high-level
>> applications, C++ is a great choice. And judging by the number of C++
>> jobs today, the language is not going away anytime soon. Now is still a
>> great time to learn this older programming language; don’t let the
>> famous naysayers and their profane soliloquies about inelegance dissuade
>> you."
>>
>> Lynn
>
>
> Who cares what Linus Torvalds says about anything other than the Linux
> Kernel?
>
>

come on, be careful... he is from my country: Finland!!! :)

[Wouter van Ooijen]

JiiPee schreef op 11-Mar-15 om 8:32 PM:

Why use a std::vector, which is a flexible array, if you want a fixed
array? You can't blame the language (or rather, the library) for giving
you options that are wrong for your situation.

> Although now as am thinking, he created many other classes and objects
> willingly, surely they also take extra memory... so its not so obvious
> which is best.

A class does not need to take more memory than the data it stores and
the code that implemnts its methods.

Wouter van Ooijen

[Mr Flibble]

If you pass your dynamic C array "a" to a generic function how does that
function know how many elements there are? You need to couple the
pointer with a size for dynamic arrays (just like vector does) to do
anything useful. If "size" is always fixed at 10 then you don't need
dynamic arrays and you are not comparing like with like when comparing
with vector as vectors can grow.

Your examples and analysis of the situation is artificial and naive;
read my other reply regarding the space complexity of the various options.

/Flibble

[JiiPee]

you pass the size-variable with it. (size is 10 here). so where ever you
use a -array you pass size with it.

[Greg Martin]

On 2015-03-11, Christopher Pisz <nos...@notanaddress.com> wrote:
> On 3/11/2015 12:29 PM, Lynn McGuire wrote:
>> "Linus Torvalds Was (Sorta) Wrong About C++"
>> http://news.dice.com/2015/03/10/linus-torvalds-was-sorta-wrong-about-c/
>>
>> "With all the new (and new-ish) languages out there, you might wonder
>> why it’s still worth learning C++, a language first invented in 1983.
>> Wedged amidst lower-level languages such as C, C++ went through a spike
>> in popularity in the mid-‘90s, when developers realized it was easily
>> translatable to assembly language; but today’s higher-level languages
>> abstract the processor even further away."
>>
>> "Systems-level programming probably still needs C, but for high-level
>> applications, C++ is a great choice. And judging by the number of C++
>> jobs today, the language is not going away anytime soon. Now is still a
>> great time to learn this older programming language; don’t let the
>> famous naysayers and their profane soliloquies about inelegance dissuade
>> you."
>>
>> Lynn
>
>
> Who cares what Linus Torvalds says about anything other than the Linux
> Kernel?
>
>

A lot of people as it happens. Whether they should or not is another
matter.

--
http://www.softsprocket.com

[Mr Flibble]

And passing it with it everywhere is equivalent to it being part of it
.. so 8 bytes of overhead.

From my other reply: the "object overhead" as you call it of
std::vector is only significant for small n. If you have lots of
vectors of small n then you are probably doing it wrong.

/Flibble

[Paavo Helde]

JiiPee <n...@notvalid.com> wrote in news:Ie1Mw.381530$dX1.1...@fx21.am4:

>
> int size = 10;
> int* a = new int[size ];
> float* b = new float[size ];
> double* c = new double[size ];

This is not exactly equivalent to std::vector because the capacity and
efficient dynamic resizing are missing.

>
> so in C we need total : 4 bytes overhead

16 bytes, if you want to compare correctly. Each pointer is an overhead.
And if you add capacities, it will make 28 bytes.

>
> in C++:
> vector<int> a = ...10);
> vector<float> b = ...10);
> vector<double> c = ..10).;
>
> would need total: 36 bytes of overhead
>

If the vectors are always of the same length, then the solution is clear:

struct X {
int a;
float b;
double c;
};

std::vector<X> x;

Voila: this has 12 bytes overhead, which is 4 bytes less than the C
version, plus it supports efficient dynamic resizing as a bonus, plus it
is not error-prone and exception-unsafe - an even bigger bonus. Q.E.D.

Cheers
Paavo

[Mr Flibble]

You could of course have a dynamic array of X also.

In my most humble opinion dynamic arrays should only be used for one
thing: allocating uninitialised buffers of char; use std::vector for
everything else..

/Flibble

[JiiPee]

it remains 4 bytes like i originally calculated. size is a global
variable (defined in a same place where "a" is defined). Why 8? size is
4 bytes....

you mean the function needs another size variable as an argument?

[JiiPee]

On 11/03/2015 21:15, Paavo Helde wrote:

> JiiPee <n...@notvalid.com> wrote in news:Ie1Mw.381530$dX1.1...@fx21.am4:
>> int size = 10;
>> int* a = new int[size ];
>> float* b = new float[size ];
>> double* c = new double[size ];
> This is not exactly equivalent to std::vector because the capacity and
> efficient dynamic resizing are missing.

ok but lets assume that project does not need them here....

>
>> so in C we need total : 4 bytes overhead
> 16 bytes, if you want to compare correctly. Each pointer is an overhead.
> And if you add capacities, it will make 28 bytes.

yes, forgot them. we dont add capacity....

>
>> in C++:
>> vector<int> a = ...10);
>> vector<float> b = ...10);
>> vector<double> c = ..10).;
>>
>> would need total: 36 bytes of overhead
>>
> If the vectors are always of the same length, then the solution is clear:
>
> struct X {
> int a;
> float b;
> double c;
> };
>
> std::vector<X> x;
>
> Voila: this has 12 bytes overhead,

>> which is 4 bytes less than the C

But if you use the same struct with C (which would be fair here), then
you get:

int size = 10;
X* x = new X[size];

With 8 bytes overhead.

[JiiPee]

but the issue here is using as little RAM memory as possible

[Öö Tiib]

'std::vector' is typically implemented as 3 pointers:
pointer of start of reserved memory
pointer one after reserved memory
pointer one after used/initialized memory
We usually need all that information in C as well if the array is
going to be allocated dynamically and its contents and size will
be changed dynamically. Having only two is inefficiently non-lazy
and will fragment the dynamic memory too quickly.

However if that is not really what you need then you are no way
enforced to use 'std::vector<int>'. You do not need to use 'int*'
in C++ anyway. If you know there are always 10 elements then you
can use 'std::array<int,10>' instead. If you know the size isn't
known compile time but won't change dynamically and you care about
the 8 bytes then you can use std::unique_ptr<int[]> instead.

[woodb...@gmail.com]

On Wednesday, March 11, 2015 at 1:12:16 PM UTC-5, Johannes Bauer wrote:

Please don't swear here.

Brian

[BGB]

yeah.

for example, if writing code for microcontrollers, these don't really
have an abundance of RAM. a higher-end microcontroller may have
double-digit kB of RAM, but many have only single-digit kB, and some
don't even have kB (you get maybe 256 or 512 bytes of RAM and maybe a
few kB of ROM).

granted, ARM SoCs tend to be a lot more powerful, but there are few good
options if one wants something fairly cheap and available in DIP
packages (vs QFP or BGA or similar).

or such...

[Ian Collins]

woodb...@gmail.com wrote:
> On Wednesday, March 11, 2015 at 1:12:16 PM UTC-5, Johannes Bauer wrote:
>
> Please don't swear here.

He didn't....

--
Ian Collins

[Ian Collins]

I should have said flexible array not dynamic array.

--
Ian Collins

[Paavo Helde]

JiiPee <n...@notvalid.com> wrote in
news:oD2Mw.1187176$6k.10...@fx09.am4:

And losing all the other goodies. This should be at least wrapped in a
proper RAII class whose destructor calls delete[].

Thankfully, my last experience with a computer where saving 4 bytes was
important was with Elektronika MK-61, 30 years ago.

[Jorgen Grahn]

On Wed, 2015-03-11, Wouter van Ooijen wrote:

> (For the record: C++ is may favourite language, crappy or not, for
> resource-constrained work. For other work I tend to use Python (which
> has its own unqiue share of crappyness.)

For Python's big standard library: yes. For rapid prototyping or
small, quick tasks: yes. Otherwise, nowadays I think C++ is a better
choice for more tasks than you'd think. It's not just about resounce
usage: it's about things like static type checking and (for me) more
attention to proper error handling.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Johannes Bauer]

On 11.03.2015 19:37, Wouter van Ooijen wrote:

>> All Linus is saying is that he WON'T. Judging from the amount of
>> extrodinarily shitty C++ code I have seen in my life, I kind of
>> understand why.
>
> That's like saying that paper is generally used for wiping your ****, so
> something written on paper must be shitty.

No, it's like saying: Paper is generally used to wipe your ass so we'll
write on slate in order to prevent idiots from coming along and wiping
their feces all over our code.

> I sort of agree that C++ is a crappy language, but as that is mostly due
> to its C legacy, I am not gona take such insults from a C lover!

That is definitely false, too. The parts that suck about C++ when people
misuse it are exclusively "new" features. Template metaprogramming (oh
the horrors), deeply nested weird inheritance hierarchies and use of the
STL which is unsuited for LOTS of tasks (space constrained, like
embedded for example).

> (For the record: C++ is may favourite language, crappy or not, for
> resource-constrained work. For other work I tend to use Python (which
> has its own unqiue share of crappyness.)

I like some features about C++ as well. Strongly typed enums are
amazing. Static assertions are great. Polymorphic functions can be very
useful, too.

And I actually use it also in embedded environments, but for exactly
those features. As a "C with benefits", not as C++. You won't see any
inheritance at all in my embedded C++ code (you will see interfaces,
though).

My hope is that at least strongly typed enums ("class enums") will go
into C at some point, that would be super cool. I think C11 already as
static assertions, so that's definitely a plus.

Cheers,
Johannnes

--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
- Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1...@speranza.aioe.org>

[Wouter van Ooijen]

Johannes Bauer schreef op 12-Mar-15 om 9:26 AM:

> On 11.03.2015 19:37, Wouter van Ooijen wrote:
>
>>> All Linus is saying is that he WON'T. Judging from the amount of
>>> extrodinarily shitty C++ code I have seen in my life, I kind of
>>> understand why.
>>
>> That's like saying that paper is generally used for wiping your ****, so
>> something written on paper must be shitty.
>
> No, it's like saying: Paper is generally used to wipe your ass so we'll
> write on slate in order to prevent idiots from coming along and wiping
> their feces all over our code.
>
>> I sort of agree that C++ is a crappy language, but as that is mostly due
>> to its C legacy, I am not gona take such insults from a C lover!
>
> That is definitely false, too. The parts that suck about C++ when people
> misuse it are exclusively "new" features. Template metaprogramming (oh
> the horrors), deeply nested weird inheritance hierarchies and use of the
> STL which is unsuited for LOTS of tasks (space constrained, like
> embedded for example).

I can only state *my* opinion. The things I hate in C++ are nearly all
inherited from C (like the weird type conversion rules, the
wrong-way-round way of declaring types, and the overall feel of a
language optimized for a 110 baud teletype. I grew up with Pascal and
loved Ada, I guess it shows).

Template programming is one of the things in C++ I like most, and IMO it
is one of the most powerfull tools in writing re-useable code for very
resource constrained systems.

I agree that large parts of the C++ libraries (and even some parts of
the language) are unsuited to programming very small systems. But even
with those features discarded I still like C++ better for such work than
anything else.

>> (For the record: C++ is may favourite language, crappy or not, for
>> resource-constrained work. For other work I tend to use Python (which
>> has its own unqiue share of crappyness.)
>
> I like some features about C++ as well. Strongly typed enums are
> amazing. Static assertions are great. Polymorphic functions can be very
> useful, too.
>
> And I actually use it also in embedded environments, but for exactly
> those features. As a "C with benefits", not as C++. You won't see any
> inheritance at all in my embedded C++ code (you will see interfaces,
> though).

I am experimenting with (virtual!) inhertitance in combination with the
de-virtualization available in recent gcc and I am positively amazed by
the results. In the appropriate situations (where direct calls would be
using in C) the compiler eliminates all VFT's and can even be persuated
to inline the calls.

Wouter van Ooijen

[Wouter van Ooijen]

Jorgen Grahn schreef op 12-Mar-15 om 8:22 AM:

> On Wed, 2015-03-11, Wouter van Ooijen wrote:
>
>> (For the record: C++ is may favourite language, crappy or not, for
>> resource-constrained work. For other work I tend to use Python (which
>> has its own unqiue share of crappyness.)
>
> For Python's big standard library: yes. For rapid prototyping or
> small, quick tasks: yes. Otherwise, nowadays I think C++ is a better
> choice for more tasks than you'd think. It's not just about resounce
> usage: it's about things like static type checking and (for me) more
> attention to proper error handling.

I agree that Pythons duck-typing is a real PITA. But there are benefits:
I like indent-equals-structure, and in my experinece it is much esasier
to grab a library and do something simple with it in Python than in C++
(like I recently did: generate a my invoices in rtf, or grab the
pictures from all pages liked from a certain webpage). And I can
distribute the source and the customer can just run it with the
appropriate Python implementation on his platform. But I'd never
consider wrting let's say a compiler in Python.

Wouter van Ooijen

[Johannes Bauer]

On 12.03.2015 09:37, Wouter van Ooijen wrote:

> Template programming is one of the things in C++ I like most, and IMO it
> is one of the most powerfull tools in writing re-useable code for very
> resource constrained systems.

Ooooh I think template programming is dreadful. Not because of the
results, the results are really amazing.

But because of the debugging and readability issues. Oh and the horrors
of compiler errors with templates. It's dreadful.

And, since you said you think duck-typing is annoying in Python, you get
similar results in C++ templating code: You can introduce type errors
that aren't ever reported until someone changes something about the code
that uses templating when all the sudden everything just blows up. It is
annoying.

And for resource constrained systems, templates are the aboulte worst
because they introduce a TON of code duplication. I'm not sure what
systems you're referring to, but I'm wokring on Cortex-M
microcontrollers. So let's say a Cortex-M0 with 64k flash. I dare to to
use one, only a single one of those templated STL library functions and
your ROM will be full already.

> I agree that large parts of the C++ libraries (and even some parts of
> the language) are unsuited to programming very small systems. But even
> with those features discarded I still like C++ better for such work than
> anything else.

I just tested it, have a project here that does a ton of work on a
Cortex-M3, compiled in C. 62k of code, with many parts of the C standard
library in there (printf and friends). Now I added one single file:

#include <string>
#include <iostream>
void foo(const std::string &moo) {
std::cout << moo;
}

And linked the whole thing again with g++. First observation: New
syscalls are drawn in. kill, getpid and open. What? kill and getpid,
seriously? What is going on? In any case, after implementing stubs for
those, it links: 293 kB of binary! That is almost a FIVE FOLD increrase
in code side fo doing pretty much nothing.

I must admit that I expected horrible results, but the sheer amount of
useless code that is pulled in actually did shock me. And I double
checked to see if my measurement was correct, and it was. The code is
full of monstrosities like

800f324: d809 bhi.n 800f33a
<std::istreambuf_iterator<wchar_t, std::char_traits<wchar_t> >
std::num_get<wchar_t, std::istreambuf_iterator<wchar_t,
std::char_traits<wchar_t> > >::_M_extract_int<unsigned
int>(std::istreambuf_iterator<wchar_t, std::char_traits<wchar_t> >,
std::istreambuf_iterator<wchar_t, std::char_traits<wchar_t> >,
std::ios_base&, std::_Ios_Iostate&, unsigned int&) const+0x1be>

And I guess if for every variation of every parameter those compiled
template binaries are duplicated, then, yes, you get a fivefold increase
in code size.

> I am experimenting with (virtual!) inhertitance in combination with the
> de-virtualization available in recent gcc and I am positively amazed by
> the results. In the appropriate situations (where direct calls would be
> using in C) the compiler eliminates all VFT's and can even be persuated
> to inline the calls.

Sounds very interesting. Do you have any pointers, I wasn't aware of
that feature. It sounds like something like that could be very useful
for very small systems indeed.

Cheers,
Johannes

[Johannes Bauer]

On 12.03.2015 10:18, Stefan Ram wrote:

> Johannes Bauer <dfnson...@gmx.de> writes:
>> And for resource constrained systems, templates are the aboulte worst
>

> Templates fit small-memory systems well when the
> programmer is knowing what he is doing.

But this is exactly the criticism about C++ in the original article: You
absolutely *have* to know the implications of what you're doing in
detail or you can introduce a vast array of problems by a single line or
reference (like std::string).

It's not transparent by any means what is efficient (and can maybe even
resolved at compile-time) and what will introduce tons of overhead. By
contrast in a language as simple as C it is simply not possible to
intruduce such overhead by seemingly subtle changes in code.

[Wouter van Ooijen]

Johannes Bauer schreef op 12-Mar-15 om 10:23 AM:

> On 12.03.2015 10:18, Stefan Ram wrote:
>> Johannes Bauer <dfnson...@gmx.de> writes:
>>> And for resource constrained systems, templates are the aboulte worst
>>
>> Templates fit small-memory systems well when the
>> programmer is knowing what he is doing.
>
> But this is exactly the criticism about C++ in the original article: You
> absolutely *have* to know the implications of what you're doing in
> detail or you can introduce a vast array of problems by a single line or
> reference (like std::string).
>
> It's not transparent by any means what is efficient (and can maybe even
> resolved at compile-time) and what will introduce tons of overhead. By
> contrast in a language as simple as C it is simply not possible to
> intruduce such overhead by seemingly subtle changes in code.

foo();

Do you know what the effects are? I don't. I can probably find out, but
that holds for everything.

You are clearly comfortabale with finding out what the effect of an
'innconect' C statement are, but not with the corresponding situation in
c++. Fine, but that's no reason to dismiss C++.

Wouter van Ooijen

[David Brown]

Actually, Python might not be a bad choice for a compiler - especially
if it is for a "small" language. It has parsing libraries, and the
string manipulation, pattern matching, regular expressions, dictionaries
(hash maps), etc., would all be very useful in such a program.

The lack of static checking is the biggest disadvantage of Python in my
experience. It's far too easy to make a typo somewhere in a variable
name, or mix up types (like 1 and "1") - you don't find the error until
the code actually runs.

[Wouter van Ooijen]

Johannes Bauer schreef op 12-Mar-15 om 10:05 AM:

> On 12.03.2015 09:37, Wouter van Ooijen wrote:
>
>> Template programming is one of the things in C++ I like most, and IMO it
>> is one of the most powerfull tools in writing re-useable code for very
>> resource constrained systems.
>
> Ooooh I think template programming is dreadful. Not because of the
> results, the results are really amazing.
>
> But because of the debugging and readability issues. Oh and the horrors
> of compiler errors with templates. It's dreadful.

As with all features, it is important how they are used. When I write a
class template, the very first lines check the classm arguments for
suitability. The error messages are still not as clear as they are for a
straight error in your code, but you only need to look at the first
three error lines (the assert failure, dismiss the location of that
assert, and the next line is the template invocation).

> And for resource constrained systems, templates are the aboulte worst
> because they introduce a TON of code duplication.

Again, not when used correctly. I mostly use templates for very thing
Adapters, where inlining saves more code than the duplaction costs. But
in other situations I derive (or implemnet) the template class
from/on-top-of a not-template base class. I guess this pattern has a
name, but I don't know it.

> I'm not sure what
> systems you're referring to, but I'm wokring on Cortex-M
> microcontrollers. So let's say a Cortex-M0 with 64k flash.

That's a *large* chip in my book. I mostly use LPC1114 level chips.

> I dare to to
> use one, only a single one of those templated STL library functions and
> your ROM will be full already.

STL offers run-time flexibility in the size of what you are
storing/handling/computing. If you need that flexibility, OK, but most
small systems don't: they have a fixed-sized task that must be done, no
matter what. Doing more is not a plus. So the STL approach as it is
*implemented* in the current STL is totally unsuited for (very) small
systems.

But some of the basic principles could be very usefull, if implemented
appropriately (fixed-maximum-size containers, allocated without heap).

>
>> I agree that large parts of the C++ libraries (and even some parts of
>> the language) are unsuited to programming very small systems. But even
>> with those features discarded I still like C++ better for such work than
>> anything else.
>
> I just tested it, have a project here that does a ton of work on a
> Cortex-M3, compiled in C. 62k of code, with many parts of the C standard
> library in there (printf and friends). Now I added one single file:
>
> #include <string>
> #include <iostream>
> void foo(const std::string &moo) {
> std::cout << moo;
> }
>
> And linked the whole thing again with g++. First observation: New
> syscalls are drawn in. kill, getpid and open. What? kill and getpid,
> seriously? What is going on? In any case, after implementing stubs for
> those, it links: 293 kB of binary! That is almost a FIVE FOLD increrase
> in code side fo doing pretty much nothing.

I agree the the implementation of std:ostream *sucks* for using on small
systems. But I do like the opeartor<< approach, so I have been
struggling to find alternatives. So far no real solution, but someday...

> I must admit that I expected horrible results, but the sheer amount of
> useless code that is pulled in actually did shock me. And I double
> checked to see if my measurement was correct, and it was. The code is
> full of monstrosities like

When you switch to the desktop-mindset (memory is cheap, but only cache
is fast, average performance is what counts, and better be safe (catch
exceptions) that sorry) the design choices that produce this result are
not that weird. It is just that small embedded systems require a very
different mindset.

>> I am experimenting with (virtual!) inhertitance in combination with the
>> de-virtualization available in recent gcc and I am positively amazed by
>> the results. In the appropriate situations (where direct calls would be
>> using in C) the compiler eliminates all VFT's and can even be persuated
>> to inline the calls.
>
> Sounds very interesting. Do you have any pointers, I wasn't aware of
> that feature. It sounds like something like that could be very useful
> for very small systems indeed.

No, I have not found much beyond the very technical descriptions of how
it is implemented. I use the latest ARM GCC from
https://launchpad.net/gcc-arm-embedded , with -fdevirtualize. I compile
'all-at-one', which might or might not be needed.

I did a talk on Meetting C++ about my previous approach, based purely on
templates called "objects? no thanks":
http://meetingcpp.com/index.php/tv14/items/14.html

IMO C++ is a wonderfull language for developing code (especially
re-useable code) for very small systems, but is difficult to find the
correct subset of the language, libraries and programming paradigms
(juk, I hate that word) because

1. the vast majority of C++ users work in different fields and hence
have very differnt priorities

2. many very-small-systems developers don't appreciate the advantages of
C++ and are scared away by the horror stories of linking in large libraries.

Wouter van Ooijen

[Wouter van Ooijen]

Stefan Ram schreef op 12-Mar-15 om 10:40 AM:

> Johannes Bauer <dfnson...@gmx.de> writes:
>> But this is exactly the criticism about C++ in the original article: You
>> absolutely *have* to know the implications of what you're doing in
>> detail or you can introduce a vast array of problems by a single line or
>> reference (like std::string).
>

> When a programmer is writing code for microcontrollers in C++,
> he - of course - first has to learn C++ and then microcontroller
> programming in C++. He should have come across texts such as (quote):
>
> »Most of the standard and third-party C++ libraries don't
> adhere to these limitatins, so they are not useable.«

Hey, that's my text, with misspellings and all :)

> I am by no means an expert in this topic, but my own
> (German-language) C++ tutorial has a small lesson on
> embedded programming containing this advice:
>
> · avoid exceptions (code size)

IMO exceptions are not that bad (and often better than the
alternatives), if the common implementations would avoid dragging in
dynamic memory. More at http://www.voti.nl/blog/?p=40

> · possibly avoid dynamic memory

IMO this is the root problem. Dynamic memory is a defense-in-depth, a
flexible response, a way to use an unknown amount of resource (memory),
at the cost of some unpredicatbility (both in timing and in 'will the
memory be available' and what to do when it is not). For a (very) small
system those costs often outweight the advantages.

> · possibly avoid virtual classes and templates

I used to agree on virtual classes, but the upcoming devirtualization
might change that completely. I like to use the mechanism, but I hate
the cost (it is an optimization and dead-code-removal barrier). When I
can have it without the costs: jummy!

For me templates are essential.

> · possibly avoid iostreams

Avoid the current implementations. At a high level I like the operator<<
syntax.

> · possibly avoid RTTI, dynamic_cast and the container library

IMO RTTI and dynamic_cast should be avoided anyway.

> · possibly avoid temporary objects

I would not know why.

Wouter van Ooijen

[Wouter van Ooijen]

Stefan Ram schreef op 12-Mar-15 om 11:08 AM:

> Wouter van Ooijen <wou...@voti.nl> writes:
>> As with all features, it is important how they are used. When I write a
>> class template, the very first lines check the classm arguments for
>> suitability.
>

> Isn't that what we got concepts for in C++? Oh, wait,
> there are no concepts in C++!

That's why some people were very eager to get concepts in. IMO something
like that is realy needed, but I could not grok the proposals, so maybe
they were right to defer it to a later version.

Wouter

[Cholo Lennon]

On 03/11/2015 03:12 PM, Johannes Bauer wrote:
> On 11.03.2015 18:45, Scott Lurndal wrote:
>
>> There is really no reason that systems-level programming cannot
>> also be done in C++. I've two operating systems and two hypervisors
>> to prove it...
>
> It's besides the point. Nobody -- especially not Linus -- is arguing
> that it cannot be done. Of course it can be done. Hell, I can write a
> complete DBMS in Itanium assembly or I can write a C++ compiler in GWBasic.

>
> All Linus is saying is that he WON'T. Judging from the amount of
> extrodinarily shitty C++ code I have seen in my life, I kind of
> understand why.

I don't understand your point, In 30 years I've already seen a lot of
shitty, really shitty C code too. IMHO the language is not the problem
(the programmers are)


Regards

--
Cholo Lennon
Bs.As.
ARG

[Wouter van Ooijen]

Stefan Ram schreef op 12-Mar-15 om 2:31 PM:

> Cholo Lennon <cholo...@hotmail.com> writes:
>> I don't understand your point, In 30 years I've already seen a lot of
>> shitty, really shitty C code too. IMHO the language is not the problem
>> (the programmers are)
>

> The programmers have not properly learned the language.
> So the programmers are to blame!
>
> But what if the language is very difficult to be learned?
> Then maybe, after all, it /is/ the language that is to be blamed!
>
> Who was the one who said:
>
> »Compared with other languages,
> learning C++ good really is hard.«
>
> It was Bjarne Stroustrup!
>
> (Or, if a manager makes poorly trained programmers work on a
> critical project, it's the manager who is to blame. Also,
> education managers who choose C++ for pupils and students as
> a first language to gain some programming experience when
> they only have little time for that class.)

Now hat's one I can agree on. If you want someone to have a quick
programming experience, throw out all the Pascal and C derivates, and go
with Python.

Wouter

[Martijn Lievaart]

On Thu, 12 Mar 2015 01:27:11 -0500, Paavo Helde wrote:

> Thankfully, my last experience with a computer where saving 4 bytes was
> important was with Elektronika MK-61, 30 years ago.

Funny, my latest experience where 4 bytes was important was twice today,
once in a binary protocol where every bit counts, the there in a
performance critical app where saving bytes means better cache line
efficiency.

Having said that, I would use std::vector over malloc/realloc every day
unless I know I cannot afford it.

M4

[Luca Risolia]

On 12/03/2015 10:23, Johannes Bauer wrote:
> On 12.03.2015 10:18, Stefan Ram wrote:
> It's not transparent by any means what is efficient (and can maybe even
> resolved at compile-time) and what will introduce tons of overhead. By
> contrast in a language as simple as C it is simply not possible to
> intruduce such overhead by seemingly subtle changes in code.

Nonsense. Try to implement all the functionalities of a std::string in C
and then you will see what you are talking about.

[Cholo Lennon]

On 03/12/2015 10:31 AM, Stefan Ram wrote:

> Cholo Lennon <cholo...@hotmail.com> writes:
>> I don't understand your point, In 30 years I've already seen a lot of
>> shitty, really shitty C code too. IMHO the language is not the problem
>> (the programmers are)
>

> The programmers have not properly learned the language.
> So the programmers are to blame!
>
> But what if the language is very difficult to be learned?
> Then maybe, after all, it /is/ the language that is to be blamed!

I'm not saying that you're wrong, indeed maybe you're right, but I've
seen professional crappy code in all kind of language (Java, VBasic,
(Object)Pascal, C/C++, bash, perl, (Visual)Foxpro/DBase, etc, etc)...

>
> Who was the one who said:
>
> »Compared with other languages,
> learning C++ good really is hard.«
>
> It was Bjarne Stroustrup!
>
> (Or, if a manager makes poorly trained programmers work on a
> critical project, it's the manager who is to blame. Also,
> education managers who choose C++ for pupils and students as
> a first language to gain some programming experience when
> they only have little time for that class.)
>

> Source:
>
> "Wenn man es mit anderen Sprachen vergleicht,
> ist C++ tatsächlich schwer gut zu erlernen."
> BJARNE STROUSTRUP
> http://www.heise.de/developer/artikel/Interview-mit-C-Schoepfer-Bjarne-Stroustrup-2300861.html?artikelseite=2

[Wouter van Ooijen]

> Who was the one who said:
>
> »Compared with other languages,
> learning C++ good really is hard.«
>
> It was Bjarne Stroustrup!

And he was probably right. But is that an argument against?

A modern jet fighter is (almost) impossible to fly by hand, and very
costly and complex to develop and produce. Does that mean that we'd be
better off fighting our enemies on bikes?

Wouter

[JiiPee]

not Visual Basic??

[JiiPee]

In an embedded system?

[Ian Collins]

Stefan Ram wrote:
> Johannes Bauer <dfnson...@gmx.de> writes:
>> But this is exactly the criticism about C++ in the original article: You
>> absolutely *have* to know the implications of what you're doing in
>> detail or you can introduce a vast array of problems by a single line or
>> reference (like std::string).
>

> When a programmer is writing code for microcontrollers in C++,
> he - of course - first has to learn C++ and then microcontroller
> programming in C++. He should have come across texts such as (quote):
>
> »Most of the standard and third-party C++ libraries don't
> adhere to these limitatins, so they are not useable.«
>

> I am by no means an expert in this topic, but my own
> (German-language) C++ tutorial has a small lesson on
> embedded programming containing this advice:
>
> · avoid exceptions (code size)

> · possibly avoid dynamic memory

> · possibly avoid virtual classes and templates

> · possibly avoid iostreams

> · possibly avoid RTTI, dynamic_cast and the container library

> · possibly avoid temporary objects
> (additions or modifications to this list are welcome)

That is a reasonable starting point, modulo templates and virtual calls.

Embedded linkers tend to be pretty good a eliminating duplicate assembly
code, so duplicated template functions often get eliminated.

The manual baggage (switches and the like) used to replace virtual calls
can take up more space than virtual dispatch tables.

Avoiding RTTI usually excludes exceptions.

--
Ian Collins

[Richard]

[Please do not mail me a copy of your followup]

Johannes Bauer <dfnson...@gmx.de> spake the secret code
<mdq0hn$3fd$1...@news.albasani.net> thusly:

>All Linus is saying is that he WON'T. Judging from the amount of
>extrodinarily shitty C++ code I have seen in my life, I kind of
>understand why.

The vast overwhelming majority of shitty C++ code I've seen is written
by people who keep writing C code and calling it C++.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[Johannes Bauer]

On 12.03.2015 15:17, Luca Risolia wrote:

> Nonsense. Try to implement all the functionalities of a std::string in C
> and then you will see what you are talking about.

To be honest I don't give a shit fuck what std::string COULD do. For all
I know it provides a freaking list-interpreter on top of it all.

The point is: I don't want to pay for what I don't use. I only want code
for the stuff I need, not for what I MIGHT need.

Sure, if I want to fly to the moon I might need very large booster
rockets and a spaceship. But if I only want to go shopping my car will
do just fine.

[Bo Persson]

On 2015-03-12 20:12, Johannes Bauer wrote:
> On 12.03.2015 15:17, Luca Risolia wrote:
>
>> Nonsense. Try to implement all the functionalities of a std::string in C
>> and then you will see what you are talking about.
>
> To be honest I don't give a shit fuck what std::string COULD do. For all
> I know it provides a freaking list-interpreter on top of it all.
>
> The point is: I don't want to pay for what I don't use. I only want code
> for the stuff I need, not for what I MIGHT need.
>
> Sure, if I want to fly to the moon I might need very large booster
> rockets and a spaceship. But if I only want to go shopping my car will
> do just fine.
>

And I guess your car doesn't have an automatic gearbox, cruise control,
electric window openers, or a GPS?

Just overhead!


Bo Persson

[Jorgen Grahn]

On Thu, 2015-03-12, Wouter van Ooijen wrote:
> Jorgen Grahn schreef op 12-Mar-15 om 8:22 AM:
>> On Wed, 2015-03-11, Wouter van Ooijen wrote:
>>
>>> (For the record: C++ is may favourite language, crappy or not, for
>>> resource-constrained work. For other work I tend to use Python (which
>>> has its own unqiue share of crappyness.)
>>
>> For Python's big standard library: yes. For rapid prototyping or
>> small, quick tasks: yes. Otherwise, nowadays I think C++ is a better
>> choice for more tasks than you'd think. It's not just about resounce
>> usage: it's about things like static type checking and (for me) more
>> attention to proper error handling.
>
> I agree that Pythons duck-typing is a real PITA. But there are benefits:
> I like indent-equals-structure, and in my experinece it is much esasier
> to grab a library and do something simple with it in Python than in C++

Yes.

That could and should be improved in C++. Sometimes I get the feeling
C++ libraries (like Boost) are written for particle physicists and
people doing their own nuclear test simulations. Flawless but
complex. A Python library is often not designed to last a century,
have maximum performance or cover exactly all uses. So the Python
libraries are more practical and easier to use.

Perhaps the C compatibility of C++ has a drawback here. You can catch
both the C and C++ audience by making your library have a C interface.

So I guess I'm arguing it's more a question of culture than of
language support.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Christopher Pisz]

On 3/12/2015 1:39 PM, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Johannes Bauer <dfnson...@gmx.de> spake the secret code
> <mdq0hn$3fd$1...@news.albasani.net> thusly:
>
>> All Linus is saying is that he WON'T. Judging from the amount of
>> extrodinarily shitty C++ code I have seen in my life, I kind of
>> understand why.
>
> The vast overwhelming majority of shitty C++ code I've seen is written
> by people who keep writing C code and calling it C++.
>

I second that emotion.


--
I have chosen to troll filter/ignore all subthreads containing the
words: "Rick C. Hodgins", "Flibble", and "Islam"
So, I won't be able to see or respond to any such messages
---

[Johannes Bauer]

On 12.03.2015 20:27, Bo Persson wrote:

> And I guess your car doesn't have an automatic gearbox, cruise control,
> electric window openers, or a GPS?

You managed to pick exactly four features my car really does not have.

> Just overhead!

Precisely.

[Luca Risolia]

Il 12/03/2015 20:12, Johannes Bauer ha scritto:
> To be honest I don't give a shit fuck what std::string COULD do. For all
> I know it provides a freaking list-interpreter on top of it all.
>
> The point is: I don't want to pay for what I don't use. I only want code
> for the stuff I need, not for what I MIGHT need.

This does make C a better language, as you seemed to imply. Just don't
use std::string or streams in that case.

[Luca Risolia]

Il 12/03/2015 20:36, Luca Risolia ha scritto:
> This does make C a better language

does NOT make..typo

[Christopher Pisz]

On 3/12/2015 2:35 PM, Johannes Bauer wrote:
> On 12.03.2015 20:27, Bo Persson wrote:
>
>> And I guess your car doesn't have an automatic gearbox, cruise control,
>> electric window openers, or a GPS?
>
> You managed to pick exactly four features my car really does not have.
>
>> Just overhead!
>
> Precisely.
>
> Cheers,
> Johannes

Is catching errors at compile time rather than runtime "overhead" too?
I bet maintenance cost > overhead.

[Scott Lurndal]

Mine has none of those.

Fact is that any one program will seldom, if ever, use
all the features of std::string.

[Johannes Bauer]

On 12.03.2015 20:36, Luca Risolia wrote:
> Il 12/03/2015 20:12, Johannes Bauer ha scritto:
>> To be honest I don't give a shit fuck what std::string COULD do. For all
>> I know it provides a freaking list-interpreter on top of it all.
>>
>> The point is: I don't want to pay for what I don't use. I only want code
>> for the stuff I need, not for what I MIGHT need.
>
> This does make C a better language, as you seemed to imply.

I most certainly did not imply that C is a better language. Both
languages are merely tools for different jobs. Not every tool suits
every job.

> Just don't
> use std::string or streams in that case.

Or any STL. Or any more advanced C++ features. Yup, that is what I'm doing.

[Johannes Bauer]

On 12.03.2015 20:38, Christopher Pisz wrote:

> Is catching errors at compile time rather than runtime "overhead" too?
> I bet maintenance cost > overhead.

Which errors do you have in mind that C doesn't catch at compile time
but C++ does?

Off-hand I can only think of strongly typed enums which C++ has and C
doesn't.

[Wouter van Ooijen]

Ian Collins schreef op 12-Mar-15 om 7:20 PM:

A problem I have with virtuals is that IME unused virtual functions are
not eliminated, hence when you use a type hierarchy that is 'rich' in
virtual functions you will end up getting them all, not just the ones
that you actually use. But I agree that switch-based dispatching is in
most cases even worse.

Wouter van Ooijen

[Paavo Helde]

Johannes Bauer <dfnson...@gmx.de> wrote in news:mdsrv1$gmf$2
@news.albasani.net:

> On 12.03.2015 20:38, Christopher Pisz wrote:
>
>> Is catching errors at compile time rather than runtime "overhead" too?
>> I bet maintenance cost > overhead.
>
> Which errors do you have in mind that C doesn't catch at compile time
> but C++ does?

Are you kidding?

int n = 100;
long* p = malloc(n);
p[n-1] = 42;

---

enum a { a1, a2 };
enum b { b1, b2 };
void g(enum b arg) {}

g(a1);

---

// a.h
void foo(int x);

// a.c
// not including a.h
void foo(long x) {}

// main.c
#include "a.h"
foo(42);

ok, the latter is a linker error in C++, not compile time, but still much
better than a random error on random architecture

The list goes on, but the main point is that in normal C++ one does not
use known error-prone constructs like C-style casts, so more errors are
caught in compile-time even if the corresponding C-style code would
compile without errors in C++.

p.

[Johannes Bauer]

On 12.03.2015 22:24, Paavo Helde wrote:

>> Which errors do you have in mind that C doesn't catch at compile time
>> but C++ does?
>
> Are you kidding?

LOL, no but with your examples I'm sure YOU are kidding:

> int n = 100;
> long* p = malloc(n);
> p[n-1] = 42;

std::vector<int> x;
x.push_back(123);
std::cerr << x[-1] << std::endl;

Totally caught at compile time *cough* NOT

> enum a { a1, a2 };
> enum b { b1, b2 };
> void g(enum b arg) {}
>
> g(a1);

Yup, that one is legit. It was also the example I explicitly gave.

> // a.h
> void foo(int x);
>
> // a.c
> // not including a.h
> void foo(long x) {}
>
> // main.c
> #include "a.h"
> foo(42);
>
> ok, the latter is a linker error in C++, not compile time, but still much
> better than a random error on random architecture

Oh, that is indeed neat! Nice.

> The list goes on, but the main point is that in normal C++ one does not
> use known error-prone constructs like C-style casts,

Haha, sure, it does the super easy thing of having a HANDFULL of
different cast operators which makes it very easy and intuitive to use.

> so more errors are
> caught in compile-time even if the corresponding C-style code would
> compile without errors in C++.

Well to be honest, you only came up with one example that was news to
me. The vector thing isn't caught at compile time AT ALL, the enum
example was the example I gave in the first place and the last example
is indeed neat. My C compiler could and shold do that, too. I wish it did.

[Melzzzzz]

return type would not be caught by linker... c++ mangles function
names by parameter, but not by return type...

[Paavo Helde]

Johannes Bauer <dfnson...@gmx.de> wrote in

news:mdt2de$tqf$1...@news.albasani.net:

> Well to be honest, you only came up with one example that was news to
> me.

The issue is not if something is news to you or not. The issue is whether
something is error-prone and causing problems in the actual work for the
actual programmers. And the winner in this class are C-style casts, I don't
care if they are elegant or not. I really wish that my C++ compiler
rejected all C-style casts.

[Christopher Pisz]

On 3/12/2015 3:12 PM, Johannes Bauer wrote:
> On 12.03.2015 20:38, Christopher Pisz wrote:
>
>> Is catching errors at compile time rather than runtime "overhead" too?
>> I bet maintenance cost > overhead.
>
> Which errors do you have in mind that C doesn't catch at compile time
> but C++ does?
>
> Off-hand I can only think of strongly typed enums which C++ has and C
> doesn't.
>
> Cheers,
> Johannes
>

I had a lot of fun debugging variadic function arguments, which our
genius local C anti-programmer loved to spam everywhere, only to find
casts to incorrect types and void * all over the damn place. That was a
good 6 months of wasted man hours.

That's just one example. At one point, I was making a list and a website
dedicated to the hell C programmers working on C++ put me through. I'll
see if I can dig up the page on my HD at home, if you'd like to read
through years worth of my rants.

[Christopher Pisz]

On 3/12/2015 3:10 PM, Johannes Bauer wrote:
> On 12.03.2015 20:36, Luca Risolia wrote:
>> Il 12/03/2015 20:12, Johannes Bauer ha scritto:
>>> To be honest I don't give a shit fuck what std::string COULD do. For all
>>> I know it provides a freaking list-interpreter on top of it all.
>>>
>>> The point is: I don't want to pay for what I don't use. I only want code
>>> for the stuff I need, not for what I MIGHT need.
>>
>> This does make C a better language, as you seemed to imply.
>
> I most certainly did not imply that C is a better language. Both
> languages are merely tools for different jobs. Not every tool suits
> every job.
>
>> Just don't
>> use std::string or streams in that case.
>
> Or any STL. Or any more advanced C++ features. Yup, that is what I'm doing.
>
> Cheers,
> Johannes
>

Common C programmer mentality. Always a fail.

Who are these deluded people that think they can do better than all the
intelligent minds combined that went into coming up with the STL, not to
mention the millions using it?

So, if I load up your projects, do I get to experience the joys of
maintaining and debugging your custom linked lists, your own custom
"faster, better" strings that aren't faster or better at all, 6000 line
header files full of typedef-ed types, and a plethora of other
constructs, because you are better than everyone else?

Been there, done that on several projects that in the end went belly-up,
all due to some legacy C programmer, that refused to modernize, that
they wouldn't get rid of.

[JiiPee]

On 12/03/2015 19:34, Christopher Pisz wrote:
> On 3/12/2015 1:39 PM, Richard wrote:
>> [Please do not mail me a copy of your followup]
>>
>> Johannes Bauer <dfnson...@gmx.de> spake the secret code
>> <mdq0hn$3fd$1...@news.albasani.net> thusly:
>>
>>> All Linus is saying is that he WON'T. Judging from the amount of
>>> extrodinarily shitty C++ code I have seen in my life, I kind of
>>> understand why.
>>
>> The vast overwhelming majority of shitty C++ code I've seen is written
>> by people who keep writing C code and calling it C++.
>>
>
> I second that emotion.
>
>

I remember me learning first C 1996 January. Then I found C++ and never
after that even considered doing a project with C (well only if no other
options, like embedded). Why use a language with less options? :) So its
kind of interesting to see some saying C is better than C++....the way
they think is so different.

[Öö Tiib]

If the implementation does not eliminate all virtuals of class hierarchy
that have been never called virtually then it is issue of quality of
implementation. Fortunately when engineer has problems with compiler
then engineer can fix the compiler.

[woodb...@gmail.com]

On Thursday, March 12, 2015 at 11:04:18 PM UTC-5, Öö Tiib wrote:
> If the implementation does not eliminate all virtuals of class hierarchy
> that have been never called virtually then it is issue of quality of
> implementation. Fortunately when engineer has problems with compiler
> then engineer can fix the compiler.

Not many programmers fix the compiler bugs they find.
And some code generators are closed source.

Brian
Ebenezer Enterprises - So far G-d has helped us.
http://webEbenezer.net

[BGB]

embedded can be fun, but may need clarification as to the class of
hardware and timing constraints, ...

like, there is a range of hardware, with anywhere from only a few kB of
RAM, up to devices with 100s of MB (basically, cellphone-class hardware,
or better).

likewise, there may be factors like non-real-time (it is done when its
done), vs soft-real-time (avoids significant delays, but small delays
here and there are acceptable), vs hard-real-time (say, code needs to
keep within a strict 10us tolerance and may not have any delays).


admittedly, I personally do most of my code in straight C (generally
including when developing on PCs as well), sometimes with assembler
thrown in the mix.


most of my stuff on embedded HW tends to shy away from dynamic
allocation (may be problematic, unavailable, or introduce delays), and
generally does a lot more using fixed-size global arrays (for example,
one statically knows the max number of IO pins, motor outputs, ... which
may exist, so sanely sized global arrays can keep waste low. likewise,
memory for any buffers can be reserved up-front, rather than allocated
dynamically).

sometimes, it may make sense to fake dynamic allocation by grabbing an
entry from an array (using a rover), or keeping free items in a
free-list, as this may be less of an issue than using a general-purpose
malloc (while still having more of the "feel" of PC style code).


(like, if you want to use a lot of the same code on different devices,
#defines and #ifdef's may be used for per-use-case functionality, ...).

likewise, a lot more code tends towards being event-driven state
machines, and conventional OO style coding doesn't really fit in so
well, the CPU speed may leave something to be desired, or there may be
issues with how much code is needed (for example, on a PC one may
largely forget about the issue of how much executable code they have in
a program, but on resource-constrained devices, code-size may also be an
issue), ...

so, it may be more of a case of doing what works, rather than what is
elegant or pretty.


and, if something goes wrong, maybe you have some blinking lights to
indicate the error status or something, or maybe get extra fancy and
have a small speaker to make noises or similar...

[JiiPee]

On 12/03/2015 16:32, Wouter van Ooijen wrote:
>> Who was the one who said:
>>
>> »Compared with other languages,
>> learning C++ good really is hard.«
>>
>> It was Bjarne Stroustrup!
>
> And he was probably right. But is that an argument against?
>
> A modern jet fighter is (almost) impossible to fly by hand, and very
> costly and complex to develop and produce. Does that mean that we'd be
> better off fighting our enemies on bikes?
>
> Wouter
>

some would say that its not good to make war at all.... but thats
another issue and nothing to do with c++ ...

[Öö Tiib]

On Friday, 13 March 2015 07:25:54 UTC+2, woodb...@gmail.com wrote:
> On Thursday, March 12, 2015 at 11:04:18 PM UTC-5, Öö Tiib wrote:
> > If the implementation does not eliminate all virtuals of class hierarchy
> > that have been never called virtually then it is issue of quality of
> > implementation. Fortunately when engineer has problems with compiler
> > then engineer can fix the compiler.
>
> Not many programmers fix the compiler bugs they find.
> And some code generators are closed source.

If you can't fix it then you can ask other programmer who can fix it. The
closed source software is also made by engineers. Engineer is usually
happy to hear about things that he can improve in his product.

[Christian Gollwitzer]

Am 13.03.15 um 05:04 schrieb Öö Tiib:

> Fortunately when engineer has problems with compiler
> then engineer can fix the compiler.

Wow, that is really a bold statement. I think that "real" compilers,
i.e. something like LLVM or g++, are so incredibly complex that only few
people have the ability to "fix" them, if it is something as complex as
optimizing out dead code. Or am I the only one here who admits to not
understans the inner workings of these beasts? Similarly, I've never
hacked the Linux kernel or OpenOffice, when all I wanted was to install
some hardware or to write a letter.

Christian

[David Brown]

More often, it is a question of /usage/ of the compiler rather than
quality of the compiler. Typically the user has forgotten the
"-Wl,--gc-sections" or "-ffunction-sections" switches (to gcc), or not
enabled optimisation.

Of course, the number of engineers who actually read compiler manuals is
probably smaller than the number who can fix the compiler...

[David Brown]

On 12/03/15 17:33, JiiPee wrote:
> On 12/03/2015 13:47, Wouter van Ooijen wrote:
>> Stefan Ram schreef op 12-Mar-15 om 2:31 PM:
>>> Cholo Lennon <cholo...@hotmail.com> writes:
>>>> I don't understand your point, In 30 years I've already seen a lot of
>>>> shitty, really shitty C code too. IMHO the language is not the problem
>>>> (the programmers are)
>>>
>>> The programmers have not properly learned the language.
>>> So the programmers are to blame!
>>>
>>> But what if the language is very difficult to be learned?
>>> Then maybe, after all, it /is/ the language that is to be blamed!

>>>
>>> Who was the one who said:
>>>
>>> »Compared with other languages,
>>> learning C++ good really is hard.«
>>>
>>> It was Bjarne Stroustrup!
>>>

>>> (Or, if a manager makes poorly trained programmers work on a
>>> critical project, it's the manager who is to blame. Also,
>>> education managers who choose C++ for pupils and students as
>>> a first language to gain some programming experience when
>>> they only have little time for that class.)
>>
>> Now hat's one I can agree on. If you want someone to have a quick
>> programming experience, throw out all the Pascal and C derivates, and
>> go with Python.
>>
>> Wouter
>>
>
> not Visual Basic??
>

If by "quick programming experience" you mean "try being a professional
programmer for a few weeks, then switch career paths to being a crash
test dummy because it's less painful", then Visual Basic is excellent at
finishing your programming experience quickly :-)

(I learned to program in Basic, on a wide variety of home computers. VB
is not actually that bad, as long as you are only doing very small and
simple programs, and don't presume that you are learning more than baby
steps of programming. But while I'd not recommend anyone to bother
learning VB, since there are better alternatives, if the choice was only
C++ or VB for first language, then VB is a better choice.)

[Martijn van Buul]

* BGB:

> embedded can be fun, but may need clarification as to the class of
> hardware and timing constraints, ...
>
> like, there is a range of hardware, with anywhere from only a few kB of
> RAM, up to devices with 100s of MB (basically, cellphone-class hardware,
> or better).

Uh, why restrict the definition to systems that small? At work, I develop
software on hardware hardware that exceeds most desktop PCs(Broadwell Core i5
or i7, with about 16GB of memory) - yet it is still considered an embedded
system, and much of the issues I'm facing are very similar to the problems seen
on, say, a phone.

> most of my stuff on embedded HW tends to shy away from dynamic
> allocation (may be problematic, unavailable, or introduce delays),

It's neither. It's surprisingly predictable. Whether you want do do
dynamic memory on all of your RT tasks is something altogether different.

> and generally does a lot more using fixed-size global arrays (for example,
> one statically knows the max number of IO pins, motor outputs, ... which
> may exist, so sanely sized global arrays can keep waste low.

.. and it can explode in your face, because suddenly you face yourself with
having to allocate for mutually exclusive worst-case scenario's.

> likewise, a lot more code tends towards being event-driven state
> machines, and conventional OO style coding doesn't really fit in so
> well,

In contrary: It fits like a glove. It allows you to cleanly separate
the state machine from whatever it is controlling, (hopefully) leading to
better code quality. Whether that results in an unacceptable performance
penalty is largely the result of implementation details.

In another line of thought: (GUI) applications tend to be *very* event
driven, and so far I haven't heard anyone suggest that OO is a bad paradigm
there.

I've done OO on microcontrollers (which, admittedly, would have been
considered premium workstation classs hardware only a few years ago)

--
Martijn van Buul - pi...@dohd.org

[Johannes Bauer]

On 12.03.2015 23:43, Christopher Pisz wrote:
>>> Just don't
>>> use std::string or streams in that case.
>>
>> Or any STL. Or any more advanced C++ features. Yup, that is what I'm
>> doing.
>

> Common C programmer mentality. Always a fail.

I gave an example where including a *single* reference to std::string
made the program 4 times (!) the size of the controller ROM I'm using.
It just does not fit in the chip.

Don't know why this is so hard to understand to your "mentality", but
it's not a "fail" on my part, but a hard, physical constraint.

> Who are these deluded people that think they can do better than all the
> intelligent minds combined that went into coming up with the STL, not to
> mention the millions using it?

Why do you think I claim I can come up with more "intelligent" code? I
never claimed that and that you seem to suggest I did means the deluded
one here is you.

I don't claim to be able to write better code than the STL.

I claim to be able to write code that ACTUALLY WORKS in my scenario
where any single reference to STL functionality blows the code so out of
proportion that it becomes LITTERALLY unusable on constrained hardware.

> So, if I load up your projects, do I get to experience the joys of

Don't worry, you never will "load up my projects". Because nobody would
hire someone with such a deluded mindset to do an embedded programmer's
job. And because if they did they would fire you on the first day when
you come back from a task and say "it can't be done, we need different
hardware".

> maintaining and debugging your custom linked lists, your own custom
> "faster, better" strings that aren't faster or better at all, 6000 line
> header files full of typedef-ed types, and a plethora of other
> constructs, because you are better than everyone else?

So much anger and so much ignorance in your words. What a pity.

> Been there, done that on several projects that in the end went belly-up,
> all due to some legacy C programmer, that refused to modernize, that
> they wouldn't get rid of.

Life must be hard for you. I truly hope you find someone you can cry
your sorrows to.

[Scott Lurndal]

Christopher Pisz <nos...@notanaddress.com> writes:
>On 3/12/2015 3:10 PM, Johannes Bauer wrote:
>> On 12.03.2015 20:36, Luca Risolia wrote:
>>> Il 12/03/2015 20:12, Johannes Bauer ha scritto:
>>>> To be honest I don't give a shit fuck what std::string COULD do. For all
>>>> I know it provides a freaking list-interpreter on top of it all.
>>>>
>>>> The point is: I don't want to pay for what I don't use. I only want code
>>>> for the stuff I need, not for what I MIGHT need.
>>>
>>> This does make C a better language, as you seemed to imply.
>>
>> I most certainly did not imply that C is a better language. Both
>> languages are merely tools for different jobs. Not every tool suits
>> every job.
>>
>>> Just don't
>>> use std::string or streams in that case.
>>
>> Or any STL. Or any more advanced C++ features. Yup, that is what I'm doing.
>>
>> Cheers,
>> Johannes
>>
>
>Common C programmer mentality. Always a fail.

Insults and intolerance seem to be the extent of
your discourse.

<rant elided>

[Scott Lurndal]

Christopher Pisz <nos...@notanaddress.com> writes:
>On 3/12/2015 3:12 PM, Johannes Bauer wrote:
>> On 12.03.2015 20:38, Christopher Pisz wrote:
>>
>>> Is catching errors at compile time rather than runtime "overhead" too?
>>> I bet maintenance cost > overhead.
>>
>> Which errors do you have in mind that C doesn't catch at compile time
>> but C++ does?
>>
>> Off-hand I can only think of strongly typed enums which C++ has and C
>> doesn't.
>>
>> Cheers,
>> Johannes
>>
>
>I had a lot of fun debugging variadic function arguments, which our
>genius local C anti-programmer loved to spam everywhere, only to find
>casts to incorrect types and void * all over the damn place. That was a
>good 6 months of wasted man hours.
>
>That's just one example. At one point, I was making a list and a website
>dedicated to the hell C programmers working on C++ put me through. I'll
>see if I can dig up the page on my HD at home, if you'd like to read
>through years worth of my rants.

I think most of us would prefer that you keep your rants to
yourself. Here as well. Stick to discussion of C++ and
leave your foolish hatred of C programmers at home.

[Wouter van Ooijen]

>> A problem I have with virtuals is that IME unused virtual functions are
>> not eliminated, hence when you use a type hierarchy that is 'rich' in
>> virtual functions you will end up getting them all, not just the ones
>> that you actually use. But I agree that switch-based dispatching is in
>> most cases even worse.
>
> If the implementation does not eliminate all virtuals of class hierarchy
> that have been never called virtually then it is issue of quality of
> implementation.

That is theoretically true. But for me (and I guess for nearly everyone)
quality of implementation aspects are often of evrriding importance:
practical heap implementations for instance have an a-priori unknown
effect on the real-time behaviour of my code. You can say that that is
not the 'fault' of C++, but for me the consequence is still that in
general I can't the heap in my real-time code.

Fortunately when engineer has problems with compiler
> then engineer can fix the compiler.

That is theoretically true, but totally unpractical in practice.

Wouter van Ooijen

[Wouter van Ooijen]

JiiPee schreef op 13-Mar-15 om 8:04 AM:

And I agree, but that would force me to find another argument that is
understandable to the war-minded world in general ;)

Wouter

[Wouter van Ooijen]

JiiPee schreef op 13-Mar-15 om 2:20 AM:

> Why use a language with less options? :)

One good reason is to look at it from the *reader* instead of the writer
perspective: YOU might settle on a reasonable subset of your language to
write your code in, but each feature will end up in someones subset, so
to read and maintain code you will need to understand the whole language.

Wouter

[Johannes Bauer]

On 11.03.2015 20:35, Paavo Helde wrote:

> In the extreme case where each byte must be conserved, I agree that with C-
> style arrays and lots of work one can win some bytes. But as C is a proper
> subset of C++,

It isn't.

> the same code can then be used as C++ code and still have
> better type-checking and other goodies.

Setup of NVIC configuration for embedded systems: Designated
initializers is the only practical solution. C++ doesn't have those, sadly.