reasons for preferring C over C++

"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



 

"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

 

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" :)

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.

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