f



when to use C and when to use C++

Hi everyone,

  I have been asked this question quite a few times and i wonder what
could the actual reason?

 " When to prefer C over C++ or vice versa, of course this is for real
world pratical scenario"

    As per my understanding, C++ makes it easier to program application
related logic as OOPS helps in that sense, but for some reason that is
not a reasonable explanation, could any one add on their comments?

0
sam_cit (405)
11/13/2006 5:15:17 AM
comp.lang.c 30657 articles. 5 followers. spinoza1111 (3246) is leader. Post Follow

102 Replies
1467 Views

Similar Articles

[PageSpeed] 35

sam_cit@yahoo.co.in wrote:
> Hi everyone,
> 
>   I have been asked this question quite a few times and i wonder what
> could the actual reason?
> 
>  " When to prefer C over C++ or vice versa, of course this is for real
> world pratical scenario"

Usually the reason for the question is that some asshole wants to start 
a flame war.

>     As per my understanding, C++ makes it easier to program application
> related logic as OOPS helps in that sense, but for some reason that is
> not a reasonable explanation, could any one add on their comments?

Of course it is not a reasonable explanation for the question not an 
adequate answer for it.  It is at best a prejudice, at worst a lie.


0
mambuhl (2203)
11/13/2006 5:53:29 AM
sam_cit@yahoo.co.in a �crit :
> Hi everyone,
> 
>   I have been asked this question quite a few times and i wonder what
> could the actual reason?
> 
>  " When to prefer C over C++ or vice versa, of course this is for real
> world pratical scenario"
> 
>     As per my understanding, C++ makes it easier to program application
> related logic as OOPS helps in that sense, but for some reason that is
> not a reasonable explanation, could any one add on their comments?
> 

The problem  of C++ is that it is an extremely complex language. People
that have invested a lot of time in mastering its complexity are
productive with it, people that do not want to bother may use C.

Using C coupled with a garbage collector makes many of the features
of C++ unnecessary since memory management, one of the principal reasons
for constructors/destructors disappears from view.

A problem with C is that the language is severly crippled by the absence
of any high level library for data structures like the STL. This is not
a problem with the language itself but with the people that organize the
discussion and evolution of C. The standards comitee denies any progress
to the language and apparently they have decided that no new standard
will appear in the next 10 years or so, since there will be no C 2009
and the next standard will (maybe) appear in 2019...

This means in practice that lists, arrays and many other commonly used
data structures are absent from the C standard library. It means too
that you have to use some external library, tying your code to it,
what many people will not want to do, so they start endlessly coding
their 1000th linked list package.

This group is part of the problem of C. As you can see from the answer
of Mr Ambuhl above, it is full of people that think insults are the
only answer to people that want to discuss anything more serious than:

<begin quote >
Hi people

	I have coded:
	i++ = (i++ + i++);

and it doesnt't work... PLEEZE HELP
< end quote>

In general, disucssions concerning the evolution of C are destroyed
systematically by a group of people called "regulars" that have
taken as granted that *their* view of C (frozen about 1989) is the
only view that can be defended in this group.

So, since comp.std.c has the same view, there is effectively no
discussion group, and no discussion of the evolution of C at all.

When to use C?

You can use C anywhere, you can code anything with it, it is a general
purpose language. Its advantages are its simplicity, and its 
disadvantages are its simplicity.

jacob

0
jacob (2541)
11/13/2006 6:48:36 AM
jacob navia wrote:
> 
> Using C coupled with a garbage collector makes many of the features
> of C++ unnecessary since memory management, one of the principal reasons
> for constructors/destructors disappears from view.
> 
I don't intend to be drawn into yet another pointless GC debate but this
falls short of the truth.  Memory is but one of the many resources that
can be managed through objects with constructors and destructors, that's
why the idiom is called "Resource Acquisition Is Initialization".

-- 
Ian Collins.
0
ian-news (10155)
11/13/2006 7:03:27 AM
Ian Collins a �crit :
> jacob navia wrote:
> 
>>Using C coupled with a garbage collector makes many of the features
>>of C++ unnecessary since memory management, one of the principal reasons
>>for constructors/destructors disappears from view.
>>
> 
> I don't intend to be drawn into yet another pointless GC debate but this
> falls short of the truth.  Memory is but one of the many resources that
> can be managed through objects with constructors and destructors, that's
> why the idiom is called "Resource Acquisition Is Initialization".
> 

I said "*one of* " the principal reasons.
0
jacob (2541)
11/13/2006 7:21:31 AM
Ian Collins said:

> jacob navia wrote:
>> 
>> Using C coupled with a garbage collector makes many of the features
>> of C++ unnecessary since memory management, one of the principal reasons
>> for constructors/destructors disappears from view.
>> 
> I don't intend to be drawn into yet another pointless GC debate but this
> falls short of the truth.

The OP asked for comments, and Jacob provided one. The OP did *not* ask only 
for accurate comments from knowledgeable people.

-- 
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not 
adjust your email clients.
0
invalid171 (7008)
11/13/2006 7:27:27 AM
On Mon, 13 Nov 2006 07:48:36 +0100, jacob navia
<jacob@jacob.remcomp.fr> wrote:
>A problem with C is that the language is severly crippled by the absence
>of any high level library for data structures like the STL. This is not
>a problem with the language itself but with the people that organize the
>discussion and evolution of C. The standards comitee denies any progress
>to the language and apparently they have decided that no new standard
>will appear in the next 10 years or so, since there will be no C 2009
>and the next standard will (maybe) appear in 2019...

Interestingly the development of D was spurred by missing C facilities
and to overcome C++ complexities.



Andreas
-------
1 + 1 = 3, for large values of 1.
0
akk (192)
11/13/2006 7:47:14 AM
sam_cit@yahoo.co.in wrote:
> Hi everyone,
>
>   I have been asked this question quite a few times and i wonder what
> could the actual reason?
>
>  " When to prefer C over C++ or vice versa, of course this is for real
> world pratical scenario"
>
>     As per my understanding, C++ makes it easier to program application
> related logic as OOPS helps in that sense, but for some reason that is
> not a reasonable explanation, could any one add on their comments?

Use C when it's appropriate.  If you are writing a program
in C++, you may end up writing a lot of low-level routines
that are perfectly valid C.  If at that time you recognize that
you are writing C, it increases the flexibility of your code
if you compile those sections as C and create a C library,
and then use them from C++, since they will also
be useable from C applications.

Some people argue that C++ makes it easier to program,
but this is often because they lack sufficient knowledge
of how to apply object-oriented programming techniques
in their C-code.  In my (limited experience), C++ tends to
encourage difficult to maintain, hideous crap that is
just annoying to read.

The STL is an extremely nice feature of C++, but it
is often horribly inefficient.  The data structures are
designed to be flexible and generic, and as a result
they are not the perfect match for any programming
situation.  When you code in C or C++, one of
the primary reasons for that language choice is
speed...so why kill yourself on the performance side
by using overly generic data structures?

I will freely acknowledge that I have a strong bias
against C++.  I think I've met 3 people who write C++
code that doesn't make me vomit.  Several C++
coders I know have expressed such amazing
ignorance of C as claiming that the -> operator
is not a part of the C language and an apparent
ignorance of the 'struct' keyword.  (Which is to say
that one person actually said 'That's C++, C doesn't
have the arrow operator', and the abundance of
code that fails to use structures makes me believe
these people are just friggin' clueless.)

Most of the 'nice' feature of C++ are syntactic
sugar (introspection, operator overloading, automatic
constructors/destructors).  The try/catch clause is
nice, but leads to sloppy programming.  Namespaces
are nice, but lead to sloppy build environments.  The
STL is nice, but is usually not the best choice.

In summary, use C when it is appropriate,
and use C++ never.

--
Bill Pursell

0
bill.pursell (771)
11/13/2006 7:58:46 AM
Bill Pursell wrote:
> 
> The STL is an extremely nice feature of C++, but it
> is often horribly inefficient.

Sorry, FUD.

> The data structures are
> designed to be flexible and generic, and as a result
> they are not the perfect match for any programming
> situation.  When you code in C or C++, one of
> the primary reasons for that language choice is
> speed...so why kill yourself on the performance side
> by using overly generic data structures?
> 
What's overly generic about a vector?

> I will freely acknowledge that I have a strong bias
> against C++.  

Fair enough, but please don't spread misinformation.

-- 
Ian Collins.
0
ian-news (10155)
11/13/2006 8:21:41 AM
Bill Pursell said:

<snip>
 
> Use C when it's appropriate.

Better advice would be "use the *most* appropriate tool for the job". The 
choice of "most appropriate tool" depends on the job, the tools available, 
the various (and often conflicting) requirements of efficiency, 
portability, ease of maintenance, development time constraints, and 
familiarity. It would (probably) be very unwise to write a C program to 
process a business transaction, however easy that might be for you, if the 
other 10,000,000 lines of the suite are written in COBOL, because most of 
the available maintenance expertise is going to be in COBOL, not C. But if 
you're starting a new project and picking a brand new team (or going it 
alone), you might well look at Python and Perl and so on for your text 
processing application, and then think to yourself, "sheesh, I'd be much 
happier writing this in C, simply because I know C so much better, so I'd 
find it easier to write, easier to read, easier to debug..."

> If you are writing a program
> in C++, you may end up writing a lot of low-level routines
> that are perfectly valid C.  If at that time you recognize that
> you are writing C, it increases the flexibility of your code
> if you compile those sections as C and create a C library,
> and then use them from C++, since they will also
> be useable from C applications.

Agreed.

> Some people argue that C++ makes it easier to program,

I, on the other hand, would argue that sticking with what you know makes it 
easier to program in the short term. That isn't necessarily the best 
choice, though.

Just the other day, I found myself about 20 lines into a C program, when I 
thought, "hmmm, to do *this*, I'm going to need to do *that*, which means 
I'll have to write some routines to do *the other*, and by the time I've 
done *that*, I'll have implemented about half the STL - so why not just use 
C++ and save myself a lot of time?" So I did.

> but this is often because they lack sufficient knowledge
> of how to apply object-oriented programming techniques
> in their C-code.  In my (limited experience), C++ tends to
> encourage difficult to maintain, hideous crap that is
> just annoying to read.

Then I suggest you spend a little time developing your ability to write 
easily maintainable, non-hideous, jewels of C++ that are a delight to read. 
It isn't easy! But it is certainly possible.

> The STL is an extremely nice feature of C++, but it
> is often horribly inefficient.

I agree, but often it doesn't matter, because "horribly inefficient" is a 
relative term. When I use the STL, I am sacrificing a certain amount of 
performance in favour of ease of writing, ease of reading, and ease of 
maintenance. If I can save myself 40 hours of development time and end up 
with a program which runs in 10 seconds using STL, when my own hand-written 
C routines might be able to perform the same task in 8 seconds, then I'm 
likely to jump at the chance *unless* those extra 2 seconds become a 
significant part of the equation. Let's simplify matters, and assume I'm 
the only person who will ever run the program. If so, then my payoff for 
using C comes only when I run the program for the 72001st time(!). If, on 
the other hand, I have many users lined up for the program, then the 
equation changes. Even then, it might be worth writing the C++ version 
simply to get the users up and running, and then re-writing it in C if and 
only if I start to get a lot of complaints about performance.

> The data structures are
> designed to be flexible and generic, and as a result
> they are not the perfect match for any programming
> situation.  When you code in C or C++, one of
> the primary reasons for that language choice is
> speed...so why kill yourself on the performance side
> by using overly generic data structures?

Because "killing yourself" isn't the only choice. C++'s "overly generic" 
data structures are nevertheless no slouches at performance. Yes, maybe you 
can beat them with customised routines, but those customised routines take 
time to write and get right. If the payoff is worth it, by all means do so, 
but don't just *assume* that the payoff will be worth it.

> I will freely acknowledge that I have a strong bias
> against C++.

So do I. It's only my *second* favourite language.

> I think I've met 3 people who write C++
> code that doesn't make me vomit.

I suggest that you consult a doctor. :-)

> Several C++
> coders I know have expressed such amazing
> ignorance of C as [...]

Well, we can't blame the language for its users!

<snip>

> In summary, use C when it is appropriate,
> and use C++ never.

....except when it is appropriate. Or, better still, use the best tool for 
the job.

-- 
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not 
adjust your email clients.
0
invalid171 (7008)
11/13/2006 8:47:18 AM
Martin Ambuhl a �crit :
> sam_cit@yahoo.co.in wrote:
> 
>> Hi everyone,
>>
>>   I have been asked this question quite a few times and i wonder what
>> could the actual reason?
>>
>>  " When to prefer C over C++ or vice versa, of course this is for real
>> world pratical scenario"
> 
> 
> Usually the reason for the question is that some asshole wants to start 
> a flame war.

Translation:
"I want to kill any discussion that goes beyond homework level".

The easiest way is to insult anyone that posts an interesting question
that *could* lead to an interesting discussion.

comp.lang.c is just for questions like this

Hi people

I wrote
	i++ = i++ + i++
and it doesn't work...

PLEEZE HELP


0
jacob (2541)
11/13/2006 8:55:55 AM
Richard Heathfield a �crit :
> Ian Collins said:
> 
> 
>>jacob navia wrote:
>>
>>>Using C coupled with a garbage collector makes many of the features
>>>of C++ unnecessary since memory management, one of the principal reasons
>>>for constructors/destructors disappears from view.
>>>
>>
>>I don't intend to be drawn into yet another pointless GC debate but this
>>falls short of the truth.
> 
> 
> The OP asked for comments, and Jacob provided one. The OP did *not* ask only 
> for accurate comments from knowledgeable people.
> 

No, he did not.

And you are sure the appointed expert in what I know
and what I do not know.

0
jacob (2541)
11/13/2006 8:57:26 AM
sam_cit@yahoo.co.in wrote:
> Hi everyone,
>
>   I have been asked this question quite a few times and i wonder what
> could the actual reason?
>
>  " When to prefer C over C++ or vice versa, of course this is for real
> world pratical scenario"

I  tend to use C++ at work, where development speed is crucial (ie. you
don't really care about putting string terminations, you don't want to
care much about allocations of string/other objects... etc.. - sad but
true). On the other hand, when I code in my spare time, I code for
fun,so I like to think about each and every detail (as it's fun :) I
enjoy it so I don't mind to spend extra time placing null terminations,
etc...

Just my case...

0
stdazi (57)
11/13/2006 1:36:51 PM
Richard Heathfield wrote:
> Bill Pursell said:
>
> <snip>
>
> > Use C when it's appropriate.
>
> Better advice would be "use the *most* appropriate tool for the job".


Richard,
[Perhaps a little OT]

Thanks for that. I have often wondered about this myself. I started
with C as it seemed to be the underlying language in "Cocoa", (OS X).
(Problem is, that I have really begun to like C!!  Besides, I am not
sure a list as active and enjoyable as this one, exists elsewhere?)  My
next thought is do I need to then learn C++? It this question does not
make too much sense, it is because I do not yet clearly see all the
intricacies of the different programming languages.

0
mdeh (570)
11/13/2006 5:06:51 PM
mdh said:

<snip>

> (Problem is, that I have really begun to like C!!

That is not a problem, believe me. C is a very likeable language. (It is 
also a very hateable language, it seems.)

> My
> next thought is do I need to then learn C++?

Only you can answer that. (Do all programmers need to learn C++? No. Do some 
programmers need to learn C++? Yes.)

-- 
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not 
adjust your email clients.
0
invalid171 (7008)
11/13/2006 5:15:17 PM
mdh wrote:

> Thanks for that. I have often wondered about this myself. I started
> with C as it seemed to be the underlying language in "Cocoa", (OS X).

I would have expected "Objective C."
0
james
11/13/2006 5:35:41 PM

> mdh wrote:
>
> > Thanks for that. I have often wondered about this myself. I started
> > with C as it seemed to be the underlying language in "Cocoa", (OS X).
>

james of tucson wrote:
> I would have expected "Objective C."

James...not quite sure  I understand the difference between the 2. I
know  it is OT...but care to tell in a short sentence, or maybe
privately by e-mail?

0
mdeh (570)
11/13/2006 6:57:05 PM
Ian Collins wrote:
> jacob navia wrote:
>> Using C coupled with a garbage collector makes many of the features
>> of C++ unnecessary since memory management, one of the principal reasons
>> for constructors/destructors disappears from view.
>>
> I don't intend to be drawn into yet another pointless GC debate but this
> falls short of the truth.  Memory is but one of the many resources that
> can be managed through objects with constructors and destructors, that's
> why the idiom is called "Resource Acquisition Is Initialization".
> 
Note that this idiom is fairly specific to C++, with its deterministic 
finalization and peculiar exception handling mechanism (supporting either a 
"catch" or a "finally" block, but not both). Garbage-collected OO languages 
typically offer nondeterministic finalization, and the "destructor" (or 
whatever it's called) is a last, untimely resort to freeing resources, which 
otherwise have to be managed explicitly.

C with a garbage collector and exception handling would come a lot closer to 
matching C++ (for those who insist). Of course, if it's OO you're after 
you're sort of going to need classes... and then you'll want generics too 
(though not necessarily in the form of C++'s templates). Before you know it, 
you'll have C# or Java.

Which, I guess, just goes to show you that different languages have 
different uses.

S.
0
invalid58 (621)
11/13/2006 7:18:45 PM
Skarmander wrote:

> C with a garbage collector and exception handling would come a lot
> closer to matching C++ (for those who insist). 

Objective-C's manual reference counting is one compromise -- the
language is much closer to C, and adds object allocation constructs
without going as far as literally replacing the language.

I thought Objective-C was an obscurity until I started programing on
MacOSX, and discovered that it was easy for a C programmer to work with
and quite useful.
0
james
11/13/2006 7:22:17 PM
mdh wrote:
> 
>> mdh wrote:
>>
>>> Thanks for that. I have often wondered about this myself. I started
>>> with C as it seemed to be the underlying language in "Cocoa", (OS X).
> 
> james of tucson wrote:
>> I would have expected "Objective C."
> 
> James...not quite sure  I understand the difference between the 2. I
> know  it is OT...but care to tell in a short sentence, or maybe
> privately by e-mail?

Your learning C will not be a waste if and when you want to use
Objective-C, but you must be aware that they are not the same thing.

[OT]
Objective-C is essentially C, plus some SmallTalk-style objects. It is
much smaller and more dynamic than C++, but also requires more runtime
support. In addition, it is a proper superset of C (i.e. any valid C
program is also a valid Objective-C program); any additional keywords
either begin with the '@' character, or are used in a such a limited
context that they do not conflict with their C meanings (or lack thereof)

See:
http://en.wikipedia.org/wiki/Objective-C#Philosophical_differences_between_Objective-C_and_C.2B.2B

news:comp.lang.objective-c
[/OT]





-- 
Clark S. Cox III
clarkcox3@gmail.com
0
clarkcox3 (505)
11/13/2006 7:28:24 PM
Clark S. Cox III wrote:

> [OT]
> Objective-C is essentially C,.......


thanks

0
mdeh (570)
11/13/2006 8:02:40 PM
Bill Pursell wrote:
> When you code in C or C++, one of
> the primary reasons for that language choice is
> speed...so why kill yourself on the performance side
> by using overly generic data structures?

If you read comp.lang.c++ regularly, you will see
benchmarks posted from time to time, where C++ code
using those "generic" structures (eg. string handling)
actually outperforms "equivalent" C code, because those
structures also make the job of optimisation easier for
the compiler.

> Several C++ coders I know have expressed such amazing
> ignorance of C

I know several C coders who have an amazing ignorance
of Perl. C must be a dreadful language !!


> Most of the 'nice' feature of C++ are syntactic
> sugar (introspection, operator overloading, automatic
> constructors/destructors).

Automatic constructors and destructors are much more
than syntactic sugar.

> The try/catch clause is nice, but leads to sloppy programming.

Well, it's just the same as setjmp/longjmp, but easier to
work with. I notice you use the passive voice, "leads to
sloppy programming". It is up to any particular programmer
whether to write sloppy code or not, it doesn't just happen
by itself.

> Namespaces are nice, but lead to sloppy build environments. 

Huh?

0
oldwolf (2279)
11/13/2006 8:44:09 PM
sam_cit@yahoo.co.in wrote:
> Hi everyone,
>
>   I have been asked this question quite a few times and i wonder what
> could the actual reason?
>
>  " When to prefer C over C++ or vice versa, of course this is for real
> world pratical scenario"
>
>     As per my understanding, C++ makes it easier to program application
> related logic as OOPS helps in that sense, but for some reason that is
> not a reasonable explanation, could any one add on their comments?

It *really* depends on the application in question.  Some solutions
make more sense when expressed as objects, others make more sense when
expressed as procedures.  There's no hard and fast rule, and more often
than not the answer is determined by what the developers already know.
If all your guys have decades' worth of experience in C, go with C.  If
all your developers have only ever used C++, go with C++.

OOP does not magically make application programming easier; it makes
certain solutions easier to visualize, but the coding itself may be
just as involved (maybe more so!) as writing straight C.

I don't have a ton of experience with C++, but I will say that if your
problem involves heavy-duty text processing, C++ is the better choice.
The C++ string class, while not ideal, gives you more useful tools for
string manipulation than the C string library.

Some of the features that make C++ worth using (such as virtual
functions) incur some performance cost.  For a lot of general-purpose
applications programming, this cost is negligible, but if you have to
account for every CPU cycle, it may be better to go with straight C.

0
john_bode (637)
11/13/2006 8:55:14 PM
John Bode wrote:

> 
> Some of the features that make C++ worth using (such as virtual
> functions) incur some performance cost.  For a lot of general-purpose
> applications programming, this cost is negligible, but if you have to
> account for every CPU cycle, it may be better to go with straight C.
> 
Or C++ without using those features.

In the case of virtual methods, the alternatives in C tend to be either
a switch or a table of function pointers which is the common
implementation of virtual methods.  So not using them may cost more
cycles and hinder optimisation.

Profile, profile, profile!

-- 
Ian Collins.
0
ian-news (10155)
11/13/2006 9:03:03 PM
Old Wolf wrote:
> Bill Pursell wrote:
>
> > Most of the 'nice' feature of C++ are syntactic
> > sugar (introspection, operator overloading, automatic
> > constructors/destructors).
>
> Automatic constructors and destructors are much more
> than syntactic sugar.

How so?

> > The try/catch clause is nice, but leads to sloppy programming.
>
> Well, it's just the same as setjmp/longjmp, but easier to
> work with. I notice you use the passive voice, "leads to
> sloppy programming". It is up to any particular programmer
> whether to write sloppy code or not, it doesn't just happen
> by itself.

Absolutely.  My complaints about C++ are primarily
that it seems to encourage sloppy programming.  Or
perhaps it is more that I've seen many people go
down the road of "if I write in C++ then my code
will magically be beautiful, so I don't have to worry
about it".   I recognize that I'm being completely
irrational about this, but at the moment (lasting about
6 months now) I'm in a big anti-C++ mood.

> > Namespaces are nice, but lead to sloppy build environments.
>
> Huh?

This is really just a personal gripe with one particular
piece of software I had to deal with.  The namespaces
were horribly convoluted and cluttered and it was
obvious that the programmer was creating new
namespaces whenever he had a symbol name clash
rather than clarifying the design.   It led me to think
that namespaces were simply a mechanism for giving
the programmer more rope with which to hang himself.
It seems to me that being forced to keep the global
namespace uncluttered imposes more discipline on
the design, and makes you more aware of ensuring
proper linkage attributes.  I think that the concept
of namespaces is great, and I love them in Python, but
I just don't see that they buy you anything in C++.
You can accomplish the same thing by keeping
your libraries in order, and having namespaces seems
to encourage disorganized libraries and discourages
proper modularity.

--
Bill Pursell

0
bill.pursell (771)
11/13/2006 9:25:56 PM
On Mon, 13 Nov 2006 09:55:55 +0100, in comp.lang.c , jacob navia
<jacob@jacob.remcomp.fr> wrote:

>Martin Ambuhl a �crit :
>> sam_cit@yahoo.co.in wrote:
>> 
>>> Hi everyone,
>>>
>>>   I have been asked this question quite a few times and i wonder what
>>> could the actual reason?
>>>
>>>  " When to prefer C over C++ or vice versa, of course this is for real
>>> world pratical scenario"
>> 
>> 
>> Usually the reason for the question is that some asshole wants to start 
>> a flame war.
>
>Translation:
>"I want to kill any discussion that goes beyond homework level".

Translation:
"Jacob Navia likes insulting the regulars in CLC because he is a fool"

Back to Martin's comment: 
The commonest two reasons for someone asking why use C or C++ are 
a) he's a troll and wants to start a flame war and 
b) he's a student struggling with a stupid homework question.

So you see, Jacob's childish remark fits neither camp. 
-- 
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place. 
 Therefore, if you write the code as cleverly as possible, you are, 
 by definition, not smart enough to debug it."
--Brian Kernighan
0
markmcintyre (4555)
11/13/2006 9:37:30 PM
On Mon, 13 Nov 2006 08:21:31 +0100, in comp.lang.c , jacob navia
<jacob@jacob.remcomp.fr> wrote:

>Ian Collins a �crit :
>> jacob navia wrote:
>> 
>>>Using C coupled with a garbage collector makes many of the features
>>>of C++ unnecessary since memory management, one of the principal reasons
>>>for constructors/destructors disappears from view.
>>>
>> 
>> I don't intend to be drawn into yet another pointless GC debate but this
>> falls short of the truth.  Memory is but one of the many resources that
>> can be managed through objects with constructors and destructors, that's
>> why the idiom is called "Resource Acquisition Is Initialization".
>> 
>
>I said "*one of* " the principal reasons.

Which part of "I don't intend to be drawn" did you find hard to
understand? 

-- 
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place. 
 Therefore, if you write the code as cleverly as possible, you are, 
 by definition, not smart enough to debug it."
--Brian Kernighan
0
markmcintyre (4555)
11/13/2006 9:38:02 PM
Bill Pursell wrote:
> Old Wolf wrote:
> 
>>Bill Pursell wrote:
>>
>>
>>>Most of the 'nice' feature of C++ are syntactic
>>>sugar (introspection, operator overloading, automatic
>>>constructors/destructors).
>>
>>Automatic constructors and destructors are much more
>>than syntactic sugar.
> 
> 
> How so?
> 
Try implementing Resource Acquisition Is Initialization without them.

> 
>>>The try/catch clause is nice, but leads to sloppy programming.
>>
>>Well, it's just the same as setjmp/longjmp, but easier to
>>work with. I notice you use the passive voice, "leads to
>>sloppy programming". It is up to any particular programmer
>>whether to write sloppy code or not, it doesn't just happen
>>by itself.
> 
> 
> Absolutely.  My complaints about C++ are primarily
> that it seems to encourage sloppy programming. 

Process or organisations encourage sloppy programming, not the language.
 Granted C as a low level language tends to require greater discipline.

> 
>>>Namespaces are nice, but lead to sloppy build environments.
>>
>>Huh?
> 
> I think that the concept
> of namespaces is great, and I love them in Python, but
> I just don't see that they buy you anything in C++.
> You can accomplish the same thing by keeping
> your libraries in order, and having namespaces seems
> to encourage disorganized libraries and discourages
> proper modularity.
> 
I find the opposite, using namespaces helps me organise my code be
keeping things where they belong.

-- 
Ian Collins.
0
ian-news (10155)
11/13/2006 9:40:26 PM
Old Wolf wrote:
> Bill Pursell wrote:

>> The try/catch clause is nice, but leads to sloppy programming.
> 
> Well, it's just the same as setjmp/longjmp, but easier to
> work with. I notice you use the passive voice, "leads to
> sloppy programming". 

That is not the passive voice: it is active.  A passive voice 
construction might be "sloppy programming is led to."
0
mambuhl (2203)
11/13/2006 10:22:33 PM
At first I wasn't sure if I'd take part in this C Vs C++ discussion, but 
I'll dip my feet...

jacob navia:

> The problem  of C++ is that it is an extremely complex language.


That can be said, Yes. However if you ask proficient C++ programmers, 
they'll tell you they don't find it that complicated at all.


> People that have invested a lot of time in mastering its complexity are 
> productive with it, people that do not want to bother may use C.


Fair enough statement. Regulars here such as Richard Heathfield and Keith 
Thompson appear not to be reluctant to put the work in to learn a language, 
so you're argument doesn't quite explain why they favour C.

 
> Using C coupled with a garbage collector makes many of the features
> of C++ unnecessary since memory management, one of the principal reasons
> for constructors/destructors disappears from view.


Constructors, destructors, class objects, smart pointers, operator 
overloading, templates -- I myself favour C++ for a menagarie of reasons.

 
> This means in practice that lists, arrays and many other commonly used
> data structures are absent from the C standard library.


int array[5];


> You can use C anywhere, you can code anything with it, it is a general
> purpose language. Its advantages are its simplicity, and its 
> disadvantages are its simplicity.


Good points.

-- 

Frederick Gotham
0
fgothamNO (1668)
11/13/2006 10:32:54 PM
Bill Pursell:

> Use C when it's appropriate.  If you are writing a program
> in C++, you may end up writing a lot of low-level routines
> that are perfectly valid C.


I myself do, but I don't call them "low-level". Things like arrays, 
pointers and bitmasking are just as much a part of C++ as they are a part 
of C, even though many C++ programmers deny this.


> If at that time you recognize that you are writing C, it increases the
> flexibility of your code if you compile those sections as C and create a
> C library, and then use them from C++, since they will also be useable
> from C applications.


You should have seen the abuse I got when I suggested that exact thing over 
on comp.lang.c++.

 
> Some people argue that C++ makes it easier to program,
> but this is often because they lack sufficient knowledge
> of how to apply object-oriented programming techniques
> in their C-code.  In my (limited experience), C++ tends to
> encourage difficult to maintain, hideous crap that is
> just annoying to read.


Your opinion. My own differs.

 
> The STL is an extremely nice feature of C++, but it
> is often horribly inefficient.  The data structures are
> designed to be flexible and generic, and as a result
> they are not the perfect match for any programming
> situation.  When you code in C or C++, one of
> the primary reasons for that language choice is
> speed...so why kill yourself on the performance side
> by using overly generic data structures?


You'd be suprised! I could write a more efficient "memcpy" in C++ than I 
could in C.

If I were to use "memcpy" in C to copy an array of int's, I would have to 
perform the redundant check that the arrays are suitably aligned for 
optimal copying-time.

In C++, however, I could use a combination of function overloading and 
templates. For instance:

#include <cstddef>

template<class T>
void memcpy(T *to,T const *from,std::size_t const len)
{
    T const *const pover_to = to + len;

    while (pover_to != to) *to++ = *from++;     
}

 
> I will freely acknowledge that I have a strong bias
> against C++.


And I that I have a strong favouring toward it.


> I think I've met 3 people who write C++
> code that doesn't make me vomit.  Several C++
> coders I know have expressed such amazing
> ignorance of C as claiming that the -> operator
> is not a part of the C language and an apparent
> ignorance of the 'struct' keyword.  (Which is to say
> that one person actually said 'That's C++, C doesn't
> have the arrow operator', and the abundance of
> code that fails to use structures makes me believe
> these people are just friggin' clueless.)


You should meet a Java programmer : ).

 
> Most of the 'nice' feature of C++ are syntactic
> sugar (introspection, operator overloading, automatic
> constructors/destructors).  The try/catch clause is
> nice, but leads to sloppy programming.


It _can_, but a proficient programmer can write good code.


> Namespaces are nice, but lead to sloppy build environments.  The STL is
> nice, but is usually not the best choice.


I disagree with both these arguments.

 
> In summary, use C when it is appropriate,
> and use C++ never.


I agree that the appropriate language should be used whenever it is 
appropriate, however I am slightly biases as I always find C++ to be 
appropriate.

-- 

Frederick Gotham
0
fgothamNO (1668)
11/13/2006 10:42:37 PM
Frederick Gotham:

>     T const *const pover_to = to + len;

    to + len / sizeof(T)

-- 

Frederick Gotham
0
fgothamNO (1668)
11/13/2006 10:50:06 PM
Frederick Gotham wrote:
> 
> You'd be suprised! I could write a more efficient "memcpy" in C++ than I 
> could in C.
> 
> If I were to use "memcpy" in C to copy an array of int's, I would have to 
> perform the redundant check that the arrays are suitably aligned for 
> optimal copying-time.
> 
> In C++, however, I could use a combination of function overloading and 
> templates. For instance:
> 
Which wouldn't give you a more efficient memcpy().

If you wanted an optimised memcpy(), you'd probably write it in
assembly, complete with the "redundant check that the arrays are
suitably aligned" and take advantage of whatever block move instructions
your processor possessed.

You would save on typing.

> #include <cstddef>
> 
> template<class T>
> void memcpy(T *to,T const *from,std::size_t const len)
> {
>     T const *const pover_to = to + len;
> 
>     while (pover_to != to) *to++ = *from++;     
> }
> 
Far form optimal where T is char on anything other than an 8 bit machine.

-- 
Ian Collins.
0
ian-news (10155)
11/13/2006 10:57:21 PM
Frederick Gotham wrote:
> At first I wasn't sure if I'd take part in this C Vs C++ discussion, but 
> I'll dip my feet...
> 
> jacob navia:
> 
> 
  >>This means in practice that lists, arrays and many other commonly used
>>data structures are absent from the C standard library.
> 
> 
> 
> int array[5];
> 

That is an array only in very special situations... In most cases it
will "decay" into a pointer to int. The size information is destroyed
or discarded and there it goes, a buffer overflow please...

I have tried to incorporate some C++ features into the C implementation
I distribute (lcc-win32). One of the principal reasons was to have
arrays that are *really* arrays and do not "decay" into anything. Using
simple features like operator overloading, I have managed to demonstrate
that with a few extensions, C can be a high level language without the
complications of C++ and with enough expression power to code
any algorithm.

The features I have added are:

o operator overloading
o default function arguments
o references
o try/catch

And that is it.

This few features allows for an amazing power of expression,
that I have used to omplement a string library, that mimicks
the normal C string library (Strcmp, Strcat Strstr, etc) but uses
length delimited strings.

Porting from the C library to this library is quite easy, in most cases
it means just some capitalization of the C functions.

Essential for this is (again) arrays that can be accessed with
[ ] but allow for indexing with bounds checking.

Arrays, and specialy strings, are not first class object TYPES
in C, but just pointers to some "zero terminated" memory or pointers
to the first element without any size information.

That's why I added arrays to the list of objects that you have to
manage yourself in C.
0
jacob (2541)
11/13/2006 11:18:14 PM
Mark McIntyre wrote:
> On Mon, 13 Nov 2006 09:55:55 +0100, in comp.lang.c , jacob navia
> <jacob@jacob.remcomp.fr> wrote:
> 
> 
>>Martin Ambuhl a �crit :
>>
>>>sam_cit@yahoo.co.in wrote:
>>>
>>>
>>>>Hi everyone,
>>>>
>>>>  I have been asked this question quite a few times and i wonder what
>>>>could the actual reason?
>>>>
>>>> " When to prefer C over C++ or vice versa, of course this is for real
>>>>world pratical scenario"
>>>
>>>
>>>Usually the reason for the question is that some asshole wants to start 
>>>a flame war.
>>
>>Translation:
>>"I want to kill any discussion that goes beyond homework level".
> 
> 
> Translation:
> "Jacob Navia likes insulting the regulars in CLC because he is a fool"
> 
> Back to Martin's comment: 
> The commonest two reasons for someone asking why use C or C++ are 
> a) he's a troll and wants to start a flame war and 
> b) he's a student struggling with a stupid homework question.
> 
> So you see, Jacob's childish remark fits neither camp. 

What a logic. This is 100% McIntyre:

Ambuhl says:

 >>>Usually the reason for the question is that some asshole wants to
 >>> start a flame war.

I said:

 >>Translation:
 >>"I want to kill any discussion that goes beyond homework level".

and it is ME that is insulting people. Maybe because I do not treat 
anybody of asshole obviously.

Refraining from insults is considered here a reason for being
flamed as

 > "Jacob Navia likes insulting the regulars in CLC because he is a fool"

Well... this is an example of this sectarian logic. Only comprehensible
from within the sect rules, hierarchy and "reasoning".
0
jacob (2541)
11/13/2006 11:25:26 PM
jacob navia wrote:
> Frederick Gotham wrote:
> 
>> At first I wasn't sure if I'd take part in this C Vs C++ discussion,
>> but I'll dip my feet...
>>
>> jacob navia:
>>
>>
>  >>This means in practice that lists, arrays and many other commonly used
> 
>>> data structures are absent from the C standard library.
>>
>>
>>
>>
>> int array[5];
>>
> 
> That is an array only in very special situations... In most cases it
> will "decay" into a pointer to int. The size information is destroyed
> or discarded and there it goes, a buffer overflow please...
> 
This deficiency is being addressed, have a look at std::tr1::array.  Not
standard yet, but on its way.

-- 
Ian Collins.
0
ian-news (10155)
11/13/2006 11:36:50 PM
jacob navia said:

> Frederick Gotham wrote:
>> At first I wasn't sure if I'd take part in this C Vs C++ discussion, but
>> I'll dip my feet...
>> 
>> jacob navia:
>> 
>> 
>   >>This means in practice that lists, arrays and many other commonly used
>>>data structures are absent from the C standard library.
>> 
>> int array[5];
>> 
> 
> That is an array only in very special situations...

Wrong. The array is always an array, throughout its lifetime.


> In most cases it
> will "decay" into a pointer to int.

Wrong. Its name does, but it doesn't.

> The size information is destroyed
> or discarded

Wrong. The size information is available via sizeof array, and the number of 
elements in the array is available via the canonical expression:

sizeof array / sizeof array[0]

<snip>

-- 
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not 
adjust your email clients.
0
invalid171 (7008)
11/14/2006 12:32:37 AM
Ian Collins <ian-news@hotmail.com> writes:
> jacob navia wrote:
[...]
>> That is an array only in very special situations... In most cases it
>> will "decay" into a pointer to int. The size information is destroyed
>> or discarded and there it goes, a buffer overflow please...
>> 
> This deficiency is being addressed, have a look at std::tr1::array.  Not
> standard yet, but on its way.

That's C++, isn't it?  Did you perhaps momentarily forget which
newsgroup you're reading?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
We must do something.  This is something.  Therefore, we must do this.
0
kst-u (21963)
11/14/2006 5:28:39 AM
Keith Thompson wrote:
> Ian Collins <ian-news@hotmail.com> writes:
> 
>>jacob navia wrote:
> 
> [...]
> 
>>>That is an array only in very special situations... In most cases it
>>>will "decay" into a pointer to int. The size information is destroyed
>>>or discarded and there it goes, a buffer overflow please...
>>>
>>
>>This deficiency is being addressed, have a look at std::tr1::array.  Not
>>standard yet, but on its way.
> 
> 
> That's C++, isn't it?  Did you perhaps momentarily forget which
> newsgroup you're reading?
> 
Oops, I forgot to stick to the group's main topics of insults and
accusations...

It won't happen again.

-- 
Ian Collins.
0
ian-news (10155)
11/14/2006 5:56:03 AM
Ian Collins said:

> Keith Thompson wrote:
>> Ian Collins <ian-news@hotmail.com> writes:
>> 
>>>jacob navia wrote:
>> 
>> [...]
>> 
>>>>That is an array only in very special situations... In most cases it
>>>>will "decay" into a pointer to int. The size information is destroyed
>>>>or discarded and there it goes, a buffer overflow please...
>>>>
>>>
>>>This deficiency is being addressed, have a look at std::tr1::array.  Not
>>>standard yet, but on its way.
>> 
>> 
>> That's C++, isn't it?  Did you perhaps momentarily forget which
>> newsgroup you're reading?
>> 
> Oops, I forgot to stick to the group's main topics of insults and
> accusations...

How about sticking to C, at least?


-- 
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not 
adjust your email clients.
0
invalid171 (7008)
11/14/2006 7:04:31 AM
Ian Collins a �crit :
> Keith Thompson wrote:
> 
>>Ian Collins <ian-news@hotmail.com> writes:
>>
>>
>>>jacob navia wrote:
>>
>>[...]
>>
>>
>>>>That is an array only in very special situations... In most cases it
>>>>will "decay" into a pointer to int. The size information is destroyed
>>>>or discarded and there it goes, a buffer overflow please...
>>>>
>>>
>>>This deficiency is being addressed, have a look at std::tr1::array.  Not
>>>standard yet, but on its way.
>>
>>
>>That's C++, isn't it?  Did you perhaps momentarily forget which
>>newsgroup you're reading?
>>
> 
> Oops, I forgot to stick to the group's main topics of insults and
> accusations...
> 
> It won't happen again.
> 

How true!

0
jacob (2541)
11/14/2006 7:18:49 AM
Skarmander a �crit :
> Ian Collins wrote:
> 
> C with a garbage collector and exception handling would come a lot 
> closer to matching C++ (for those who insist). 
> 

I insist and I have made exactly such an implementation available

http://www.cs.virginia.edu/~lcc-win32
0
jacob (2541)
11/14/2006 7:20:58 AM
jacob navia wrote:
> Skarmander a �crit :
> 
>> Ian Collins wrote:
>>
Not me squire, I don't agree with this.  Please take greater care with
your quoting.

>> C with a garbage collector and exception handling would come a lot
>> closer to matching C++ (for those who insist).
> 
> 
> I insist and I have made exactly such an implementation available
> 
> http://www.cs.virginia.edu/~lcc-win32


-- 
Ian Collins.
0
ian-news (10155)
11/14/2006 7:31:10 AM
Richard Heathfield a �crit :
> jacob navia said:
> 
> 
>>Frederick Gotham wrote:
>>
>>>At first I wasn't sure if I'd take part in this C Vs C++ discussion, but
>>>I'll dip my feet...
>>>
>>>jacob navia:
>>>
>>>
>>
>>  >>This means in practice that lists, arrays and many other commonly used
>>
>>>>data structures are absent from the C standard library.
>>>
>>>int array[5];
>>>
>>
>>That is an array only in very special situations...
> 
> 
> Wrong. The array is always an array, throughout its lifetime.
> 
> 
> 
>>In most cases it
>>will "decay" into a pointer to int.
> 
> 
> Wrong. Its name does, but it doesn't.
> 
> 
>>The size information is destroyed
>>or discarded
> 
> 
> Wrong. The size information is available via sizeof array, and the number of 
> elements in the array is available via the canonical expression:
> 
> sizeof array / sizeof array[0]
> 
> <snip>
> 

[root@gateway tmp]# cat tarray.c
void fn(int array[8])
{
         printf("sizeof array = %d\n",sizeof(array));
}

int main(void)
{
         int array[8];

         fn(array);
}
[root@gateway tmp]# gcc tarray.c
[root@gateway tmp]# ./a.out
sizeof array = 4
[root@gateway tmp]#
0
jacob (2541)
11/14/2006 4:13:44 PM
jacob navia <jacob@jacob.remcomp.fr> wrote:

> Richard Heathfield a �crit :
> > jacob navia said:
> > 
> >>Frederick Gotham wrote:
> >>
> >>>jacob navia:
> >>
> >>  >>This means in practice that lists, arrays and many other commonly used
> >>
> >>>>data structures are absent from the C standard library.
> >>>
> >>>int array[5];

This (which is a declaration of an array)...

> >>That is an array only in very special situations...
> > 
> > Wrong. The array is always an array, throughout its lifetime.
> > 
> >>The size information is destroyed or discarded
> > 
> > Wrong. The size information is available via sizeof array, and the number of 
> > elements in the array is available via the canonical expression:
> > 
> > sizeof array / sizeof array[0]

> [root@gateway tmp]# cat tarray.c
> void fn(int array[8])

....is not at all the same as this, which is a function declaration which
includes a _pointer_ _argument_ which only looks like an array.

Richard
0
rlb (4118)
11/14/2006 4:19:22 PM
jacob navia:

> That is an array only in very special situations... In most cases it
> will "decay" into a pointer to int. The size information is destroyed
> or discarded and there it goes, a buffer overflow please...


An array can implicitly convert to a pointer to its first element.

A double can implicitly convert to an int.

I would be wrong to suggest that a double is just int because it can 
implicitly convert to one. Similarly, you can't say that an array is just a 
pointer simply because it can implicitly convert to one.

If you want to be able to pass an array to a function and still retain its 
length, then simply do:

#include <stddef.h>

void Func(T *p,size_t len);  /* Defined elsewhere */

#define FUNC(arr) (Func(arr,sizeof arr/sizeof*arr))

This would sort of be equivalent to the following C++ code:

#include <cstddef>

template<class T,std::size_t len>
void Func(T (&arr)[len]);

-- 

Frederick Gotham
0
fgothamNO (1668)
11/14/2006 4:55:46 PM
Frederick Gotham:

> #define FUNC(arr) (Func(arr,sizeof arr/sizeof*arr))


Of course, I should have parentheses around all appearances of the macro 
parameter.

-- 

Frederick Gotham
0
fgothamNO (1668)
11/14/2006 5:14:33 PM
Richard Bos a �crit :
> jacob navia <jacob@jacob.remcomp.fr> wrote:
> 
> 
>>Richard Heathfield a �crit :
>>
>>>jacob navia said:
>>>
>>>
>>>>Frederick Gotham wrote:
>>>>
>>>>
>>>>>jacob navia:
>>>>
>>>> >>This means in practice that lists, arrays and many other commonly used
>>>>
>>>>
>>>>>>data structures are absent from the C standard library.
>>>>>
>>>>>int array[5];
> 
> 
> This (which is a declaration of an array)...
> 
> 
>>>>That is an array only in very special situations...
>>>
>>>Wrong. The array is always an array, throughout its lifetime.
>>>
>>>
>>>>The size information is destroyed or discarded
>>>
>>>Wrong. The size information is available via sizeof array, and the number of 
>>>elements in the array is available via the canonical expression:
>>>
>>>sizeof array / sizeof array[0]
> 
> 
>>[root@gateway tmp]# cat tarray.c
>>void fn(int array[8])
> 
> 
> ...is not at all the same as this, which is a function declaration which
> includes a _pointer_ _argument_ which only looks like an array.
> 
> Richard

What was I saying?

int array[5]: the size information is destroyed or discarded...

Yeah, looks like an array, feel like an array, but it is not an array.
Exactly what I was saying. Besides, passing it to another function
makes all the size information that *could* have been stored there get lost.

0
jacob (2541)
11/14/2006 5:32:32 PM
Frederick Gotham a �crit :
> jacob navia:
> 
> 
>>That is an array only in very special situations... In most cases it
>>will "decay" into a pointer to int. The size information is destroyed
>>or discarded and there it goes, a buffer overflow please...
> 
> 
> 
> An array can implicitly convert to a pointer to its first element.
> 
> A double can implicitly convert to an int.

Both SCALARS. And the conversion is not "in palce". Another object
is created, that contains the transformed value!!!

> 
> I would be wrong to suggest that a double is just int because it can 
> implicitly convert to one. Similarly, you can't say that an array is just a 
> pointer simply because it can implicitly convert to one.
> 
> If you want to be able to pass an array to a function and still retain its 
> length, then simply do:
> 
> #include <stddef.h>
> 
> void Func(T *p,size_t len);  /* Defined elsewhere */
> 
> #define FUNC(arr) (Func(arr,sizeof arr/sizeof*arr))
> 
> This would sort of be equivalent to the following C++ code:
> 
> #include <cstddef>
> 
> template<class T,std::size_t len>
> void Func(T (&arr)[len]);


All this would be unnecessary if I could declare:

int fn(int array[253]);

and have the expected semantics.

0
jacob (2541)
11/14/2006 5:35:25 PM
jacob navia said:

>>>>>>int array[5];
>> 
<snip>
> 
> What was I saying?
> 
> int array[5]:

The original, as you can see above, was not int array[5]: but int array[5]; 
and that means it was /not/ a parameter definition, but an ordinary array 
definition.

If you want to talk about parameter definitions, fine, let's talk about 
those, but they aren't arrays, so they're not relevant to your point, such 
as it was.

-- 
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not 
adjust your email clients.
0
invalid171 (7008)
11/14/2006 5:45:19 PM
jacob navia said:

<snip>
 
> All this would be unnecessary if I could declare:
> 
> int fn(int array[253]);
> 
> and have the expected semantics.

For those who have read K&R2, the expected semantics is "pointer to an int" 
- and that's exactly what you get.

-- 
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not 
adjust your email clients.
0
invalid171 (7008)
11/14/2006 5:47:08 PM
Richard Heathfield wrote:
> jacob navia said:
> 
> <snip>
>  
> 
>>All this would be unnecessary if I could declare:
>>
>>int fn(int array[253]);
>>
>>and have the expected semantics.
> 
> 
> For those who have read K&R2, the expected semantics is "pointer to an int" 
> - and that's exactly what you get.
> 

The expected semantics are that sizeof(array) is 253*sizeof(int).
Obviously C has a different opinion about this, what I find is a
big problem for the language. Arrays are not first class objects.


0
jacob (2541)
11/14/2006 6:21:02 PM
jacob navia:

> The expected semantics are that sizeof(array) is 253*sizeof(int).
> Obviously C has a different opinion about this, what I find is a
> big problem for the language. Arrays are not first class objects.


Let's say that there's a country called Malingua. In Malingua, they 
manufacture cars. These cars are just like the cars we have all over the 
world, except that their accelerator and break pedals are switched.

What are the expected semantics of pressing the left pedal? Well that depends 
entirely on how ignorant you are. There's the correct answer, and then 
there's the incorrect answer which you hold to be true on account of your 
ignorance.

To say, in this context, that the expected semantics for "sizeof array" is to 
be equal to "253*sizeof(int)", is an expectation whose foundation is 
ignorance.

Now, since _when_ can we make arguments based upon ignorance? Applying sizeof 
to a pointer type yields the size of the pointer. Applying sizeof to an array 
type yields the size of the array. If you don't like it, then tough -- but 
don't use ignorance as an excuse to imply fault in the C programming 
language.

-- 

Frederick Gotham
0
fgothamNO (1668)
11/14/2006 6:28:58 PM
Frederick Gotham wrote:
> jacob navia:
> 
> 
>>The expected semantics are that sizeof(array) is 253*sizeof(int).
>>Obviously C has a different opinion about this, what I find is a
>>big problem for the language. Arrays are not first class objects.
> 
> 
> 
> Let's say that there's a country called Malingua. In Malingua, they 
> manufacture cars. These cars are just like the cars we have all over the 
> world, except that their accelerator and break pedals are switched.
> 
> What are the expected semantics of pressing the left pedal? Well that depends 
> entirely on how ignorant you are. There's the correct answer, and then 
> there's the incorrect answer which you hold to be true on account of your 
> ignorance.
> 
> To say, in this context, that the expected semantics for "sizeof array" is to 
> be equal to "253*sizeof(int)", is an expectation whose foundation is 
> ignorance.
> 
> Now, since _when_ can we make arguments based upon ignorance? Applying sizeof 
> to a pointer type yields the size of the pointer. Applying sizeof to an array 
> type yields the size of the array. If you don't like it, then tough -- but 
> don't use ignorance as an excuse to imply fault in the C programming 
> language.
> 

This is obvious. If I do not like some feature of the language, I am
an ignorant since I should know that "C is like that".

OK.

Be it
0
jacob (2541)
11/14/2006 6:53:38 PM
Frederick Gotham wrote:
> jacob navia:
> 
>> The expected semantics are that sizeof(array) is 253*sizeof(int).
>> Obviously C has a different opinion about this, what I find is a
>> big problem for the language. Arrays are not first class objects.
> 
> 
> Let's say that there's a country called Malingua. In Malingua, they 
> manufacture cars. These cars are just like the cars we have all over the 
> world, except that their accelerator and break pedals are switched.
> 
> What are the expected semantics of pressing the left pedal? Well that depends 
> entirely on how ignorant you are. There's the correct answer, and then 
> there's the incorrect answer which you hold to be true on account of your 
> ignorance.
> 
> To say, in this context, that the expected semantics for "sizeof array" is to 
> be equal to "253*sizeof(int)", is an expectation whose foundation is 
> ignorance.
> 
> Now, since _when_ can we make arguments based upon ignorance? Applying sizeof 
> to a pointer type yields the size of the pointer. Applying sizeof to an array 
> type yields the size of the array. If you don't like it, then tough -- but 
> don't use ignorance as an excuse to imply fault in the C programming 
> language.
> 
No, let's go one step further. In Malingua, they have objects which 
outwardly resemble cars. However, if you get into one, you find out that 
they're actually showers. You can't drive them; they just happen to have 
car-shaped enclosures.

If you're surprised by this, don't be: it's your own fault for assuming that 
things that look like cars in Malingua are cars. If you don't like it, then 
tough -- but don't use ignorance as an excuse to imply fault in Malingua's 
culture.

Your point (that the semantics of a language are dictated, and match our 
expectations only when they happen to do so) is well taken. It is, however, 
disingenuous to pretend that therefore, a language can be designed in 
whatever way we please and no-one can fault it for having syntax or 
semantics that mislead a programmer's casual instincts. Whether you agree 
with the criticism is one thing, but simply dismissing it as invalid is silly.

If programming were just a programmer reading the language standard and 
henceforth magicking programs out of the void with the assimilated 
knowledge, there would be no need to evaluate language design decisions. 
However, it's not.

S.
0
invalid58 (621)
11/14/2006 6:54:12 PM
On Tue, 14 Nov 2006 00:18:14 +0100, in comp.lang.c , jacob navia
<jacob@jacob.remcomp.fr> wrote:

>Frederick Gotham wrote:
>> int array[5];
>
>That is an array only in very special situations... In most cases it
>will "decay" into a pointer to int. 

Actually the wrong way round. Its a pointer in very special
situations, vis when you pass it as an argument to a function. 

>The size information is destroyed
>or discarded and there it goes, a buffer overflow please...

The overflow or otherwise is a flaw of programme design and/or coding
mistake.  Other languages also allow equally stupid programming
mistakes. If this were not so, then surely they'd have taken over the
world already.

-- 
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place. 
 Therefore, if you write the code as cleverly as possible, you are, 
 by definition, not smart enough to debug it."
--Brian Kernighan
0
markmcintyre (4555)
11/14/2006 6:55:35 PM
On Tue, 14 Nov 2006 18:32:32 +0100, in comp.lang.c , jacob navia
<jacob@jacob.remcomp.fr> wrote:

>Richard Bos a �crit :
>>
>> ...is not at all the same as this, which is a function declaration which
>> includes a _pointer_ _argument_ which only looks like an array.
>> 
>int array[5]: the size information is destroyed or discarded...

You fundamentally misunderstand whats going on here. Naturally, if you
convert it to something else, its not what it was any more. 

>Yeah, looks like an array, feel like an array, but it is not an array.

In what way is int array[8] not an array? 
-- 
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place. 
 Therefore, if you write the code as cleverly as possible, you are, 
 by definition, not smart enough to debug it."
--Brian Kernighan
0
markmcintyre (4555)
11/14/2006 6:57:51 PM
On Tue, 14 Nov 2006 00:25:26 +0100, in comp.lang.c , jacob navia
<jacob@jacob.remcomp.fr> wrote:

>Mark McIntyre wrote:
>> On Mon, 13 Nov 2006 09:55:55 +0100, in comp.lang.c , jacob navia
>> <jacob@jacob.remcomp.fr> wrote:
>
>What a logic. This is 100% McIntyre:

When will you realise that insulting the regulars and being a dickhead
is not going to impress anyone? You behave like a teenager on a
hormone trip trying desperately to drink and pull simultaneously, and
rarely has a sigblock been more appropriate.

-- 
Mark McIntyre

"The lusers I know are so clueless, that if they were dipped in clue
 musk and dropped in the middle of pack of horny clues, on clue prom
 night during clue happy hour, they still couldn't get a clue."
--Michael Girdwood, in the monastery
0
markmcintyre (4555)
11/14/2006 7:01:49 PM
Skarmander:

> No, let's go one step further. In Malingua, they have objects which 
> outwardly resemble cars. However, if you get into one, you find out that
> they're actually showers. You can't drive them; they just happen to have
> car-shaped enclosures.


OK, I'm with you so far...

 
> If you're surprised by this, don't be: it's your own fault for assuming
> that things that look like cars in Malingua are cars. If you don't like
> it, then tough -- but don't use ignorance as an excuse to imply fault in
> Malingua's culture.


Indeed, as a Westerner, I might find it quite strange that Malingua's 
showers look like cars.

What can I do about it? Well, before travelling to Malingua, I can say, 
"OK, I going to disregard everything I learned in Ireland, and I'm going to 
start afresh in Malingua without making any presumptions as to how things 
work."

Is this a viable choice? No, not when talking about going to a different 
country.

However, we're talking about a programming language. When you're learning a 
new programming language, you can't really build on past experience. You 
need to confirm and clarify everything.

The simple fact of the matter is that you have to be in the know when it 
comes to a programming language. Some people may presume that you can pass 
an array by value, but alas they're wrong. Was their intuition flawed to 
think they could simply write:

void Func(int arr[5]) {}

Maybe, maybe not. At the end of the day though, the C Standard is the C 
Standard. You can either come to terms with the fact (however much you 
dislike it) that Malingua's showers look like cars, or you can rant on 
about how backwards Malingua is.

This reminds me of the argument posed recently whereby the following was 
deemed to be bad style:

    SomeAggregateType obj = {0};

in place of:

    SomeAggregateType obj;
    memset(&obj,0,sizeof obj);

(Let's forget for the moment that the latter form is only guaranteed to 
work with integer types.)

The argument posed was that the former form wasn't explicit enough, i.e. 
that the programmer wasn't expected to know that all the members/elements 
would be default-initialised.

This, in my own humble opinion, is BS. The semantics of the former form are 
perfectly well defined by the Standard, and that's good enough for me. One 
shouldn't censor one's code because they think a particular feature might 
be a little too advanced for some people.

The only compromise I would accept is the following:

    SomeAggregateType obj = {0};  /* Everything ges default value */

I find it quite odd that a programmer would choose a flawed construct over 
a simple comment. We have comments, use them if you like.


> Your point (that the semantics of a language are dictated, and match our
> expectations only when they happen to do so) is well taken. It is,
> however, disingenuous to pretend that therefore, a language can be
> designed in whatever way we please and no-one can fault it for having
> syntax or semantics that mislead a programmer's casual instincts.


Yes, we can agree (slightly) on this one. Maybe C should have disallowed 
the following:

void Func(int arr[5]) {}


> Whether you agree with the criticism is one thing, but simply dismissing
> it as invalid is silly.


It is the implication of a flaw in C that I was dismissing.

 
> If programming were just a programmer reading the language standard and 
> henceforth magicking programs out of the void with the assimilated 
> knowledge, there would be no need to evaluate language design decisions.
> However, it's not.


Oh but a boy can dream...

-- 

Frederick Gotham
0
fgothamNO (1668)
11/14/2006 7:10:48 PM
Mark McIntyre:

<snip tripe>

While I disagree with quite a few of the points Jacob makes, I still think he 
comes across as a nice, reasonable person. I've nothing bad to say about him.

I cannot the same for you.

-- 

Frederick Gotham
0
fgothamNO (1668)
11/14/2006 7:12:47 PM
Mark McIntyre:

> In what way is int array[8] not an array? 

In the following context:

void Func(int array[8])
{
    sizeof array;
}

int main(void) { return 0; }

-- 

Frederick Gotham
0
fgothamNO (1668)
11/14/2006 7:14:19 PM
jacob navia said:

> Richard Heathfield wrote:
>> jacob navia said:
>> 
>> <snip>
>>  
>> 
>>>All this would be unnecessary if I could declare:
>>>
>>>int fn(int array[253]);
>>>
>>>and have the expected semantics.
>> 
>> 
>> For those who have read K&R2, the expected semantics is "pointer to an
>> int" - and that's exactly what you get.
>> 
> 
> The expected semantics are that sizeof(array) is 253*sizeof(int).

Not to anyone who has read K&R2 or any decent C reference book, nor to 
anyone sufficiently competent in C to write or maintain a C compiler 
properly. Presumably that includes you.

-- 
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not 
adjust your email clients.
0
invalid171 (7008)
11/14/2006 7:31:12 PM
Richard Heathfield:

> Not to anyone who has read K&R2 or any decent C reference book, nor to 
> anyone sufficiently competent in C to write or maintain a C compiler 
> properly. Presumably that includes you.


Seeing as how Jacob is fully aware that an array cannot be passed by value, 
I think he is arguing that C should be more intuitive, i.e. that you should 
be able to figure stuff out by yourself without having to consult a book. 
It's debateable how far this view can be taken.

The following snippet a load of cod's wallop in my opinion; I don't know 
why C ever allowed the presence of the redundant array dimension in there:

    void Func(int array[8]) {}

It looks, sounds, smells like an array, but it's a pointer. At least with 
the following snippet, you know things aren't quite straight-forward:

    void Func(int array[]) {}

, but again, it's debateable as to whether array syntax should have been 
allowed at all. I myself always opt for the pointer syntax, i.e.:

    void Func(char **p) {}

instead of:

    void Func(char *p[]) {}

It's more honest in my opinion.

-- 

Frederick Gotham
0
fgothamNO (1668)
11/14/2006 7:50:13 PM
jacob navia <jacob@jacob.remcomp.fr> writes:
> Richard Heathfield wrote:
>> jacob navia said:
>> <snip>
>>
>>>All this would be unnecessary if I could declare:
>>>
>>>int fn(int array[253]);
>>>
>>>and have the expected semantics.
>> For those who have read K&R2, the expected semantics is "pointer to
>> an int" - and that's exactly what you get.
>
> The expected semantics are that sizeof(array) is 253*sizeof(int).

No, the *expected* semantics are that sizeof array == sizeof(int*), at
least to anyone who understands that particular aspect of the C
language.  I would certainly expect anyone who works on a C compiler
to understand that, and I'm sure you do.  I think that rather than
"expected semantics", you really mean "desired semantics", i.e., the
semantics that *you* want.

> Obviously C has a different opinion about this, what I find is a
> big problem for the language. Arrays are not first class objects.

This is not a matter of opinion, it's a matter of definition.

I'm not sure what "first class objects" are, but I certainly agree
that array types are not first class types in C.  That's just the way
it is.

The fact that "int array[235]" in a parameter declaration really means
"int *array" is, in my opinion, an annoyance.  The fact that the 235
is silently ignored is particularly counterintuitive.  I dislike this
particular feature of C.  Having said that, I move on and deal with
the language as it is, and I rarely use that particular feature (I'd
just declare the parameter as "int *array").

If your point is that C is imperfect, I don't think anyone is going to
disagree with you.  If your point is that this particular imperfection
makes the language useless, this is refuted by the fact that plenty of
people actually use it.

It would be nice if array types were more nearly first-class in C, but
I don't believe it's possible to make that happen without breaking
existing code.  If you can manage to design such a language change,
I'll be very impressed.

If you want first-class arrays, use a different language, and discuss
it in a different newsgroup.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
We must do something.  This is something.  Therefore, we must do this.
0
kst-u (21963)
11/14/2006 9:19:18 PM
jacob navia <jacob@jacob.remcomp.fr> writes:
> Frederick Gotham wrote:
[...]
>> To say, in this context, that the expected semantics for "sizeof
>> array" is to be equal to "253*sizeof(int)", is an expectation whose
>> foundation is ignorance.
>> Now, since _when_ can we make arguments based upon ignorance?
>> Applying sizeof to a pointer type yields the size of the
>> pointer. Applying sizeof to an array type yields the size of the
>> array. If you don't like it, then tough -- but don't use ignorance
>> as an excuse to imply fault in the C programming language.
>
> This is obvious. If I do not like some feature of the language, I am
> an ignorant since I should know that "C is like that".

jacob, please make up your mind about what you're trying to say.

If you do not like some feature of the language, that's perfectly
fine.  I don't like that particular feature myself.

Context: we're talking about a parameter declaration, something like:

    void func(int array[253]);

The phrase "expected semantics" implies, at least to me and I think to
most of us, that you *expect* "sizeof array", evaluated inside func,
to yield 253*sizeof(int).  It doesn't, and the standard is perfectly
clear on that point.  I'm sure your own lcc-win32 handles this in
accordance with the C standard.

If you're trying to say that you'd *prefer* "sizeof array" to yield
253*sizeof(int), that's perfectly reasonable, but it's not what you've
been saying.  The word "expected" implies a belief about what the
expression actually does yield, not a desire for it to behave
differently than it really does.

I wonder if this is partly a language problem (French vs. English).

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
We must do something.  This is something.  Therefore, we must do this.
0
kst-u (21963)
11/14/2006 9:29:15 PM
Keith Thompson wrote:
> jacob navia <jacob@jacob.remcomp.fr> writes:
> 
>>Frederick Gotham wrote:
> 
> [...]
> 
>>>To say, in this context, that the expected semantics for "sizeof
>>>array" is to be equal to "253*sizeof(int)", is an expectation whose
>>>foundation is ignorance.
>>>Now, since _when_ can we make arguments based upon ignorance?
>>>Applying sizeof to a pointer type yields the size of the
>>>pointer. Applying sizeof to an array type yields the size of the
>>>array. If you don't like it, then tough -- but don't use ignorance
>>>as an excuse to imply fault in the C programming language.
>>
>>This is obvious. If I do not like some feature of the language, I am
>>an ignorant since I should know that "C is like that".
> 
> 
> jacob, please make up your mind about what you're trying to say.
> 
> If you do not like some feature of the language, that's perfectly
> fine.  I don't like that particular feature myself.
> 
> Context: we're talking about a parameter declaration, something like:
> 
>     void func(int array[253]);
> 
> The phrase "expected semantics" implies, at least to me and I think to
> most of us, that you *expect* "sizeof array", evaluated inside func,
> to yield 253*sizeof(int).  It doesn't, and the standard is perfectly
> clear on that point.  I'm sure your own lcc-win32 handles this in
> accordance with the C standard.
> 
> If you're trying to say that you'd *prefer* "sizeof array" to yield
> 253*sizeof(int), that's perfectly reasonable, but it's not what you've
> been saying.  The word "expected" implies a belief about what the
> expression actually does yield, not a desire for it to behave
> differently than it really does.
> 
> I wonder if this is partly a language problem (French vs. English).
> 

Yes, I meant obviously that it should be 253*sizeof(int)...

I KNOW that the standard says otherwise and I have implemented it like
that and I have used it like that for the 20+ years I have been
programming in C, but still, after all this time, I think it is
a mistake. Arrays should KEEP its size information so that it can
be checked at run-time, and sizeof() should be a run-time function
that  returns the stored size...

BUT

It would mean quite a lot of changes to the language.
0
jacob (2541)
11/14/2006 9:45:34 PM
Mark McIntyre <markmcintyre@spamcop.net> writes:
> On Tue, 14 Nov 2006 00:18:14 +0100, in comp.lang.c , jacob navia
> <jacob@jacob.remcomp.fr> wrote:
>
>>Frederick Gotham wrote:
>>> int array[5];
>>
>>That is an array only in very special situations... In most cases it
>>will "decay" into a pointer to int. 
>
> Actually the wrong way round. Its a pointer in very special
> situations, vis when you pass it as an argument to a function. 
[...]

The implicit conversion of an array expression to a pointer value has
nothing to do with function arguments.  A function argument merely
happens to be one of the many contexts in which the conversion take
place.  For example, given:

    void func(int *p);
    int foo[10];
    ...

    func(foo);

the expression "foo" is converted to a pointer value, but *not*
because it's being passed to a function.

There are two rules to remember:

1. An expression of array type is implicitly converted to a pointer to
   the array's first element *unless* the expression is the operand of
   a unary "&" or "sizeof" operator, or is a string literal used to
   initialize an array.  (C99 6.3.2.1p3).

2. A parameter declaration of an array type is adjusted to a pointer
   type.  This is not a conversion; in a parameter declaration,
   "int array[5]" really *means* "int *array".  (C99 6.7.5.3p7)

If you look at the history of the language, these two rules exist for
similar reasons, but they're really completely independent of each
other; neither follows from the other.

People often try to re-state these rules in other terms.  The result
is almost always either needlessly complex or needlessly imprecise.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
We must do something.  This is something.  Therefore, we must do this.
0
kst-u (21963)
11/14/2006 9:46:15 PM
Frederick Gotham wrote:
> Mark McIntyre:
> 
> 
>>In what way is int array[8] not an array? 
> 
> 
> In the following context:
> 
> void Func(int array[8])
> {
>     sizeof array;
> }
> 
> int main(void) { return 0; }
> 
Yes, that's precisely my point.

Arrays become just pointers, and any size information
must be passed to the function in an extra parameter
by the programmer, with all the associated error possibilities.

jacob
0
jacob (2541)
11/14/2006 9:48:11 PM
Mark McIntyre wrote:
>> Martin Ambuhl a �crit :
>>> Usually the reason for the question is that some asshole wants to
>>> start a flame war.

Well, at least you guys have managed to start a flame war about flame wars.

-- 
Martijn
http://www.sereneconcepts.nl
http://blogger.xs4all.nl/mihaak/


0
11/14/2006 9:56:03 PM
Martijn wrote:
> Mark McIntyre wrote:
> 
>>>Martin Ambuhl a �crit :
>>>
>>>>Usually the reason for the question is that some asshole wants to
>>>>start a flame war.
> 
> 
> Well, at least you guys have managed to start a flame war about flame wars.
> 
!!!!!!!!!!!!!!!!!!!

:-)
0
jacob (2541)
11/14/2006 9:59:21 PM
Frederick Gotham wrote:
> Skarmander:
> 
>> No, let's go one step further. In Malingua, they have objects which 
>> outwardly resemble cars. However, if you get into one, you find out that
>> they're actually showers. You can't drive them; they just happen to have
>> car-shaped enclosures.
> 
> 
> OK, I'm with you so far...
> 
>  
>> If you're surprised by this, don't be: it's your own fault for assuming
>> that things that look like cars in Malingua are cars. If you don't like
>> it, then tough -- but don't use ignorance as an excuse to imply fault in
>> Malingua's culture.
> 
> 
> Indeed, as a Westerner, I might find it quite strange that Malingua's 
> showers look like cars.
> 
But here, of course, the analogy breaks down readily: Malingua, as we 
presume it to exist, isn't man-made, and isn't meant to serve a purpose. And 
even then, Malinguans familiar with cars may concede that it doesn't make a 
whole lot of sense to them either.

> What can I do about it? Well, before travelling to Malingua, I can say, 
> "OK, I going to disregard everything I learned in Ireland, and I'm going to 
> start afresh in Malingua without making any presumptions as to how things 
> work."
> 
That is humanly impossible. Only computers can work without presumptions, 
and that only because they cannot presume in the first place.

> Is this a viable choice? No, not when talking about going to a different 
> country.
> 
OK, I'm with you so far. :-)

> However, we're talking about a programming language. When you're learning a 
> new programming language, you can't really build on past experience. You 
> need to confirm and clarify everything.
> 
Says who? The language? No. So what, then? Experience? Sure. Experience 
tells us we cannot rely on our previous experience, but you see how that 
only goes so far.

If I read

    c = a + b;

it is not possible and not helpful for me to pretend that these are 
meaningless symbols barring an explicit definition in a language standard 
somewhere that will explain to me what exactly this sequence of symbols 
means, if anything.

For sure, the language standard *is* the only authority on it. I cannot 
*rely* on my assumptions about the statement's semantics, and a good many 
may be wrong. I cannot with any definite justification shout "that's wrong" 
if it shouldn't match my expectation. However, if "c = a + b;" turned out to 
mean "perform a low-level format of all attached disk drives", I would have 
reason to complain nonetheless, however formally precise and consistent the 
definition might be.

> The simple fact of the matter is that you have to be in the know when it 
> comes to a programming language. Some people may presume that you can pass 
> an array by value, but alas they're wrong. Was their intuition flawed to 
> think they could simply write:
> 
> void Func(int arr[5]) {}
> 
> Maybe, maybe not. 

As long as we're willing to concede the possibility, that's enough. It's not 
a black and white issue, and that's my point. "It's standard C so there's no 
point criticizing it for what it isn't" is a reasonable attitude for writing 
programs (indeed, the only reasonable attitude), but not when the point 
precisely is criticism of C's design.

Is the intuition flawed? Consider this: in C, everything that can be passed 
  is passed by value, but arrays cannot be passed as values. This is not 
reflected in the most intuitive attempt at doing it, since that is not an 
error, but instead implements quite different semantics.

There are two separate issues here. First, should C have included passing 
arrays by value? There are obvious and understandable reasons why it does 
not (though whether they are sufficiently good reasons is a completely 
different matter, which I will not go into here). Second, since C does not 
include passing arrays by value, should it have included the syntax form 
that it does, with the semantics that has? The latter decision is much 
harder to defend.

> At the end of the day though, the C Standard is the C 
> Standard. You can either come to terms with the fact (however much you 
> dislike it) that Malingua's showers look like cars, or you can rant on 
> about how backwards Malingua is.
> 
Or, indeed, you can do both. Nobody said coming to terms meant keeping your 
peace hereafter. What would become of activism? :-)

> This reminds me of the argument posed recently whereby the following was 
> deemed to be bad style:
> 
Style is a lot murkier than even intuition.

>     SomeAggregateType obj = {0};
> 
> in place of:
> 
>     SomeAggregateType obj;
>     memset(&obj,0,sizeof obj);
> 
> (Let's forget for the moment that the latter form is only guaranteed to 
> work with integer types.)
> 
> The argument posed was that the former form wasn't explicit enough, i.e. 
> that the programmer wasn't expected to know that all the members/elements 
> would be default-initialised.
> 
> This, in my own humble opinion, is BS. The semantics of the former form are 
> perfectly well defined by the Standard, and that's good enough for me. One 
> shouldn't censor one's code because they think a particular feature might 
> be a little too advanced for some people.
> 
There are no clear insights on how intuition works, so these matters remain 
thoroughly debatable. However, in my opinion, this is still quite a bit 
removed from the opinion that it's counterintuitive that

    void func(int arr[5]) {
	...

does not declare 'arr' to be a parameter of type "array of five ints", and 
that indeed what looks like a dimension is actually meaningless.

Both these things rely on intuition, and both can be chalked up to 
inappropriate extrapolation: you thought it meant one thing based on what 
you saw earlier, but you were wrong. How obviously jarring you might find 
either is subjective, of course, but I do think most people would agree that 
confusion about passing arrays is more "natural" than confusion about struct 
initializers.

>> Whether you agree with the criticism is one thing, but simply dismissing
>> it as invalid is silly.
> 
> It is the implication of a flaw in C that I was dismissing.
> 
It *is* a flaw in C. The syntax is confusing, and pointlessly so. The 
language would be better if it did not include this particular syntax form 
at all, and if array parameters looked as what they are: pointers.

Of course, the question of whether arrays should be first-class citizens 
instead (which would be an alternate way of solving the problem) is a whole 
'nother bag of beans, as it involves a lot more arguments and being a lot 
more explicit about design goals.

And, obviously, now that the language is what it is there is no sense in 
arguing that it should be different, as the mass of existing code is now a 
very strong argument against. But then, that's not the argument in question 
either.

S.
0
invalid58 (621)
11/14/2006 10:05:28 PM
jacob navia:

> Arrays become just pointers, and any size information
> must be passed to the function in an extra parameter
> by the programmer, with all the associated error possibilities.


While I agree with the meaning, I don't agree with your language. An array 
doesn't "just become" a pointer any more than a double "just becomes" an int. 
It's an implicit conversion.

-- 

Frederick Gotham
0
fgothamNO (1668)
11/14/2006 10:06:34 PM
jacob navia:

> It would mean quite a lot of changes to the language.


And we'd probably end up with something like C++...

-- 

Frederick Gotham
0
fgothamNO (1668)
11/14/2006 10:08:01 PM
Frederick Gotham <fgothamNO@SPAM.com> writes:
> jacob navia:
>
>> It would mean quite a lot of changes to the language.
>
>
> And we'd probably end up with something like C++...

C++ has the same array/pointer conversion rules as C (though it also
has STL vectors and so forth).

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
We must do something.  This is something.  Therefore, we must do this.
0
kst-u (21963)
11/14/2006 11:00:03 PM
jacob navia wrote:
> Frederick Gotham wrote:
>> Mark McIntyre:
>>
>>>In what way is int array[8] not an array?
>>
>> In the following context:
>>
>> void Func(int array[8])
>> {
>>     sizeof array;
>> }
>>
>> int main(void) { return 0; }
>
> Yes, that's precisely my point.
> 
> Arrays become just pointers, and any size information
> must be passed to the function in an extra parameter
> by the programmer, with all the associated error possibilities.

Not necessarily.  You can always create a completely passable array
by embedding it in a struct.  In fact, by using the "struct hack"
or C99 open arrays you can even make those variable length.

typedef struct vlgharr {
   size_t   maxsize;
   char     arrproper[1];
} vlgharr, *pvlgharr;

pvlgharr vlacreate(size_t sz) {
   pvlgharr  pv;
   size_t    needed;

   if (!sz) return NULL;
   needed = offsetof(arrproper, vlgharr) + sz;
   if (pv = malloc(needed)) pv->maxsize = sz;
   return pv;
} /* untested */

and you can now pass either pv or *pv as function parameters.  You
should probably create a corresponding "vladestroy(pvlgharr pv);"
function.

-- 
Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>


0
cbfalconer (19194)
11/14/2006 11:15:05 PM
Skarmander wrote:
> 
.... snip ...
>
> It *is* a flaw in C. The syntax is confusing, and pointlessly so. The
> language would be better if it did not include this particular syntax
> form at all, and if array parameters looked as what they are: pointers.

So all you have to do is write your function prototypes to specify
pointers, rather than the confusing array format.  It's your own
fault.

-- 
Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>

0
cbfalconer (19194)
11/14/2006 11:19:05 PM
CBFalconer <cbfalconer@yahoo.com> writes:

> jacob navia wrote:
>> Frederick Gotham wrote:
>>> Mark McIntyre:
>>>
>>>>In what way is int array[8] not an array?
>>>
>>> In the following context:
>>>
>>> void Func(int array[8])
>>> {
>>>     sizeof array;
>>> }
>>>
>>> int main(void) { return 0; }
>>
>> Yes, that's precisely my point.
>> 
>> Arrays become just pointers, and any size information
>> must be passed to the function in an extra parameter
>> by the programmer, with all the associated error possibilities.
>
> Not necessarily.  You can always create a completely passable array
> by embedding it in a struct.  In fact, by using the "struct hack"
> or C99 open arrays you can even make those variable length.
>
> typedef struct vlgharr {
>    size_t   maxsize;
>    char     arrproper[1];
> } vlgharr, *pvlgharr;
>
> pvlgharr vlacreate(size_t sz) {
>    pvlgharr  pv;
>    size_t    needed;
>
>    if (!sz) return NULL;
>    needed = offsetof(arrproper, vlgharr) + sz;
>    if (pv = malloc(needed)) pv->maxsize = sz;
>    return pv;
> } /* untested */
>
> and you can now pass either pv or *pv as function parameters.  You
> should probably create a corresponding "vladestroy(pvlgharr pv);"
> function.

Well I am sure I'll shot down in flames, but that really surprises
me.  Passing pv, OK (setting aside the legality of the hack in the
first place) but I can't see how most implementations have a hope of
passing *pv correctly.

C99 regularised this by giving the implementation a way to know the
object's size. 

-- 
Ben.
0
ben.usenet (6790)
11/14/2006 11:46:40 PM
2006-11-14 <455A4DF9.FF826562@yahoo.com>,
CBFalconer wrote:
> jacob navia wrote:
>> Frederick Gotham wrote:
>>> Mark McIntyre:
>>>
>>>>In what way is int array[8] not an array?
>>>
>>> In the following context:
>>>
>>> void Func(int array[8])
>>> {
>>>     sizeof array;
>>> }
>>>
>>> int main(void) { return 0; }
>>
>> Yes, that's precisely my point.
>> 
>> Arrays become just pointers, and any size information
>> must be passed to the function in an extra parameter
>> by the programmer, with all the associated error possibilities.
>
> Not necessarily.  You can always create a completely passable array
> by embedding it in a struct.  In fact, by using the "struct hack"
> or C99 open arrays you can even make those variable length.

Doing this precludes passing the "whole" struct by value. You can only 
pass up to the single element that is actually declared for arrproper[], 
and possibly by accident a bit extra that's present as padding.

I have no idea what "variably modified types" are or whether they are 
useful for getting around this.

I have no idea what happens if you pass a struct with a flexible array 
member in c99. probably an error message.
0
random21 (344)
11/15/2006 12:12:34 AM
Frederick Gotham said:

<snip>

> it's debateable as to whether array syntax should have been
> allowed at all.

As a matter of fact, I agree with you (with regard to function parameters) - 
but it's historical baggage from the days when [] actually /did/ mean 
"pointer", and historical baggage tends to decay into tradition.

-- 
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not 
adjust your email clients.
0
invalid171 (7008)
11/15/2006 12:48:03 AM
Frederick Gotham said:

> jacob navia:
> 
>> It would mean quite a lot of changes to the language.
> 
> 
> And we'd probably end up with something like C++...

....and we already have C++, if we want it. It's over there somewhere. So 
there's no need to change C to be like it. Otherwise we'd have two C++s, 
which would be silly.

-- 
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not 
adjust your email clients.
0
invalid171 (7008)
11/15/2006 12:53:38 AM
In article <1163394917.621118.303120@k70g2000cwa.googlegroups.com>, 
sam_cit@yahoo.co.in writes
>Hi everyone,
>
>  I have been asked this question quite a few times and i wonder what
>could the actual reason?
>
> " When to prefer C over C++ or vice versa, of course this is for real
>world pratical scenario"
>
>    As per my understanding, C++ makes it easier to program application
>related logic as OOPS helps in that sense, but for some reason that is
>not a reasonable explanation, could any one add on their comments?
>

Some preamble...
Many regard C as a sub set of C++ this is not correct. C and C++ 
diverged in 1990.  Therefore they are subtly different in some places 
even where the syntax is the same.

C++ has a whole load of features not available in C.  Many of which take 
up a lot of space and time but are seen as "essentia" by some

C++ is not available on many platforms.  This is practically speaking.

C can be written in a tight modular from that in many ways is object 
orientated not that the OO purists will admit it.

It is perceived that C is faster and more compact than C++.  This is 
generally true though with discipline C++ can be as compact and fast as 
C. You just have to know which features *not* to use.

Therefore C tends to be used on the smaller micros the 8 and 16 bit 
types which make up the majority of MCU in the world by a long way. 
(Partly because there is no C++ support for them)

Traditionally on larger systems C gets used for all the device drivers 
and low level stuff including the RTOS.  C++ tends to get used for the 
application.

These days a lot of it comes down to the compilers (and debug tools) 
available for your target platform and experience.

As I have a lot more C experience than C++ I tend to grab the C compiler 
first in embedded systems. . On a PC I would tend to use the C++ 
compiler.

Others will use C++ for every thing because it is what they know and it 
is "modern" compared to C. .

C is not going to die out as it is widely used in the embedded world and 
will remain so for years to come.

C++ on the other hand is being subverted by C# and C++/CLI  (by MS) and 
also to some extent by Java. So C++ as we know it could morph into 
something else in about 4-5 years. .

OS there you are.... as clear as mud :-)

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/



0
chris32 (3361)
11/15/2006 9:24:08 AM
CBFalconer wrote:
> Skarmander wrote:
> ... snip ...
>> It *is* a flaw in C. The syntax is confusing, and pointlessly so. The
>> language would be better if it did not include this particular syntax
>> form at all, and if array parameters looked as what they are: pointers.
> 
> So all you have to do is write your function prototypes to specify
> pointers, rather than the confusing array format.  It's your own
> fault.
> 
You're suggesting that people not use the confusing syntax in order not to 
be confused by it?

Assuming everyone did this, it would be still be a flaw, because everyone 
would be required to learn not to do something that ought to be impossible.

S.
0
invalid58 (621)
11/15/2006 7:48:16 PM
sam_cit@yahoo.co.in wrote:
> Hi everyone,
>
>   I have been asked this question quite a few times and i wonder what
> could the actual reason?
>
>  " When to prefer C over C++ or vice versa, of course this is for real
> world pratical scenario"
>
>     As per my understanding, C++ makes it easier to program application
> related logic as OOPS helps in that sense, but for some reason that is
> not a reasonable explanation, could any one add on their comments?

You have to use C when you can, C++ when you have to, or the other way,
use C++ you have to, C when you can. :-)

0
11/16/2006 3:50:11 AM
jacob navia <jacob@jacob.remcomp.fr> wrote:

> Richard Bos a �crit :
> > ...is not at all the same as this, which is a function declaration which
> > includes a _pointer_ _argument_ which only looks like an array.
> 
> What was I saying?
> 
> int array[5]: the size information is destroyed or discarded...

No, that's not what you were saying. Look again:

> >>>>>int array[5];
> >>void fn(int array[8])

Spot the fundamental difference?

Richard
0
rlb (4118)
11/16/2006 9:20:50 AM
jacob navia <jacob@jacob.remcomp.fr> wrote:

> Frederick Gotham wrote:
> > Mark McIntyre:
> > 
> >>In what way is int array[8] not an array? 
> > 
> > In the following context:
> > 
> > void Func(int array[8])
> > {
> >     sizeof array;
> > }
> > 
> > int main(void) { return 0; }
> > 
> Yes, that's precisely my point.
> 
> Arrays become just pointers,

No, they don't. In that context, there _is_ no array. There is a
notational oddity which _looks_ like an array. That's all.

Richard
0
rlb (4118)
11/16/2006 9:23:01 AM
Keith Thompson:

>> And we'd probably end up with something like C++...
> 
> C++ has the same array/pointer conversion rules as C (though it also
> has STL vectors and so forth).

<OT>

Yes, but we can have references to arrays, and we can pass an array by 
reference.

    void Func(int (&arr)[5]) {}

Or more exotically:

    #include <cstddef>

    void Func(int *p,std::size_t len) {}

    template<std::size_t len>
    void Func(int (&arr)[len]) { Func(arr,len); }

    int main()
    {
        int arr[5];

        Func(arr);
    }

</OT>



-- 

Frederick Gotham
0
fgothamNO (1668)
11/17/2006 6:54:01 PM
sam_cit@yahoo.co.in wrote:
> Hi everyone,
> 
>   I have been asked this question quite a few times and i wonder what
> could the actual reason?
> 
>  " When to prefer C over C++ or vice versa, of course this is for real
> world pratical scenario"
> 
>     As per my understanding, C++ makes it easier to program application
> related logic as OOPS helps in that sense, but for some reason that is
> not a reasonable explanation, could any one add on their comments?
> 

Hi!
The answer is pretty simple:
C is mainly used for low-level programming, - like operating systems, or 
something like that - when it's simplicity is an advantage. C++ is used 
for application programming.

Leslie Kis-Adam
<dfighter_AT_NOSPAM_freemail.hu>
0
dfighter (17)
11/17/2006 8:55:11 PM
On Fri, 17 Nov 2006 21:55:11 +0100, Leslie Kis-Adam
<dfighter@freemail.hu> wrote:

>sam_cit@yahoo.co.in wrote:
>> Hi everyone,
>> 
>>   I have been asked this question quite a few times and i wonder what
>> could the actual reason?
>> 
>>  " When to prefer C over C++ or vice versa, of course this is for real
>> world pratical scenario"
>> 
>>     As per my understanding, C++ makes it easier to program application
>> related logic as OOPS helps in that sense, but for some reason that is
>> not a reasonable explanation, could any one add on their comments?
>> 
>
>Hi!
>The answer is pretty simple:
>C is mainly used for low-level programming, - like operating systems, or 
>something like that - when it's simplicity is an advantage. C++ is used 
>for application programming.
>
Except, of course, for the many applications written in C.


-- 
Al Balmer
Sun City, AZ
0
albalmer (2312)
11/17/2006 10:55:15 PM
Al Balmer wrote:
> On Fri, 17 Nov 2006 21:55:11 +0100, Leslie Kis-Adam
> <dfighter@freemail.hu> wrote:
>
> >sam_cit@yahoo.co.in wrote:
> >> Hi everyone,
> >>
> >>   I have been asked this question quite a few times and i wonder what
> >> could the actual reason?
> >>
> >>  " When to prefer C over C++ or vice versa, of course this is for real
> >> world pratical scenario"
> >>
> >>     As per my understanding, C++ makes it easier to program application
> >> related logic as OOPS helps in that sense, but for some reason that is
> >> not a reasonable explanation, could any one add on their comments?
> >>
> >
> >Hi!
> >The answer is pretty simple:
> >C is mainly used for low-level programming, - like operating systems, or
> >something like that - when it's simplicity is an advantage. C++ is used
> >for application programming.
> >
> Except, of course, for the many applications written in C.

And the many operating systems written in C++, (offhand, L4, Windows NT
and Choices come to mind).

0
santosh.k83 (3969)
11/18/2006 2:59:18 AM
santosh wrote:
> Al Balmer wrote:
>> On Fri, 17 Nov 2006 21:55:11 +0100, Leslie Kis-Adam
>> <dfighter@freemail.hu> wrote:
>>
>>> sam_cit@yahoo.co.in wrote:
>>>> Hi everyone,
>>>>
>>>>   I have been asked this question quite a few times and i wonder what
>>>> could the actual reason?
>>>>
>>>>  " When to prefer C over C++ or vice versa, of course this is for real
>>>> world pratical scenario"
>>>>
>>>>     As per my understanding, C++ makes it easier to program application
>>>> related logic as OOPS helps in that sense, but for some reason that is
>>>> not a reasonable explanation, could any one add on their comments?
>>>>
>>> Hi!
>>> The answer is pretty simple:
>>> C is mainly used for low-level programming, - like operating systems, or
>>> something like that - when it's simplicity is an advantage. C++ is used
>>> for application programming.
>>>
>> Except, of course, for the many applications written in C.
> 
> And the many operating systems written in C++, (offhand, L4, Windows NT
> and Choices come to mind).
> 
Of course you can write applications in C, my point was that C is the 
most useful for system programming.
I guess Windows NT-s GUI was written in C++, but I'm not convinced, that 
  other parts were written with that.
0
dfighter (17)
11/18/2006 11:22:19 AM
Skarmander wrote:
> Frederick Gotham wrote:

<snip>

>> However, we're talking about a programming language. When you're 
>> learning a new programming language, you can't really build on past 
>> experience. You need to confirm and clarify everything.
>>
> Says who? The language? No. So what, then? Experience? Sure. Experience 
> tells us we cannot rely on our previous experience, but you see how that 
> only goes so far.
> 
> If I read
> 
>    c = a + b;
> 
> it is not possible and not helpful for me to pretend that these are 
> meaningless symbols barring an explicit definition in a language 
> standard somewhere that will explain to me what exactly this sequence of 
> symbols means, if anything.
> 
> For sure, the language standard *is* the only authority on it. I cannot 
> *rely* on my assumptions about the statement's semantics, and a good 
> many may be wrong. I cannot with any definite justification shout 
> "that's wrong" if it shouldn't match my expectation. However, if "c = a 
> + b;" turned out to mean "perform a low-level format of all attached 
> disk drives", I would have reason to complain nonetheless, however 
> formally precise and consistent the definition might be.

Actually, depending on your background and the language you use that 
expression in you could be very surprised by the result. If your 
experience is Pascal and saw it in a context where a condition is 
expected you would think it was doing a comparison. If your experience 
is C and you saw it in a Pascal program you would think it was doing an 
assignment. If it is actually in C++ then with object overloading the + 
operator or the = operator *could* (with appropriate system specific 
extensions) perform a low level format of all attached disk drives!

So, even for such a simple example, you *still* have to learn the 
language to know what it means, and sometimes learn the code base you 
are working with as well!

>> The simple fact of the matter is that you have to be in the know when 
>> it comes to a programming language. Some people may presume that you 
>> can pass an array by value, but alas they're wrong. Was their 
>> intuition flawed to think they could simply write:
>>
>> void Func(int arr[5]) {}
>>
>> Maybe, maybe not. 
> 
> As long as we're willing to concede the possibility, that's enough. It's 
> not a black and white issue, and that's my point. "It's standard C so 
> there's no point criticizing it for what it isn't" is a reasonable 
> attitude for writing programs (indeed, the only reasonable attitude), 
> but not when the point precisely is criticism of C's design.
> 
> Is the intuition flawed? Consider this: in C, everything that can be 
> passed  is passed by value, but arrays cannot be passed as values. This 
> is not reflected in the most intuitive attempt at doing it, since that 
> is not an error, but instead implements quite different semantics.

<snip other related stuff about intuition since this is enough to show 
the arguments going on>

My experience says you can't rely on your intuition because your 
intuition is based on your experience and even a very simple expression 
can mean drastically different things depending on the language and 
surrounding code.

Having said that, I agree that C would be better if either you could not 
use "int array[6]" as a parameter definition or if it really did mean 
you were passing an array of 6 ints by value.
-- 
Flash Gordon
0
spam331 (4048)
11/18/2006 1:27:07 PM
sam_cit@yahoo.co.in wrote:

> When [should I] prefer C over C++ or vice versa?
> Of course, this is for real world practical scenario.

If there is really a choice, good programmers always choose C++.

In practice, programmers who use C do so because they have no choice.
They must maintain legacy C code, they don't have access
to a reliable C++ compiler for the target platform or
they just don't understand C++ well enough to write good C++ programs.

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
0
edwin2096 (28)
11/18/2006 7:51:44 PM
"E. Robert Tisdale" <edwin@netwood.net> writes:
> sam_cit@yahoo.co.in wrote:
>> When [should I] prefer C over C++ or vice versa?
>> Of course, this is for real world practical scenario.
>
> If there is really a choice, good programmers always choose C++.
>
> In practice, programmers who use C do so because they have no choice.
> They must maintain legacy C code, they don't have access
> to a reliable C++ compiler for the target platform or
> they just don't understand C++ well enough to write good C++ programs.

That is manifestly untrue, but I'm not going to waste my time arguing
the point.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
We must do something.  This is something.  Therefore, we must do this.
0
kst-u (21963)
11/18/2006 8:40:35 PM
"E. Robert Tisdale" wrote:
> sam_cit@yahoo.co.in wrote:
> 
>> When [should I] prefer C over C++ or vice versa?
>> Of course, this is for real world practical scenario.
> 
> If there is really a choice, good programmers always choose C++.

Trollsdale alert.  It's baaack.  Now we have to watch out for
altered quotations again, not to mention misinformation.  Looks
like it got fired from JPL at last, which is progress.

-- 
Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>


0
cbfalconer (19194)
11/18/2006 9:13:15 PM
CBFalconer wrote:
> "E. Robert Tisdale" wrote:
> > sam_cit@yahoo.co.in wrote:
> >
> >> When [should I] prefer C over C++ or vice versa?
> >> Of course, this is for real world practical scenario.
> >
> > If there is really a choice, good programmers always choose C++.
>
> Trollsdale alert.  It's baaack.  Now we have to watch out for
> altered quotations again, not to mention misinformation.  Looks
> like it got fired from JPL at last, which is progress.

Would that be the "Jet propulsion laboratory" ? Whatever
it is how do you know he got fired ?

0
spibou (1037)
11/18/2006 9:54:41 PM
Spiros Bousbouras said:

> CBFalconer wrote:
>> Looks
>> like it got fired from JPL at last, which is progress.
> 
> Would that be the "Jet propulsion laboratory" ? Whatever
> it is how do you know he got fired ?

That's what Jet Propulsion Laboratories *do* - fire things.


-- 
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not 
adjust your email clients.
0
invalid171 (7008)
11/18/2006 10:58:05 PM
In article <1163879568_7665@sp6iad.superfeed.net>, E. Robert Tisdale 
<edwin@netwood.net> writes
>sam_cit@yahoo.co.in wrote:
>
>> When [should I] prefer C over C++ or vice versa?
>> Of course, this is for real world practical scenario.
>
>If there is really a choice, good programmers always choose C++.

Absolute CRAP.
In fact I would say that if a programmer always chooses C++ if there is 
a choice between c and C++ they are incompetent.

>In practice, programmers who use C do so because they have no choice.

Not true.

>They must maintain legacy C code, they don't have access
>to a reliable C++ compiler for the target platform or

This is sometimes true. There are not C++ compilers for all the targets 
that have C compilers.

>they just don't understand C++ well enough to write good C++ programs.

Also of course a lot of C++ programmers have no idea how to write good C 
programs.

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/



0
chris32 (3361)
11/19/2006 11:51:26 AM
Leslie Kis-Adam <dfighter@freemail.hu> wrote:

[ Snip! ]

> santosh wrote:
> > Al Balmer wrote:
> >> On Fri, 17 Nov 2006 21:55:11 +0100, Leslie Kis-Adam
> >>
> >>> sam_cit@yahoo.co.in wrote:
> >>>>  " When to prefer C over C++ or vice versa, of course this is for real
> >>>> world pratical scenario"

> >>> The answer is pretty simple:
> >>> C is mainly used for low-level programming, - like operating systems, or
> >>> something like that - when it's simplicity is an advantage. C++ is used
> >>> for application programming.
> >>>
> >> Except, of course, for the many applications written in C.
> > 
> > And the many operating systems written in C++, (offhand, L4, Windows NT
> > and Choices come to mind).
> > 
> Of course you can write applications in C, my point was that C is the 
> most useful for system programming.

Yes, and that point was wrong. Many people write application programs in
C.

> I guess Windows NT-s GUI was written in C++, but I'm not convinced, that 
>   other parts were written with that.

Anyway, I'm not convinced that Windows NT is a valid counter-example
against anything involving operating systems.

Richard
0
rlb (4118)
11/20/2006 7:30:02 AM
Richard Bos wrote:
> Leslie Kis-Adam <dfighter@freemail.hu> wrote:
>
> [ Snip! ]
>
> > santosh wrote:
> > > Al Balmer wrote:
> > >> On Fri, 17 Nov 2006 21:55:11 +0100, Leslie Kis-Adam
> > >>
> > >>> sam_cit@yahoo.co.in wrote:
<snip>
> > >>> The answer is pretty simple:
> > >>> C is mainly used for low-level programming, - like operating systems, or
> > >>> something like that - when it's simplicity is an advantage. C++ is used
> > >>> for application programming.
> > >>>
> > >> Except, of course, for the many applications written in C.
> > >
> > > And the many operating systems written in C++, (offhand, L4, Windows NT
> > > and Choices come to mind).
> > >
<snip>
> > I guess Windows NT-s GUI was written in C++, but I'm not convinced, that
> >   other parts were written with that.
>
> Anyway, I'm not convinced that Windows NT is a valid counter-example
> against anything involving operating systems.

Both of you seem to have overlooked my first, and admittedly better,
example for an operating system kernel written in C++, namely L4.

0
santosh.k83 (3969)
11/20/2006 7:48:05 AM
On Sat, 18 Nov 2006 11:51:44 -0800, "E. Robert Tisdale"
<edwin@netwood.net> wrote:
A standard Tisdale Troll, having changed his email address and
temporarily escaped my filter.

-- 
Al Balmer
Sun City, AZ
0
albalmer (2312)
11/20/2006 3:49:53 PM
On Sun, 19 Nov 2006 11:51:26 +0000, Chris Hills <chris@phaedsys.org>
wrote:

>>they just don't understand C++ well enough to write good C++ programs.
>
>Also of course a lot of C++ programmers have no idea how to write good C 
>programs.

Or good C++ programs :-)

-- 
Al Balmer
Sun City, AZ
0
albalmer (2312)
11/20/2006 3:52:49 PM
On Sat, 18 Nov 2006 16:13:15 -0500, CBFalconer <cbfalconer@yahoo.com>
wrote:

> "E. Robert Tisdale" wrote:
<snip>
> Trollsdale alert.  It's baaack.  Now we have to watch out for
> altered quotations again, not to mention misinformation.  Looks
> like it got fired from JPL at last, which is progress.

Sorry, but that doesn't follow from the evidence provided.

According to my records, Tisdale has been using both the netwood.net
address and the JPL ones for over 4 years.

- David.Thompson1 at worldnet.att.net
0
12/18/2006 7:22:38 AM
Dave Thompson wrote:
> On Sat, 18 Nov 2006 16:13:15 -0500, CBFalconer <cbfalconer@yahoo.com> wrote:
>> "E. Robert Tisdale" wrote:
> <snip>
>> Trollsdale alert.  It's baaack.  Now we have to watch out for
>> altered quotations again, not to mention misinformation.  Looks
>> like it got fired from JPL at last, which is progress.
> 
> Sorry, but that doesn't follow from the evidence provided.
> 
> According to my records, Tisdale has been using both the netwood.net
> address and the JPL ones for over 4 years.

This is one of the few occasions when a date in an attribution is
useful :-)  At least it went away again.

-- 
Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>


0
cbfalconer (19194)
12/18/2006 11:24:32 AM
Reply: