Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #18652 > unrolled thread

reasons for preferring C over C++

Back to article view | Back to comp.arch.embedded

Contents

  reasons for preferring C over C++ Wouter van Ooijen <wouter@voti.nl> - 2014-10-15 19:21 +0200
    Re: reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-15 10:36 -0700
      Re: reasons for preferring C over C++ Wouter van Ooijen <wouter@voti.nl> - 2014-10-15 19:48 +0200
        Re: reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-15 21:25 +0100
          Re: reasons for preferring C over C++ Wouter van Ooijen <wouter@voti.nl> - 2014-10-15 23:28 +0200
            Re: reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-15 23:40 +0100
    Re: reasons for preferring C over C++ Don Y <this@is.not.me.com> - 2014-10-15 10:58 -0700
    Re: reasons for preferring C over C++ upsidedown@downunder.com - 2014-10-15 21:03 +0300
      Re: reasons for preferring C over C++ Don Y <this@is.not.me.com> - 2014-10-15 11:11 -0700
      Re: reasons for preferring C over C++ Wouter van Ooijen <wouter@voti.nl> - 2014-10-15 20:26 +0200
    Re: reasons for preferring C over C++ Stefan Reuther <stefan.news@arcor.de> - 2014-10-15 20:44 +0200
      Re: reasons for preferring C over C++ Wouter van Ooijen <wouter@voti.nl> - 2014-10-15 23:30 +0200
        Re: reasons for preferring C over C++ Stefan Reuther <stefan.news@arcor.de> - 2014-10-16 18:19 +0200
          Re: reasons for preferring C over C++ Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2014-10-16 23:12 +0200
            Re: reasons for preferring C over C++ Reinhardt Behm <rbehm@hushmail.com> - 2014-10-17 13:25 +0800
            Re: reasons for preferring C over C++ Stefan Reuther <stefan.news@arcor.de> - 2014-10-17 18:43 +0200
      Re: reasons for preferring C over C++ "tim....." <tims_new_home@yahoo.co.uk> - 2014-10-18 12:29 +0100
        Re: reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-18 11:44 -0700
          Re: reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-18 22:25 +0100
            Re: reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-18 15:42 -0700
              Re: reasons for preferring C over C++ Niklas Holsti <niklas.holsti@tidorum.invalid> - 2014-10-19 11:03 +0300
              Re: reasons for preferring C over C++ Tim Wescott <seemywebsite@myfooter.really> - 2014-10-19 17:46 -0500
                Re: reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-19 16:28 -0700
                Re: reasons for preferring C over C++ Nobody <nobody@nowhere.invalid> - 2014-10-20 02:47 +0100
          Re: reasons for preferring C over C++ "tim....." <tims_new_home@yahoo.co.uk> - 2014-10-19 09:34 +0100
            Re: reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-19 17:00 -0700
              Re: reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-20 08:50 +0100
                Re: reasons for preferring C over C++ "tim....." <tims_new_home@yahoo.co.uk> - 2014-10-20 11:57 +0100
                  Re: reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-20 12:11 +0100
                  Re: reasons for preferring C over C++ upsidedown@downunder.com - 2014-10-20 22:36 +0300
                    Re: reasons for preferring C over C++ Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2014-10-21 00:36 +0000
              Re: reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-20 08:52 +0100
              Re: reasons for preferring C over C++ "tim....." <tims_new_home@yahoo.co.uk> - 2014-10-20 11:56 +0100
          Re: reasons for preferring C over C++ Stefan Reuther <stefan.news@arcor.de> - 2014-10-19 10:52 +0200
            Re: reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-19 17:16 -0700
        Re: reasons for preferring C over C++ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-18 23:02 +0000
          Re: reasons for preferring C over C++ "tim....." <tims_new_home@yahoo.co.uk> - 2014-10-19 09:45 +0100
    Re: reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-15 22:12 +0200
      Re: reasons for preferring C over C++ Wouter van Ooijen <wouter@voti.nl> - 2014-10-15 23:35 +0200
        Re: reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-15 19:10 -0700
        Re: reasons for preferring C over C++ Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2014-10-16 10:34 +0300
          Re: reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-16 10:10 +0100
    Re: reasons for preferring C over C++ Tim Wescott <tim@seemywebsite.com> - 2014-10-16 01:06 -0500
    Re: reasons for preferring C over C++ Anders.Montonen@kapsi.spam.stop.fi.invalid - 2014-10-16 08:32 +0000
      Re: reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-16 20:54 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#18819

On 14-10-19 01:42 , Paul Rubin wrote:
> Tom Gardner <spamjunk@blueyonder.co.uk> writes:
>>> use containers of multiple types without having to paste code all
>>> over the place.
>> but although /you/ don't have to make duplications in the
>> source code, doesn't the /compiler/ have to expand them in
>> the object code.
> 
> C++ templates do work like that, so you indeed get bloat in the object
> code (just as if you'd manually duplicated code like you'd have to in
> C), but the source code becomes more uniform and maintainable.  The
> bloat isn't a law of nature but rather reflects C++'s design goal of
> zero-overhead abstraction.  
> 
> Other languages like Haskell can avoid the bloat by supporting
> polymorphic functions implemented by passing type info at runtime,
> taking a slight penalty in speed.  I'm not sure how Ada handles this.
> Ada has generic but I don't know how they work.

The rules for Ada generics are specified so that generic units can
either share code between instances, or can use the "macro" approach and
generate specific code for each instance. Some compilers use shared
code, others use the macro approach. I believe there have been some
compilers that let the programmer choose which method to use, but I
don't know if that can be done in any current compiler.

The GNAT compiler uses the macro approach (specific code for each
instance). This tends to produce faster code, at the cost of more code,
of course.

It is sometimes possible to divide generic Ada units into two parts: a
non-generic part that has most of the complex code, and a small generic
wrapper that contains the code that is duplicated (and separately
optimised) for each instance. One way to do to that is to use
tagged-type polymorphism, similar to the Haskell way.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

[toc] | [prev] | [next] | [standalone]

#18832

On Sat, 18 Oct 2014 15:42:11 -0700, Paul Rubin wrote:

> Tom Gardner <spamjunk@blueyonder.co.uk> writes:
>>> use containers of multiple types without having to paste code all over
>>> the place.
>> but although /you/ don't have to make duplications in the source code,
>> doesn't the /compiler/ have to expand them in the object code.
> 
> C++ templates do work like that, so you indeed get bloat in the object
> code (just as if you'd manually duplicated code like you'd have to in
> C), but the source code becomes more uniform and maintainable.  The
> bloat isn't a law of nature but rather reflects C++'s design goal of
> zero-overhead abstraction.
> 
> Other languages like Haskell can avoid the bloat by supporting
> polymorphic functions implemented by passing type info at runtime,
> taking a slight penalty in speed.  I'm not sure how Ada handles this.
> Ada has generic but I don't know how they work.  There's also some
> generics in C11 or C14 that looked nice though I don't remember any
> details by now.

I'm not sure if that's true now or not.

gnu C has a way of defining a function as "link this only if you need 
it" (with attribute ((__weak__)), IIRC).  It basically makes a function 
act like a function in a library, even though it's been compiled into a .o 
file.  If they use that method with templatized methods, then only one 
will get included in the link, even if multiple copies are scattered 
around in the object files.

I don't KNOW that they use that, but I'd be surprised if they didn't.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

[toc] | [prev] | [next] | [standalone]

#18833

Tim Wescott <seemywebsite@myfooter.really> writes:
> I'm not sure if that's true now or not.
> gnu C has a way of defining a function as "link this only if you need 
> it" (with attribute ((__weak__)), IIRC).  It basically makes a function 
> act like a function in a library, even though it's been compiled into a .o 
> file.  If they use that method with templatized methods, then only one 
> will get included in the link, even if multiple copies are scattered 
> around in the object files.

I guess that can help a bit if only some of a template's methods are
used at any given type.  But, basically, there are two conceptual ways
to implement something like template methods: as polymorphic functions
with an amount of runtime dispatch on types (guaranteed safe, but takes
a slowdown from the dispatch), or as "macros" (no slowdown, but code
bloat, like from function inlining).  C++ uses the "macro" approach,
while with other languages (like Haskell and maybe Ada) it's up to the
compiler and can sometimes be controlled by the user.  So even with
((__weak__)) the bloat happens in the cases where the method is actually
used.

[toc] | [prev] | [next] | [standalone]

#18836

On Sun, 19 Oct 2014 17:46:18 -0500, Tim Wescott wrote:

> gnu C has a way of defining a function as "link this only if you need it"
> (with attribute ((__weak__)), IIRC).  It basically makes a function act
> like a function in a library, even though it's been compiled into a .o
> file.  If they use that method with templatized methods, then only one
> will get included in the link, even if multiple copies are scattered
> around in the object files.
> 
> I don't KNOW that they use that, but I'd be surprised if they didn't.

The usual behaviour for g++ is to instantiate the template in each object
file, and leave it to the linker to remove duplicates.

If the linker doesn't support that, there are switches to either track
template instantiations so that they can be compiled and linked separately
(-frepo), or to suppress automatic instantiation and require the code to
explicitly instantiate any templates which it uses (-fno-implicit-templates).

https://gcc.gnu.org/onlinedocs/gcc/Template-Instantiation.html

However, that isn't what Paul was talking about. While exact duplicates
can be removed, if you instantiate a template several times with different
parameters, each distinct set of parameters will get its own customised
version of the template code.

This allows for maximum optimisation, as each individual instantiation has
all of its parameters fixed at compile time. But it does result in code
bloat relative to languages which generate one set of code which handles
polymorphism by accepting parameters at run time.

The designer of the template may be able to minimise bloat by identifying
large sections of code which are only weakly dependent upon the
parameters. E.g. there could be portions of code which only care about the
type's size, and generating different versions for different sizes would
have negligible benefit (particularly on a system with a fast multiply).
So the template code could delegate such tasks to a non-template helper
function which takes the size as a (run-time) parameter.

Unfortunately, this isn't particularly straightforward for container
templates, as core operations such as copy, move, assign, swap, etc may
have to use the relevant type-specific methods or overloads, and using
indirect calls for such primitive operations would hurt performance badly.

So if you want to go down that route, you have to manually "dissect" the
parameters using type traits such as is_trivial or is_trivially_copyable
etc in order to delegate to less-specialised templates where possible
while retaining full specialisation where necessary (or where the
alternatives are impractical).

[toc] | [prev] | [next] | [standalone]

#18821

"Paul Rubin" <no.email@nospam.invalid> wrote in message 
news:7x4mv1tdyv.fsf@ruckus.brouhaha.com...
> "tim....." <tims_new_home@yahoo.co.uk> writes:
>> My C++ experience is limited to the embedded environment and I'm up to
>> speed on creating OO class structures but not much else.  I don't do
>> standard library stiff (just like I don't carry the C library manual
>> around in my head), streams or containers.  These things don't seem to
>> have much place low level embedded code, but if you believe different
>> fell free to explain why
>
> If you mean STL containers, yes they are useful in all but the smallest
> environments and (to a limited extent) even in those.

define "useful"

the syntax is awful - completely unintelligible to someone who has never 
seen it before (and sometimes even if you have)

and for what:

to save me writing a discrete function to perform the task

> They will do
> stuff like automatic resizing

Do you mean between types.  In a small embedded system who cares?  I'm going 
to be using bools, 8 bit bytes and 16 or 32 bit words.  Occasionally I might 
need floating point arithmetic for precision, but I'm (almost) never going 
to need to "output" those, I don't have the means to do so.

> and range checking

big deal

>, and they allow you to
> use containers of multiple types without having to paste code all over
> the place.  OO on the other hand has become somewhat unfashionable in
> C++.

but I won't have enough types for this to be a problem

> I think it's sufficient to just get a recent C++ book as STL is not
> really hard to use.

No it's not hard to use, but it is like 1000 discrete facts long.  And the 
tests always ask you about the most obscure ones.

I have sufficient knowledge in my head to use the C library without looking 
at the book in my day job.  But whenever I've done C tests they always pick 
on a function that you have used once (or never)

> cppreference.com is also pretty good.  And if it
> was an online test you took, unless it said otherwise I'd think it was
> ok to use reference materials while taking the test.

at 2 minutes per question you don't have enough time for more that a cursory 
glance

tim




 

[toc] | [prev] | [next] | [standalone]

#18834

"tim....." <tims_new_home@yahoo.co.uk> writes:
>> [ STL containers ]
> the syntax is awful - completely unintelligible to someone who has
> never seen it before (and sometimes even if you have)

It seemed pretty natural to me. std::vector<float> is a vector of
floats.  std::vector<int> is a vector of ints, and so on.  

> and for what: to save me writing a discrete function to perform the
> task

Well yeah, you get tested, standardized implementations of a bunch of
datatypes that occur over and over in real world programs.  Who wants to
write a new function, debug it, maintain it, make others maintain it,
figure out and maintain the implementations of such functions written by
others, stop groaning after finding there are dozens of implementations
of essentially the same function in any large codebase, etc.  Imagine
the C library didn't standardize printf, so everyone wrote their own
function for printing numbers in decimal.  Yeah you could, but it gets
in your way at more levels than you might expect.

>> They will do stuff like automatic resizing
> Do you mean between types.  

No, I mean the STL vector class will let you grow the vector, like:
  std::vector<int> v;  // v is now an empty vector
  v.push_back(3);      // v now contains the element 3
  v.push_back(4);      // v now has two elements (3 and 4)

> In a small embedded system who cares?  I'm going to be using bools, 8
> bit bytes and 16 or 32 bit words.

In very small systems (less than 4k of ram, say), yes you probably do
want static allocation.  In these days embedded programming encompasses
those very small systems (8 bitters, Cortex M0) at one end where C is
workable.  Then there's a midrange (ARM Cortex M3, say) where C++ and
the STL bring benefits.  And finally there's systems with embedded Linux
or equivalent, which is not much different from desktop programming and
where C++ itself is too low level for lots of apps (I've programmed
these systems in Python and have been interested in using Erlang on
them).  Tiny systems are a niche even in embedded software now.

>> and range checking
> big deal

Given the amount of bugs in real code caused by subscript errors, range
checking is a good thing too.

>>, and they allow you to use containers of multiple
> but I won't have enough types for this to be a problem

Look up "typeful programming" and start using more types.  It will
decrease your debugging time :).

>> STL is not really hard to use.
> No it's not hard to use, but it is like 1000 discrete facts long.  And
> the tests always ask you about the most obscure ones.

I've found cppreference.com to have enough info to use STL effectively.

> at 2 minutes per question you don't have enough time for more that a
> cursory glance

In that case they're trying to check your experience level.

[toc] | [prev] | [next] | [standalone]

#18843

On 20/10/14 01:00, Paul Rubin wrote:
> Well yeah, you get tested, standardized implementations of a bunch of
> datatypes that occur over and over in real world programs.  Who wants to
> write a new function, debug it, maintain it, make others maintain it,
> figure out and maintain the implementations of such functions written by
> others, stop groaning after finding there are dozens of implementations
> of essentially the same function in any large codebase, etc.  Imagine
> the C library didn't standardize printf, so everyone wrote their own
> function for printing numbers in decimal.  Yeah you could, but it gets
> in your way at more levels than you might expect.

I'm out of date. Does C now have a standard "string" that everybody uses?

[toc] | [prev] | [next] | [standalone]

#18846

"Tom Gardner" <spamjunk@blueyonder.co.uk> wrote in message 
news:Y831w.377569$wn1.80788@fx18.am4...
> On 20/10/14 01:00, Paul Rubin wrote:
>> Well yeah, you get tested, standardized implementations of a bunch of
>> datatypes that occur over and over in real world programs.  Who wants to
>> write a new function, debug it, maintain it, make others maintain it,
>> figure out and maintain the implementations of such functions written by
>> others, stop groaning after finding there are dozens of implementations
>> of essentially the same function in any large codebase, etc.  Imagine
>> the C library didn't standardize printf, so everyone wrote their own
>> function for printing numbers in decimal.  Yeah you could, but it gets
>> in your way at more levels than you might expect.
>
> I'm out of date. Does C now have a standard "string" that everybody uses?
>

char *

tim

 

[toc] | [prev] | [next] | [standalone]

#18848

On 20/10/14 11:57, tim..... wrote:
>
> "Tom Gardner" <spamjunk@blueyonder.co.uk> wrote in message news:Y831w.377569$wn1.80788@fx18.am4...
>> On 20/10/14 01:00, Paul Rubin wrote:
>>> Well yeah, you get tested, standardized implementations of a bunch of
>>> datatypes that occur over and over in real world programs.  Who wants to
>>> write a new function, debug it, maintain it, make others maintain it,
>>> figure out and maintain the implementations of such functions written by
>>> others, stop groaning after finding there are dozens of implementations
>>> of essentially the same function in any large codebase, etc.  Imagine
>>> the C library didn't standardize printf, so everyone wrote their own
>>> function for printing numbers in decimal.  Yeah you could, but it gets
>>> in your way at more levels than you might expect.
>>
>> I'm out of date. Does C now have a standard "string" that everybody uses?
>>
>
> char *

Given the number of things built on top of that primitive,
I'll interpret that as an implicit "no" :)

[toc] | [prev] | [next] | [standalone]

#18855

On Mon, 20 Oct 2014 11:57:08 +0100, "tim....."
<tims_new_home@yahoo.co.uk> wrote:

>
>"Tom Gardner" <spamjunk@blueyonder.co.uk> wrote in message 
>news:Y831w.377569$wn1.80788@fx18.am4...
>> On 20/10/14 01:00, Paul Rubin wrote:
>>> Well yeah, you get tested, standardized implementations of a bunch of
>>> datatypes that occur over and over in real world programs.  Who wants to
>>> write a new function, debug it, maintain it, make others maintain it,
>>> figure out and maintain the implementations of such functions written by
>>> others, stop groaning after finding there are dozens of implementations
>>> of essentially the same function in any large codebase, etc.  Imagine
>>> the C library didn't standardize printf, so everyone wrote their own
>>> function for printing numbers in decimal.  Yeah you could, but it gets
>>> in your way at more levels than you might expect.
>>
>> I'm out of date. Does C now have a standard "string" that everybody uses?
>>
>
>char *
>
>tim

C character string support is as brain dead as FORTRAN IV character
support :-), completely relying on libraries and 3A4 style FORMAT
statements.

Fortran 5 is of course usable.

[toc] | [prev] | [next] | [standalone]

#18860

On 2014-10-20, upsidedown@downunder.com <upsidedown@downunder.com> wrote:
>
> C character string support is as brain dead as FORTRAN IV character
> support :-), completely relying on libraries and 3A4 style FORMAT
> statements.
>

On the plus side, at least C doesn't have Hollerith constants. :-)

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[toc] | [prev] | [next] | [standalone]

#18844

On 20/10/14 01:00, Paul Rubin wrote:
> Look up "typeful programming" and start using more types.  It will
> decrease your debugging time :).

Including integration time, plus acceptance/handover time!

[toc] | [prev] | [next] | [standalone]

#18845

"Paul Rubin" <no.email@nospam.invalid> wrote in message 
news:7xoat7hape.fsf@ruckus.brouhaha.com...
> "tim....." <tims_new_home@yahoo.co.uk> writes:
>>> [ STL containers ]
>> the syntax is awful - completely unintelligible to someone who has
>> never seen it before (and sometimes even if you have)
>
> It seemed pretty natural to me. std::vector<float> is a vector of
> floats.  std::vector<int> is a vector of ints, and so on.

try putting that in a loop "For first, to last, step next"

compare with:

for (i=1; i< sizeof(array); i++)
    array[i]...

It's unintelligible to someone who hasn't seen it before (as I will admit is 
the C version, but the set who have seen it before is 100 times bigger)



.
>
>>> and range checking
>> big deal
>
> Given the amount of bugs in real code caused by subscript errors, range
> checking is a good thing too.

No,  I mean,

big deal that it save me from typing:

if (i < sixzeof(arrayname))

>>>, and they allow you to use containers of multiple
>> but I won't have enough types for this to be a problem
>
> Look up "typeful programming" and start using more types.  It will
> decrease your debugging time :).

will it?

do you really think that type mismatches is the bulk of my debugging a real 
time program.

You don't think that they are swamped 100 fold by event synchronisation 
problems?

>>> STL is not really hard to use.
>> No it's not hard to use, but it is like 1000 discrete facts long.  And
>> the tests always ask you about the most obscure ones.
>
> I've found cppreference.com to have enough info to use STL effectively.
>
>> at 2 minutes per question you don't have enough time for more that a
>> cursory glance
>
> In that case they're trying to check your experience level.

except that IME of working on genuine projects, ability at C++ programming 
in real world use does not correlate with whether you know all the new 
features of the latest standard.

I've worked with so really good people who coded entirely to the 99 version

OTOH, I've recently worked with someone who could (more or less) quote you 
the complete set of additions in the '11 standard (and explain why they were 
there).  Yet he was CFU when it came to actually coding a solution to a 
problem

your choice

tim



 

[toc] | [prev] | [next] | [standalone]

#18824

Paul Rubin wrote:
> "tim....." <tims_new_home@yahoo.co.uk> writes:
>>My C++ experience is limited to the embedded environment and I'm up to
>>speed on creating OO class structures but not much else.  I don't do
>>standard library stiff (just like I don't carry the C library manual
>>around in my head), streams or containers.  These things don't seem to
>>have much place low level embedded code, but if you believe different
>>fell free to explain why
> 
> If you mean STL containers, yes they are useful in all but the smallest
> environments and (to a limited extent) even in those.  They will do
> stuff like automatic resizing and range checking, and they allow you to
> use containers of multiple types without having to paste code all over
> the place.

The problem is that they do that automatic resizing out of your control.
If you really got plenty of memory, and can heavily over-allocate, this
will not be a problem. But in a high-availability system I don't want to
run against a wall after 48 hours of uptime due to memory fragmentation.
Being able to statically allocate my memory is a good thing in such an
environment.

To me, that's the main difference between desktop and embedded software:
if desktop software crashes, you always have an operator who can restart
it or maybe add another memory module.

> OO on the other hand has become somewhat unfashionable in C++.

OO is still a very convenient way to group things together.

Just because you can do everything with abstract interfaces and
factories doesn't mean you have to. Java doesn't have much extra cost
for doing that (because calling a class method is expensive anyway), so
people do it all the time. In C++, a class wrapping two ints can be as
efficient as having just these two ints, without a pile of virtual
methods in the way.


  Stefan

[toc] | [prev] | [next] | [standalone]

#18835

Stefan Reuther <stefan.news@arcor.de> writes:
> The problem is that they do that automatic resizing out of your control.
> If you really got plenty of memory, and can heavily over-allocate, this
> will not be a problem. But in a high-availability system I don't want to
> run against a wall after 48 hours of uptime due to memory fragmentation.
> Being able to statically allocate my memory is a good thing in such an
> environment.

Yes, sure, this is fine.  Of course there's an STL container class
(std::array) for statically allocated arrays too.

> To me, that's the main difference between desktop and embedded software:
> if desktop software crashes, you always have an operator who can restart
> it or maybe add another memory module.

Yes of course, if you're in the niche of programming critical systems
that have to run nonstop with no backup, then that has to affect your
coding technique.  More typical embedded products have reliability
requirements comparable to conventional desktop or server software, so
you can use much less expensive development processes and incorporate
something like a watchdog timer onto the board, to do an automatic hard
reset in the event that something jams.  Of course you can only do that
if the worst consequence of an unexpected reset is annoyance rather than
disaster.  But that encompasses an awful lot of products.

>> OO on the other hand has become somewhat unfashionable in C++.
> OO is still a very convenient way to group things together.

OO in this context means designing programs around inheritance trees
rather than values and composition.  Of course classes are essential in
C++, but the current preference is to handle polymorphism with template
generics rather than subclasses and inheritance.

[toc] | [prev] | [next] | [standalone]

#18811

tim..... <tims_new_home@yahoo.co.uk> wrote:
 
(snip)

> A few weeks ago I was put forward for a job requiring:
 
> extensive low level embedded experience in writing code in resourced limited 
> environments, specifically ARM Cortex chipsets (tick, tick, tick)
 
> The project turned out to be a "bionic" watch - no not one that turn into a 
> human being, one that monitors your biometrics.
 
> I though "great that sound really me", and then they revealed we are a 
> hardcode C++ shop (because some of their other products are advantaged by 
> that) and you're going to have to do an online test.
 
> My C++ experience is limited to the embedded environment and I'm up to speed 
> on creating OO class structures but not much else.  I don't do standard 
> library stiff (just like I don't carry the C library manual around in my 
> head), streams or containers.  These things don't seem to have much place 
> low level embedded code, but if you believe different fell free to explain 
> why

I probably believe that when doing a programming test that you should
either have access to library documentation, or problems should not
need it. Others might disagree, though.
 
> And guess what, the test was 80% on these types on things and 
> predictably, I failed.

> Looks like they are going to get the employee (well freelancer) 
> that they deserve

There are way too many stories about interviewing in general 
having unreasonably expectations.  Not that the people aren't 
good enough, but that the problems don't test the right thing.

-- glen

[toc] | [prev] | [next] | [standalone]

#18822

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message 
news:m1urhr$v12$1@speranza.aioe.org...
> tim..... <tims_new_home@yahoo.co.uk> wrote:
>
> (snip)
>


>> And guess what, the test was 80% on these types on things and
>> predictably, I failed.
>
>> Looks like they are going to get the employee (well freelancer)
>> that they deserve
>
> There are way too many stories about interviewing in general
> having unreasonably expectations.  Not that the people aren't
> good enough, but that the problems don't test the right thing.

Oh I know, but I just thought that this case the tested skill set was so 
unnecessarily far away from the original job spec, that it deserved an 
airing.

AIH the job that I am currently on hit a few roadblocks and I didn't became 
available when I thought I would, so I never would have been able to take 
the job - and, despite the interesting application and otherwise excellent 
match to my skill-set,  I was lukewarm in the first place as I wasn't sure 
that I wanted the 1.5 hour commute on the train into the city each day 
(driving to that location would take even longer!), so I wasn't overly 
disappointed to have failed!

tim



 

[toc] | [prev] | [next] | [standalone]

#18663

On 15/10/14 19:21, Wouter van Ooijen wrote:
> "Small-chip programmers are better off using C++ instead of C."
>
> Take small-chip as =<256 Kb Flash and <32 kB RAM, down to the smallest
> micro-controller you can think of.
>
> A student of me is looking for reasons that are put forward for
> preferring C over C++ on small chips. (Note: all reasons, not just
> *valid* reasons).
>
> So far he found
>
> - tooling & experience (no C++ available for my chip, no C++ experience)
>

I'd split that into two reasons, as they are very different issues.

> - semantic distance to the machine code (I can't easily see what code
> this C++ construct will cause)
>
> - C++ stronger typing gets in the way (forces you to write lots of casts)
>
> - the const trap (ultimately you might/will need to cast the cost away)
>
> - errors are harder to locate
>
> Can you suggest more reasons, or sources (pages, articles, books, etc)
> that mention such reason?
>
> PS I am (in the context of this question) NOT interested in
>
> - purely emotionally rants (like: C++ sucks, C rocks)
>
> - whether a reason is valid (please start a different thread for
> discussing this, I'll surely join in).
>
> Wouter van Ooijen


(Before anyone replies here, remember what Wouter asked for - reasons 
without regard to validity!  Some of these here are commonly-believed FUD.)


How about:

C lets you write spaghetti code which is hard to understand, C++ lets 
you write lasagne code which is even worse.

Exceptions are just undocumented gotos.

All other embedded code, such as RTOS's or network stacks, is written in 
C - so you can't work in pure C++.

Templates cause code bloat.

The STL causes code bloat.

Objects in C++ use the heap, and dynamic memory on a small system is bad.

Objects means everything involves at least one pointer (*this), which is 
inefficient on small cpus.

Templates make code unreadable and undebuggable.

You can't use advanced C features, such as VLA's and designated 
initialisers, in C++.

Coding standards insist on ANSI C.




Some quotations from Bjarne Stroustrup might help too 
(<http://en.wikiquote.org/wiki/Bjarne_Stroustrup>) :

Within C++, there is a much smaller and cleaner language struggling to 
get out.

C makes it easy to shoot yourself in the foot; C++ makes it harder, but 
when you do it blows your whole leg off.

[toc] | [prev] | [next] | [standalone]

#18668

David Brown schreef op 15-Oct-14 10:12 PM:
> On 15/10/14 19:21, Wouter van Ooijen wrote:
>> "Small-chip programmers are better off using C++ instead of C."
>>
>> Take small-chip as =<256 Kb Flash and <32 kB RAM, down to the smallest
>> micro-controller you can think of.
>>
>> A student of me is looking for reasons that are put forward for
>> preferring C over C++ on small chips. (Note: all reasons, not just
>> *valid* reasons).
>>
>> So far he found
>>
>> - tooling & experience (no C++ available for my chip, no C++ experience)
>>
>
> I'd split that into two reasons, as they are very different issues.

True. I lumped them together because the both have nothing to do with 
the language itself. Availablility of libraries (other than the standrad 
libraries) could be added here.

>
>> - semantic distance to the machine code (I can't easily see what code
>> this C++ construct will cause)
>>
>> - C++ stronger typing gets in the way (forces you to write lots of casts)
>>
>> - the const trap (ultimately you might/will need to cast the cost away)
>>
>> - errors are harder to locate
>>
>> Can you suggest more reasons, or sources (pages, articles, books, etc)
>> that mention such reason?
>>
>> PS I am (in the context of this question) NOT interested in
>>
>> - purely emotionally rants (like: C++ sucks, C rocks)
>>
>> - whether a reason is valid (please start a different thread for
>> discussing this, I'll surely join in).
>>
>> Wouter van Ooijen
>
>
> (Before anyone replies here, remember what Wouter asked for - reasons
> without regard to validity!  Some of these here are commonly-believed FUD.)
>
>
> How about:
>
> C lets you write spaghetti code which is hard to understand, C++ lets
> you write lasagne code which is even worse.
>
> Exceptions are just undocumented gotos.
>
> All other embedded code, such as RTOS's or network stacks, is written in
> C - so you can't work in pure C++.
>
> Templates cause code bloat.
>
> The STL causes code bloat.
>
> Objects in C++ use the heap, and dynamic memory on a small system is bad.
>
> Objects means everything involves at least one pointer (*this), which is
> inefficient on small cpus.
>
> Templates make code unreadable and undebuggable.
>
> You can't use advanced C features, such as VLA's and designated
> initialisers, in C++.
>
> Coding standards insist on ANSI C.
>
> Some quotations from Bjarne Stroustrup might help too
> (<http://en.wikiquote.org/wiki/Bjarne_Stroustrup>) :
>
> Within C++, there is a much smaller and cleaner language struggling to
> get out.
>
> C makes it easy to shoot yourself in the foot; C++ makes it harder, but
> when you do it blows your whole leg off.
>

I think you fully understand what I am asking for! Although some of your 
quotes fall under "purely emotionally rants", they still represent 
reasons for some persons not to use C++. I strust my student will have 
plenty of material.

Wouter

[toc] | [prev] | [next] | [standalone]

#18670

Wouter van Ooijen <wouter@voti.nl> writes:
> I think you fully understand what I am asking for! Although some of
> your quotes fall under "purely emotionally rants", they still
> represent reasons for some persons not to use C++. I strust my student
> will have plenty of material.

C++ vs C is such a flame war because C++ really does solve some of C's
problems, but on the other hand it introduces its own problems, so there
are partisans on both sides.  Stepping back, both are terrible, and the
only reason to use C is the highly mature toolchains, availability of
programmers, existing API's that expect it, and tons of legacy code.

Unfortunately it's hard to see good alternatives that got any traction.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.arch.embedded

csiph-web