f



why still use C?

no this is no trollposting and please don't get it wrong but iam very
curious why people still use C instead of other languages especially C++.

i heard people say C++ is slower than C but i can't believe that. in pieces
of the application where speed really matters you can still use "normal"
functions or even static methods which is basically the same.

in C there arent the simplest things present like constants, each struct and
enum have to be prefixed with "struct" and "enum". iam sure there is much
more.

i don't get it why people program in C and faking OOP features(function
pointers in structs..) instead of using C++. are they simply masochists or
is there a logical reason?

i feel C has to benefit against C++.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
10/5/2003 9:37:06 PM
comp.lang.c 30657 articles. 4 followers. spinoza1111 (3246) is leader. Post Follow

639 Replies
2798 Views

Similar Articles

[PageSpeed] 13

In article <clcm-20031005-0008@plethora.net>, cody wrote:
> no this is no trollposting and please don't get it wrong but iam very
> curious why people still use C instead of other languages especially C++.
> 
> i heard people say C++ is slower than C but i can't believe that.
[-]
It isn't.

[-]
> i don't get it why people program in C and faking OOP features(function
> pointers in structs..) instead of using C++. are they simply masochists or
> is there a logical reason?
[-]
C++ compilers used to pose problems like being more or less standards
compliant and in all honesty they often still do plus to generate optimal
machine code the compiler / linker combo needs to work together much more
closely than it is the case with C.

Well, and developers used to and use to pose problems, too as just take
some seasoned C developers and be assured over their dead body they'll
admit not to be able to output high quality C++ code almost straight
away and so it must be the language.

In short C++ isn't slower for sure as both, a C as well as a C++ compiler
is going to generate machine code. It's just no compiler can do the
thinking for you (yet) and I haven't met all too many C++ developers
yet who really do know the language.

Mind I'm far from saying I'd really do. Far from it, though I'm not
having problems admiting that while, after being more then 10 years in
the job, I dare say there's a fair share of developers, often the local
"star developers", who prefer arguing to listening.

In general language wars are pointless anyway, though as the end user
couldn't care less about "your" problems but he or she wants to see
a working result, so the real question is are you able to deliver or
are you not ?

Cheers,
Juergen

-- 
\ Real name     : Juergen Heinzl       \       no flames      /
 \ EMail Private : juergen@manannan.org \ send money instead /
0
juergen14 (24)
10/5/2003 10:03:39 PM
Hi cody,

> no this is no trollposting and please don't get it wrong but iam very
> curious why people still use C instead of other languages especially C++.

I can't answer for people in general of course, but as a moderately able 
C programmer with a thorough dislike of C++ I can try to explain what my 
motives are.

> i heard people say C++ is slower than C but i can't believe that. in pieces
> of the application where speed really matters you can still use "normal"
> functions or even static methods which is basically the same.

A few years ago I did some timing and (counter to my intuition) I found 
that, indeed, it didn't make a difference, as you point out. One 
remarkable thing was that the C++ executables for my (small) benchmarks 
were quite a bit larger, which may be relevant for embedded applications.

> in C there arent the simplest things present like constants, each struct and
> enum have to be prefixed with "struct" and "enum". iam sure there is much
> more.

These are some areas where I would agree that yes, C++ is (a bit) 
cleaner than C. Another example is declaring variables inside for() 
statements and such, this can truly help readability, and limiting the 
scope of a local variable if possible is a good thing. Note that many of 
these (almost cosmetic) changes have made their way back into C99.

> i don't get it why people program in C and faking OOP features(function
> pointers in structs..) instead of using C++. are they simply masochists or
> is there a logical reason?

In all honesty I think that many people who prefer C over C++ don't 
quite get what all the fuzz is about in OOP (I know I don't). In 
principle there are sound advantages to grouping together structs and 
their associated method functions from a design perspective. Inheritance 
and polymorphism have an important part to play as well, especially in 
some areas of application (such as GUIs).

However, this is the first place where you get a tradeoff of execution 
speed, executable size, and runtime memory usage (for virtual method 
tables) versus design-time advantages. In reality of course, especially 
with nowadays' big machines, these disadvantages are not too important 
for most applications. However, (to me at least) it is a bit unnerving 
to be at the mercy of the compiler and its designer, and hope that he 
implemented all this machinery properly and without causing too much 
overhead. This is more a psychological barrier than a real one of 
course, since modern compilers are able to optimize away many 
unneccessary machinery, and some rather clever tricks have been found to 
  make virtual method calls very cheap. However, as a programmer I am no 
longer completely in the driver's seat as I am with C. Looking at a C 
porgram, I can have a straightforward and relatively accurate mental 
picture of what the actual machine code produced by the compiler will 
look like. With OOP and C++, that's no longer true, especially with code 
that uses all the available C++ features including exceptions and templates.

One generic complaint I have with OOP (not limited to C++) is that I can 
no longer look at a code fragment and reconstruct the execution flow in 
my head, because of polymorphism and operator overloading; in C (unless 
you're doing funky stuff with threads or longjumps), the execution flow 
is pretty much known at compile-time, and can be reproduced from the 
code. I happen to like that.

Of course OOP proponents will counter that this is in fact the entire 
point of OOP: one should no longer be thinking in terms of structural 
execution flow, but rather in terms of objects with a well-defined 
behaviorial 'contract', that can be triggered by invoking methods.

Now this is where a lot of subjectivity comes in, but I for one simply 
don't think that way. This is probably due to the way I earned my 
computer experience (going up from BASIC to 8-bit machine language to 
Pascal to C). "Thinking in classes", something that is essential for 
good OOP programming, is just not for me (except for some obvious cases 
with a small number of classes - I have done some C++ programming in my 
time of course).

When the programs get bigger, and the number of classes grows, you come 
to another point: there is a transition in the level of design: instead 
of putting statements in the right order, you have to start managing a 
class model. The Design Patterns school-of-thought comes in here: how do 
I design a set of classes with interaction to get a certain type of 
bahavior? For me, this has two problems. First, there is often more than 
one sensible way of designing a set of classes to address a certain 
problem. I have an instinctive dislike of that kind of situation: I have 
the (admittedly rather naive) feeling that software related problems 
should have a canonical 'best' solution. The second (real) problem is 
that C++ doesn't really support the Design Pattern level of abstraction. 
Instead, it hands the programmer a number of nuts and bolts that enable 
him to approximate the abstract idea encapsulated in a DP. I think there 
are no programming languages available today that properly support the 
Design Pattern methodology, and it's certainly not C++.

Now of course all this is more a rant against OOP than C++, but IMHO C++ 
offers no advantages to C99 other than OOP-support, so it is relevant to 
your question.

You could argue of course that C++ > (C + OOP). The two most prominent 
features apart from OOP that set aside C and C++ are, I think, 
exceptions and templates.

As for exceptions, you may know Dijkstra's paper "Goto's considered 
harmful". In this paper he has a number of points that I would subscribe 
to, concerning the ability of the human programmer to read the meaning 
of a piece of code from the source. In essence, he argues that GOTO 
statements destroy this possibility.

I would argue that exceptions are "goto's on steroids". Since exceptions 
are allowed to cross function-call boundaries, execution flow becomes 
very non-transparant - at least to me! This is a similar objection I 
have with polymorphism as described above.

A serious problem with exception handling in C++ is it's interaction 
with memory management, which is made even worse by having implicit 
object creation (with implicit constructor calls). Now I know a lot of 
talented programmers, many of which are far more accomplished in C++ 
programming than I am, but not a single one of them can quote me the 
do's-and-don'ts of a 'good' C++ program in this respect. It's a minefield.

Incidentally, having just written a rather big real-life C library with 
error handling, I do appreciate the need for exception handling. 
However, I think it is a mistake to have a language that does include 
exception handling but doesn't do garbage collection for the reason 
stated above. Sure, it's possible to do it properly. But one has to 
remember that programmers are human beings; most programmers I know have 
simply not the level of intimacy with the C++ runtime model to do this 
without making mistakes.

Templates.... Suffice it to say that one cannot write a portable C++ 
program using templates and expect it to work identically on different 
compilers. Portability is nil, and this makes this feature not useful in 
many practical sutuations. One can complain about (or to) compiler 
builders in this regard, but this is just a symptom of overly 
complicated semantics. Even if compiler builders get their act together, 
the semantics would still be too difficult for most programmers. 
Including me.

To summarize I would say C++ with its feature set is just too 
complicated, as a language design I feel it has failed. One has to keep 
in mind that a programming language is a tool to make programs. If a 
tool has a significant chance of being unintentially misused (with 
possibly disastrous results), it's not a good tool. I will stick with 
something I actually (more or less) understand, which is C.

By the way, did you ever read the Stroustrup book ('Programming in 
C++')? As the book progresses, his examples evolve from things that look 
sort-of-like-C to STL-based programs that are (to my untrained eye at 
least) simply ugly. My feeling is that he tries to bring the expressive 
power of dynamic interpreted languages to the realm of compiled 
languages. A valliant attempt, and I would applaud him for it. However, 
his writing conveys a breathtaking arrogance or perhaps lack of 
understanding for the fact that most programmers are mere mortals... I'm 
sure as the language's designer he is able to mentally internalize the 
runtime model of C++, but to think that your average programmer could 
readily do the same is just preposterous.

And a last thing: try writing a library in C++ and linking it with a 
program written in C (like Matlab, IDL, Mathematica...). Now there's a 
practical reason to prefer C over C++ if I ever saw one.

Thank you for giving me an opportunity to rant a bit about this. Perhaps 
this therapeutical excercise of mine will give you some insight in the 
reasons why some of us still prefer C over C++! :-)

Best regards,

   Sidney Cadot
   The Netherlands

0
sidney (345)
10/6/2003 1:00:01 AM
Sidney Cadot wrote:

> Hi cody,
> 
>> no this is no trollposting and please don't get it wrong but iam very
>> curious why people still use C instead of other languages especially C++.
> 
> I can't answer for people in general of course, but as a moderately able
> C programmer with a thorough dislike of C++ I can try to explain what my
> motives are.

<superb answer snipped>

Very well said. A very thoughtful article indeed.

-- 
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
0
dontmail (1886)
10/6/2003 5:21:46 AM
"Sidney Cadot" <sidney@jigsaw.nl> wrote in message
news:blqeq9$1lc$1@news.tudelft.nl...
> Hi cody,
>
> > no this is no trollposting and please don't get it wrong but iam very
> > curious why people still use C instead of other languages especially
C++.
>
> I can't answer for people in general of course, but as a moderately able
> C programmer with a thorough dislike of C++ I can try to explain what my
> motives are.
>
> > i heard people say C++ is slower than C but i can't believe that. in
pieces
> > of the application where speed really matters you can still use "normal"
> > functions or even static methods which is basically the same.
>
> A few years ago I did some timing and (counter to my intuition) I found
> that, indeed, it didn't make a difference, as you point out. One
> remarkable thing was that the C++ executables for my (small) benchmarks
> were quite a bit larger, which may be relevant for embedded applications.

OOP in general tends to be slower.  The process of allocating and
deallocating memory, including finding a good sized region to allocate,
takes time.   As you say, though, one can do non-OOP in C++, and, with some
work, OOP in C.

> > in C there arent the simplest things present like constants, each struct
and
> > enum have to be prefixed with "struct" and "enum". iam sure there is
much
> > more.

As if the compiler didn't know...  In PL/I structures can be referenced in
any unambiguous way.  I don't know if that leads to more bugs, or makes
programs more or less readable, though.   It does seem strange that you have
to keep reminding the compiler that something is a struct.

> These are some areas where I would agree that yes, C++ is (a bit)
> cleaner than C. Another example is declaring variables inside for()
> statements and such, this can truly help readability, and limiting the
> scope of a local variable if possible is a good thing. Note that many of
> these (almost cosmetic) changes have made their way back into C99.
>
> > i don't get it why people program in C and faking OOP features(function
> > pointers in structs..) instead of using C++. are they simply masochists
or
> > is there a logical reason?

Note, though, that Java is much closer to C than C++ is, despite the
similarity of names.  If you like C, but want an OO language, Java should be
your choice.

> In all honesty I think that many people who prefer C over C++ don't
> quite get what all the fuzz is about in OOP (I know I don't). In
> principle there are sound advantages to grouping together structs and
> their associated method functions from a design perspective. Inheritance
> and polymorphism have an important part to play as well, especially in
> some areas of application (such as GUIs).

For some kinds of programming projects, yes.

(snip)

>. However, as a programmer I am no
> longer completely in the driver's seat as I am with C. Looking at a C
> porgram, I can have a straightforward and relatively accurate mental
> picture of what the actual machine code produced by the compiler will
> look like. With OOP and C++, that's no longer true, especially with code
> that uses all the available C++ features including exceptions and
templates.

Well, some people consider C as a glorified assembler.  It isn't quite that,
especially as it has changed over the years, but not so far off.

> One generic complaint I have with OOP (not limited to C++) is that I can
> no longer look at a code fragment and reconstruct the execution flow in
> my head, because of polymorphism and operator overloading; in C (unless
> you're doing funky stuff with threads or longjumps), the execution flow
> is pretty much known at compile-time, and can be reproduced from the
> code. I happen to like that.

Well, with library functions in general you don't know what is inside the
function.   If you are writing the whole program yourself then the
abstraction is less useful.   If different people are working on different
parts then abstraction means you need to know less about the specific
features of those parts.  The interface is narrower, which sometimes
decreases efficiency.  (It may take more calls to get something done, or
more things done than are really needed.)

> Of course OOP proponents will counter that this is in fact the entire
> point of OOP: one should no longer be thinking in terms of structural
> execution flow, but rather in terms of objects with a well-defined
> behaviorial 'contract', that can be triggered by invoking methods.

(snip)

> As for exceptions, you may know Dijkstra's paper "Goto's considered
> harmful". In this paper he has a number of points that I would subscribe
> to, concerning the ability of the human programmer to read the meaning
> of a piece of code from the source. In essence, he argues that GOTO
> statements destroy this possibility.
>
> I would argue that exceptions are "goto's on steroids". Since exceptions
> are allowed to cross function-call boundaries, execution flow becomes
> very non-transparant - at least to me! This is a similar objection I
> have with polymorphism as described above.

Well, there is that.  But the name, exception, gives you some idea of their
use.  They should be used for exceptional things.  In compilers sometimes
there is nothing that can be done.  Especially in recursive descent
compilers it may be that the only thing to do is declare an error and go
onto the next statement.   That requires crossing function call boundaries,
but it is easy to understand what is happening.  The C setjmp/longjmp has a
similar use, and is similarly non-transparent.

(snip)

> To summarize I would say C++ with its feature set is just too
> complicated, as a language design I feel it has failed. One has to keep
> in mind that a programming language is a tool to make programs. If a
> tool has a significant chance of being unintentially misused (with
> possibly disastrous results), it's not a good tool. I will stick with
> something I actually (more or less) understand, which is C.

Well, much of the idea of C is to be simple.  I learned PL/I as my first
structures language, and I still prefer it, in some ways, to C.    PL/I is
complicated, almost by design.  (It was designed to include features from
Algol, Fortran, and COBOL, all in one language.)   C string handling is
simple in design, somewhat efficient, but so easy to do wrong.    Again,
PL/I was designed to be complicated, but such that you didn't need to learn
parts you didn't need to use.  That required no reserved words.  (If you
didn't know about a feature how could you know not to use the words?)
Writing simple programs is pretty simple.   The dynamic memory features of C
are fine once you are used to them, but pretty strange until then.

-- glen


0
gah (12851)
10/6/2003 5:28:35 AM
On  6-Oct-2003, "cody" <NO.SPAM.deutronium@gmx.net> wrote:

> [snip]

Because C is more portable?

0
nospam59 (11089)
10/6/2003 9:01:03 AM
<nospam@nospam.invalid> wrote in message
news:20031006091002.387075F1A6@mail.zedz.net...
>
> On  6-Oct-2003, "cody" <NO.SPAM.deutronium@gmx.net> wrote:
>
> > [snip]
>
> Because C is more portable?

No more portable than C++.

-Mike


0
mkwahler (3821)
10/6/2003 11:17:02 AM
> Inheritance and polymorphism have an important part to play as well,
> especially in some areas of application (such as GUIs).
>
> However, this is the first place where you get a tradeoff of execution
> speed, executable size, and runtime memory usage (for virtual method
> tables) versus design-time advantages. In reality of course, especially
> with nowadays' big machines, these disadvantages are not too important
> for most applications. However, (to me at least) it is a bit unnerving
> to be at the mercy of the compiler and its designer, and hope that he
> implemented all this machinery properly and without causing too much
> overhead. This is more a psychological barrier than a real one of

that is really true!

> course, since modern compilers are able to optimize away many
> unneccessary machinery, and some rather clever tricks have been found to
>   make virtual method calls very cheap. However, as a programmer I am no
> longer completely in the driver's seat as I am with C. Looking at a C
> porgram, I can have a straightforward and relatively accurate mental
> picture of what the actual machine code produced by the compiler will
> look like. With OOP and C++, that's no longer true, especially with code
> that uses all the available C++ features including exceptions and
templates.
>
> One generic complaint I have with OOP (not limited to C++) is that I can
> no longer look at a code fragment and reconstruct the execution flow in
> my head, because of polymorphism and operator overloading;

yes, operator overloading is one of the most the most sucking thing in c++!

> As for exceptions, you may know Dijkstra's paper "Goto's considered
> harmful". In this paper he has a number of points that I would subscribe
> to, concerning the ability of the human programmer to read the meaning
> of a piece of code from the source. In essence, he argues that GOTO
> statements destroy this possibility.
>
> I would argue that exceptions are "goto's on steroids". Since exceptions
> are allowed to cross function-call boundaries, execution flow becomes
> very non-transparant - at least to me!

where the exception goes is well defined, it cannot go somewhere, it goes
simply
down the callstack which is more readable than gotos, imo.

but doesn't c support structured exception handling too? i heard something
like that.

> It's a minefield.

absolutely.

> Templates.... Suffice it to say that one cannot write a portable C++
> program using templates and expect it to work identically on different
> compilers. Portability is nil, and this makes this feature not useful in
> many practical sutuations. One can complain about (or to) compiler
> builders in this regard, but this is just a symptom of overly
> complicated semantics.

that is not true. name me one example where semantics are different on
different compilers!
templates are a very very useful and mighty feature in c++. however it is a
bit difficult to use.

> To summarize I would say C++ with its feature set is just too
> complicated, as a language design I feel it has failed. One has to keep
> in mind that a programming language is a tool to make programs. If a
> tool has a significant chance of being unintentially misused (with
> possibly disastrous results), it's not a good tool. I will stick with
> something I actually (more or less) understand, which is C.

yes and no. c++ should not be used for everything. gui's should not be made
with c++.
for libraries, c++ is good because it is very fast and flexible thanks to
templates.
you say the language design has failed, but do you have a better idea how it
can be solved?
imo for high performance applications there is no better way than c++. since
c lacks of templates,
c++ would be the choice for me.

> By the way, did you ever read the Stroustrup book ('Programming in
> C++')? As the book progresses, his examples evolve from things that look
> sort-of-like-C to STL-based programs that are (to my untrained eye at
> least) simply ugly. My feeling is that he tries to bring the expressive
> power of dynamic interpreted languages to the realm of compiled
> languages. A valliant attempt, and I would applaud him for it. However,
> his writing conveys a breathtaking arrogance or perhaps lack of
> understanding for the fact that most programmers are mere mortals... I'm
> sure as the language's designer he is able to mentally internalize the
> runtime model of C++, but to think that your average programmer could
> readily do the same is just preposterous.

right i cannot imagegine that somebody really and completely understands the
STL.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk


0
10/6/2003 12:23:23 PM
Mike Wahler wrote:

> 
> <nospam@nospam.invalid> wrote in message
> news:20031006091002.387075F1A6@mail.zedz.net...
>>
>> On  6-Oct-2003, "cody" <NO.SPAM.deutronium@gmx.net> wrote:
>>
>> > [snip]
>>
>> Because C is more portable?
> 
> No more portable than C++.
> 
> -Mike
Are you excluding "C++" programs written for Microsoft compilers, or g++ 
prior to 3.x?  That would nearly make the point, that C++ portability has 
been possible (but not commonly adhered to) for about a year, compared to 
over 20 for C.
-- 
Tim Prince
0
10/6/2003 1:31:50 PM
Sidney Cadot <sidney@jigsaw.nl> wrote in message news:<blqeq9$1lc$1@news.tudelft.nl>...
....
> And a last thing: try writing a library in C++ and linking it with a 
> program written in C (like Matlab, IDL, Mathematica...). Now there's a 
> practical reason to prefer C over C++ if I ever saw one.

It seems to me that only this last issue truly addresses the question.
In all of your other issues, you're complaining about features of C++
that you don't have to use if you don't want to.

I personally use C or C++ for the simple reason that our company's
contract with NASA requires us to deliver code for either Fortran 77,
Fortran 90, C90 (more precisely, C94), or Ada.

I like C because it's a simpler language than C++, and because I've
got a lot more experience with it. However, I love complicated things,
and I see all kinds of interesting features in C++ that I'd love to
have time to play with. However, as long as all of my C++ programming
is done at home, rather than at work, I'm never going to build up much
experience with it. I'm hpping that the next project I work on allows
both C++ and C99 (which also has some neat new features that aren't in
C++).
0
kuyper5 (433)
10/6/2003 2:01:44 PM
On Sun, 5 Oct 2003, cody wrote:

> no this is no trollposting and please don't get it wrong but iam very
> curious why people still use C instead of other languages especially C++.
>
> i heard people say C++ is slower than C but i can't believe that. in pieces
> of the application where speed really matters you can still use "normal"
> functions or even static methods which is basically the same.
>
> in C there arent the simplest things present like constants, each struct and
> enum have to be prefixed with "struct" and "enum". iam sure there is much
> more.
>
> i don't get it why people program in C and faking OOP features(function
> pointers in structs..) instead of using C++. are they simply masochists or
> is there a logical reason?
>
> i feel C has to benefit against C++.

There are a few reasons I would use C over C++.

1) Not all environments have a good C++ compiler.

There are still some situations where finding a good C++ compiler is just
not possible. Last time I checked they were still working on an embedded
C++ standard because the C++ standard does not address the needs of the
embedded world.

2) There is a certain amount of overhead with learning and using C++ that
   might not be necessary for specific projects.

If I am writing a program that I can keep most, if not all, of the project
in my head then why would I want to use C++? Especially if I have been
programming C for over 20 years.

3) C language is closer to assembly language.

If I am trying to squeak out every last cycle I can out of an application
or if timing is critical I would write a project in C language, set a
switch to keep the intermediate assembly source files and then replace the
C source with assembly source but only for those functions that need to be
hand tweaked. In situations where I cannot do this, I can often play with
my C language until I get the same results as programming in assembly
language.

Bottom line, I use C with I don't need everything C++ offers. It is sort
of the same reason they still teach Newtonian physics. Why doesn't
everyone use Einsteinian physics? Because Newtonian is easier and is good
enough for today to today physics.

-- 
Send e-mail to: darrell at cs dot toronto dot edu
Don't send e-mail to vice.president@whitehouse.gov
0
darrell13 (403)
10/6/2003 2:29:46 PM
Darrell Grainger wrote:
....
> 3) C language is closer to assembly language.

I don't think that objection holds up. Whatever features of C that
you're thinking of, are all part of C++ as well. If you need to write
close to assembly language, you can write C++ code that is also legal
C90 code with essentially the same meaning. If you follow good C coding
practices (systematic use of prototypes, etc.), you'll seldom even have
to hink about the fact that you're writing this code to be compiled by a
C++ compiler, rather than a C compiler.
0
kuyper (156)
10/6/2003 2:52:14 PM
Mike Wahler wrote:
> <nospam@nospam.invalid> wrote in message
> >
> > Because C is more portable?
> 
> No more portable than C++.

There are many machines out there that have a C compiler, of some
sort, available.  They do not have any C++ available.  PICs, the
Rabbit, 8051s come to mind.  To my mind this makes C more
portable.

If you talk solely about portability, but not availability, then
Pascal is much more portable than C.  There are far fewer
requirements for the underlying machine.  But if you talk about
walking up to some machine while clutching a program source file
in some ISO standardized language, and getting that program to run
on that machine, C is most likely to do the job.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

0
cbfalconer (19194)
10/6/2003 3:05:08 PM
On Mon, 06 Oct 2003 14:29:46 +0000, Darrell Grainger wrote:
 
> Bottom line, I use C with I don't need everything C++ offers. It is sort
> of the same reason they still teach Newtonian physics. Why doesn't
> everyone use Einsteinian physics? Because Newtonian is easier and is good
> enough for today to today physics.

	Allow me, as a former relativist (in the physical sciences sense) to take
exception on that analogy. While illustrative, it seems to imply that C++
has some kind of trascendence over C - which, in my view, it has not.

	Both Newtonian physics and Einsteinian physics are superb theories, the
latter superseding the former, but not obsoleting it for the reasons you
accurately mentioned.

	However, C++ does not stand vis-a-vis C the same way. C++ is a horribly
complicated language, based on a philosophy totally different than that
underlying C, and artificially made it look as close as possible to C. In
my view, C++ is the most abhorrent contraption ever produced by the CS
establishment, turning a potentially interesting field (albeit not the
silver bullet many would have us believe) like object oriented design into
something unpalatable and repugnant. In my view again, if there is a CS
hell, I hope that Mr. Stroustrup, the guy whose brainchild C++ is, has an
honorary place waiting for him in there.

  
0
santa6300 (7)
10/6/2003 6:02:51 PM
Santa Claus wrote:
> 
> However, C++ does not stand vis-a-vis C the same way. C++ is a horribly
> complicated language, based on a philosophy totally different than that
> underlying C, and artificially made it look as close as possible to C. In
> my view, C++ is the most abhorrent contraption ever produced by the CS
> establishment, turning a potentially interesting field (albeit not the
> silver bullet many would have us believe) like object oriented design into
> something unpalatable and repugnant. In my view again, if there is a CS
> hell, I hope that Mr. Stroustrup, the guy whose brainchild C++ is, has an
> honorary place waiting for him in there.

    It'll be right next to the place reserved for people who
sling mud anonymously.

    If your criticism has merit (I know too little of C++ to
evaluate it), have the courage to put your name to it.  If
the courage is lacking, what are we to make of your confidence
in your own opinion?  And if you have so little confidence in
it, why bother us with it?

    May the next chimney you slide down have a roaring fire
at the bottom.

-- 
Eric.Sosman@sun.com
0
Eric.Sosman (4552)
10/6/2003 6:22:06 PM
"Tim Prince" <timothyprince@xxxxsbcglobal.net> wrote in message
news:a9egb.224$_%6.21079244@newssvr21.news.prodigy.com...
> Mike Wahler wrote:
>
> >
> > <nospam@nospam.invalid> wrote in message
> > news:20031006091002.387075F1A6@mail.zedz.net...
> >>
> >> On  6-Oct-2003, "cody" <NO.SPAM.deutronium@gmx.net> wrote:
> >>
> >> > [snip]
> >>
> >> Because C is more portable?
> >
> > No more portable than C++.
> >
> > -Mike
> Are you excluding "C++" programs written for Microsoft compilers,

I'm excluding anything outside the domain of the ISO
standard C++ language,  just as I would exclude anything
outside standard C when referring to portablility.

>or g++
> prior to 3.x?


I'm not talking about compilers, but (standardized) languages.

>That would nearly make the point,

I need refer to no specific imlementations to make the point
that C and C++ are standardized and portable.

> that C++ portability has
> been possible

The ISO standard C++ language is portable.  And yes,
it's possible that it is what it is.

>(but not commonly adhered to)

ISO C and ISO C++ are standardized, portable languages.
What folks do or not with them does not change this fact.

> for about a year,

You don't get out much do you? :-)  C++ has been standardized
since 1998.

>compared to
> over 20 for C.

C has not been standardized for 20 years.  It was first
standardized in 1990 (or 1989, depending upon whom you ask).

-Mike


0
mkwahler (3821)
10/6/2003 6:24:43 PM
cody writes:

> in C there arent the simplest things present like constants, each struct
and
> enum have to be prefixed with "struct" and "enum". iam sure there is much
> more.

The only real difference from C++ is in the syntax.  I think (perhaps
wrongly) of the thing you are describing as a mini namespace thing.
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
r124c4u1022 (2303)
10/6/2003 6:49:39 PM
On 05 Oct 2003 21:37:06 GMT, "cody" <NO.SPAM.deutronium@gmx.net> wrote
in comp.std.c:

> no this is no trollposting and please don't get it wrong but iam very
> curious why people still use C instead of other languages especially C++.

This post is completely off-topic in all three of the newsgroups to
which you posted it, although the moderator of comp.lang.c.moderated
apparently disagrees with me.

It is particularly off-topic in comp.std.c, which discusses the past,
present, and future of the ISO/IEC International Standard for the C
programming language.  As far as the standard is concerned, there is
literally no language other than C, although C++ is mentioned a few
times in non-normative footnotes.

> i heard people say C++ is slower than C but i can't believe that. in pieces

What people?  What are their qualifications to make such a statement?
What evidence have they provided to prove the statement?

And what are your qualifications to refute such a statement?  What
evidence do you have to disprove it?

> of the application where speed really matters you can still use "normal"
> functions or even static methods which is basically the same.
> 
> in C there arent the simplest things present like constants, each struct and
> enum have to be prefixed with "struct" and "enum". iam sure there is much
> more.

Obviously your knowledge of C is minimal.  Do you think ignorance of a
subject qualifies you to expound on it?  Or is your wisdom to be
inferred by your lack of proper capitalization, punctuation, and
grammar?

> i don't get it why people program in C and faking OOP features(function
> pointers in structs..) instead of using C++. are they simply masochists or
> is there a logical reason?
> 
> i feel C has to benefit against C++.

Why should we care about your obviously illogical feelings?  C existed
long before C++ did, and is and was extremely successful.  It is the
most portable programming language in the world.  It does not need to
justify its existence to you or to anyone else, nor does it have to
compare itself to any other language.

Discussions of the relative merits of various programming languages
belong in news:comp.programming if they are cogent.  They belong in
advocacy groups if not.  No one is asking you to use C is you don't
think it is useful to you.

But comparisons between C and any other language, C++ included, are
not C language issues and do not belong in any of groups you posted
to.

-- 
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
jackklein (3930)
10/6/2003 6:49:47 PM
One word inertia.

C++ has been around for so long and is a very mature language with
fantastic tools. The problem is that companies do not invest in
training developers about object oriented design and programming.

Sandeep
--
http://www.EventHelix.com/EventStudio
EventStudio 2.0 - Generate Sequence Diagrams and Use Cases in PDF
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
10/6/2003 6:49:56 PM
"cody" <NO.SPAM.deutronium@gmx.net> wrote in message
news:clcm-20031005-0008@plethora.net...
> no this is no trollposting and please don't get it wrong but iam very
> curious why people still use C instead of other languages especially C++.
>
> i heard people say C++ is slower than C but i can't believe that. in
pieces
> of the application where speed really matters you can still use "normal"
> functions or even static methods which is basically the same.

I would dispute claims that C++ is slower than C.  It is a fair call that
some early implementations of C++ (particularly while the standard was
in draft and evolving) were not particularly efficient.  But that has
changed, now that there is a standard and compiler writers have had
a chance to address shortcomings of earlier implementations.

There are some aspects of C++ that carry a performance overhead.
No question.  But, doing the same things in C would also carry a
performance overhead and that needs to be coupled with the fact
that the programmer must manually craft solutions to address the
same problem.   One obvious example is virtual function dispatch,
which essentially means that the choice of a function to call is based
on the type of an object.   It carries an overhead in either run time
or space:  each data structure must carry a pointer to the function
that must be called, or there must be a run-time mechanism that
examines the type of object and then determins what object to
run.    If such a facility is needed, then it is available in C++ but
must be explicitly coded in C.   The hand coded solutions would
carry overheads as well.

>
> in C there arent the simplest things present like constants, each struct
and
> enum have to be prefixed with "struct" and "enum". iam sure there is much
> more.

I thought C supported constants, but never mind (willing to stand
corrected).

The other points (eg struct and enumerted types needing to carry the
keywords) are stylistic issues.  There are arguments in favour of having to
use the keywords (eg making it explicit what is actually going on) versus
not
(eg not having to know what is going on).

>
> i don't get it why people program in C and faking OOP features(function
> pointers in structs..) instead of using C++. are they simply masochists or
> is there a logical reason?
>

In my experience, this observation is incorrect.   There are some older
codes
in C that essentially replicated OO features (eg calling a function based on
type of object) but these are not extremely common, and most of them
preceded languages like C++ that support OO features.

The basic fact is that use of OO is a design trade-off.  Object oriented
approaches
come with a series of trade-offs, in design, coding, and run time
performance.
There are other ways of designing systems, that also have trade-offs.  Some
of
those design approaches are quite amenable to implementation in C.  The
basic
result is that people who work on problems that aren't well suited to an OO
solution will often use other design approaches.  Those people are often
quite
justified in using C, as they don't need to exploit additional features of
C++.
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
nospam1890 (18)
10/6/2003 6:50:00 PM
"cody" <NO.SPAM.deutronium@gmx.net> writes:

>no this is no trollposting and please don't get it wrong but iam very
>curious why people still use C instead of other languages especially C++.

One important advantage of C is that C is significantly simpler than C++.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
fjh (268)
10/6/2003 6:50:03 PM
cody wrote:

> no this is no trollposting

I will try to bear that in mind.

> and please don't get it wrong but iam very
> curious why people still use C instead of other languages especially C++.
> 
> i heard people say C++ is slower than C but i can't believe that.

Believe it. Or test it. For your test to be significant, be sure you use a 
wide range of test programs, equivalently written in C and C++ (don't 
bother with the so-called "C subset" of C++ - either write in C or write in 
C++), on a wide variety of programs. Tabulate your results. (If they're 
worth a damn, they're probably worth publishing, perhaps on your Web site 
in the first instance.)

> in
> pieces of the application where speed really matters you can still use
> "normal" functions or even static methods which is basically the same.

Suck it and see.

> in C there arent the simplest things present like constants,


int main(void)
{
  const int new = 6; /* I rest my case */
  return 0;
}

> each struct
> and enum have to be prefixed with "struct" and "enum".

Poor baby.

> iam sure there is
> much more.

Yes, there is. C is simple, portable, and very very fast. Those are 
important qualities.

> i don't get it why people program in C and faking OOP features(function
> pointers in structs..) instead of using C++. are they simply masochists or
> is there a logical reason?

There is a logical reason. Encapsulation is a great idea for some projects 
(not all, of course), so why not use it (when appropriate)? Note, also, 
that a C program such as you describe doesn't "fake OOP features" - rather, 
it uses OOP to achieve its objectives. That C, which was /not/ designed to 
do OOP, /can/ be used for OOP is quite remarkable in itself. Having said 
that, I am very much of the "if you want OOP and C++ is available, use C++" 
school - but note that C++ is /not/ available on anything like as many 
target platforms as C is.

> 
> i feel C has to benefit against C++.

It does have three important advantages. It's simple, portable, and fast.

-- 
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
dontmail (1886)
10/6/2003 6:50:12 PM
cody wrote:
> i heard people say C++ is slower than C but i can't believe that. in pieces
> of the application where speed really matters you can still use "normal"
> functions or even static methods which is basically the same.

There is both a speed and size penalty for using C++ where
pain C would do.  The penalty isn't as bad as it used to be.

> in C there arent the simplest things present like constants, each struct and
> enum have to be prefixed with "struct" and "enum". iam sure there is much
> more.

C has constants.  We usually use typedefs rather than struct
and enum tags.

> i don't get it why people program in C and faking OOP features(function
> pointers in structs..) instead of using C++. are they simply masochists or
> is there a logical reason?

It's very rare for C programs to "fake OOP features".

One of C's main benefits is that it is easier to implement
and has simpler run-time support requirements.  This makes
it especially suited to embedded processors, for example.
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
DAGwyn (797)
10/6/2003 6:50:21 PM
cody wrote:

> no this is no trollposting and please don't get it wrong but iam very
> curious why people still use C instead of other languages especially C++.

C is available on nearly every machine. C++ is not. OOP is a nice thing 
but not for everything. 

"With OOP we can solve problems very elegant, we wouldn't have without 
it."

While the above statement is not entirely true, there is some truth in it. 
;)

/Sven

-- 
Remove the "-usenet" part of the mail address to mail me. The Gibe/Swen
worm forced me to shutdown my usenet email address for a limited time.
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
10/6/2003 6:50:28 PM
On Sun, 5 Oct 2003, cody wrote:

> no this is no trollposting and please don't get it wrong but iam very
> curious why people still use C instead of other languages especially C++.
>
> i heard people say C++ is slower than C but i can't believe that. in pieces
> of the application where speed really matters you can still use "normal"
> functions or even static methods which is basically the same.
>
> in C there arent the simplest things present like constants, each struct and
> enum have to be prefixed with "struct" and "enum". iam sure there is much
> more.
>
> i don't get it why people program in C and faking OOP features(function
> pointers in structs..) instead of using C++. are they simply masochists or
> is there a logical reason?
>
> i feel C has to benefit against C++.

There are a few reasons I would use C over C++.

1) Not all environments have a good C++ compiler.

There are still some situations where finding a good C++ compiler is just
not possible. Last time I checked they were still working on an embedded
C++ standard because the C++ standard does not address the needs of the
embedded world.

2) There is a certain amount of overhead with learning and using C++ that
   might not be necessary for specific projects.

If I am writing a program that I can keep most, if not all, of the project
in my head then why would I want to use C++? Especially if I have been
programming C for over 20 years.

3) C language is closer to assembly language.

If I am trying to squeak out every last cycle I can out of an application
or if timing is critical I would write a project in C language, set a
switch to keep the intermediate assembly source files and then replace the
C source with assembly source but only for those functions that need to be
hand tweaked. In situations where I cannot do this, I can often play with
my C language until I get the same results as programming in assembly
language.

Bottom line, I use C with I don't need everything C++ offers. It is sort
of the same reason they still teach Newtonian physics. Why doesn't
everyone use Einsteinian physics? Because Newtonian is easier and is good
enough for today to today physics.

-- 
Send e-mail to: darrell at cs dot toronto dot edu
Don't send e-mail to vice.president@whitehouse.gov
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
darrell
10/6/2003 6:51:04 PM
In article <clcm-20031005-0008@plethora.net>,
 "cody" <NO.SPAM.deutronium@gmx.net> wrote:

> no this is no trollposting and please don't get it wrong but iam very
> curious why people still use C instead of other languages especially C++.

C++ *is* C.  Worse, it is an improper superset of C.  Of all the things 
you might advocate as an "alternative" to ANSI C, C++ is probably the 
worst.

> i don't get it why people program in C and faking OOP features(function
> pointers in structs..) instead of using C++.

This is laughable.  It is C++ that is best known for faking OO features!  
If you're looking for an OO extension to C that is actually well done, 
one that is additionally a proper superset of C, you should be looking 
at Objective-C.  But that's still in the C family.  If you don't want C, 
don't use C; don't use C++ and pretend you're not using C, though.
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
10/6/2003 6:51:07 PM
cody wrote:
> in C there arent the simplest things present like constants, each struct and
> enum have to be prefixed with "struct" and "enum". 

Neither of these is really true.  "Real" integer constants can be
created using enums (or "#define"), and you can use "typedef" to avoid
having to write "struct" or "enum" everywhere if it bothers you, e.g.:

  typedef enum { false, true } bool;

Jeremy.
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
jeremy63 (294)
10/6/2003 6:51:10 PM
Hi all

My reason is simple: I have no time at the moment to learn C++ and C fits my
needs.

Well, I actually know something about C++, but I feel that you need a lot of
knowledke on C++ to be able to develop "big programs", I mean that there are
lots of things that need to be well understood, otherwise you are dead (you
know, lot of errors you can't find...)

"cody" <NO.SPAM.deutronium@gmx.net> escribi� en el mensaje
news:clcm-20031005-0008@plethora.net...
> no this is no trollposting and please don't get it wrong but iam very
> curious why people still use C instead of other languages especially C++.
>
> i heard people say C++ is slower than C but i can't believe that. in
pieces
> of the application where speed really matters you can still use "normal"
> functions or even static methods which is basically the same.
>
> in C there arent the simplest things present like constants, each struct
and
> enum have to be prefixed with "struct" and "enum". iam sure there is much
> more.
>
> i don't get it why people program in C and faking OOP features(function
> pointers in structs..) instead of using C++. are they simply masochists or
> is there a logical reason?
>
> i feel C has to benefit against C++.
>
> --
> cody
>
> [Freeware, Games and Humor]
> www.deutronium.de.vu || www.deutronium.tk
> --
> comp.lang.c.moderated - moderation address: clcm@plethora.net
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
10/6/2003 6:51:15 PM
cody wrote:

> I am very curious about why people still use C
> instead of other languages, especially C++.

Fear of change.

> I heard people say C++ is slower than C but I can't believe that.

Neither can I.  In fact, I know it isn't true.
No one has *ever* shown an example of C code
which is faster that C++ (or slower than C code)
that actually performed the same computation.
The speed of the code emitted by either a C or C++ compiler
depends *only* upon the quality of the the compiler.

> In pieces of the application where speed really matters,
> you can still use "normal" [C] functions or even static methods
> which is basically the same.

It doesn't matter.

> In C, there aren't the simplest things present like constants,

C supports the const keyword now.

> each struct and enum must be prefixed with "struct" and "enum".

	typedef struct X {
	  // public data members
	  } X;

in C is the same as

	struct X {
	  // public data members
	  };

in C++.

> I am sure there is much more.
> 
> I don't get it why people program in C and faking OOP features
> (function pointers in structs..) instead of using C++.
> Are they simply masochists?  Or is there a logical reason?
> 
> I feel C has to benefit against C++.

They are *not* faking OOP features.
This is just the way that C programmers wrote object oriented programs
before the C++ programming language was introduced.
The C++ programming just makes object oriented programming
easier, more reliable and more portable -- that's all that
*any* so called object oriented programming language can do.
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
10/6/2003 6:51:16 PM
cody wrote:

> no this is no trollposting and please don't get it wrong but iam very
> curious why people still use C instead of other languages especially C++.
> 
> i heard people say C++ is slower than C but i can't believe that. in pieces
> of the application where speed really matters you can still use "normal"
> functions or even static methods which is basically the same.

C++ is not slower than C.  Many early C++ compilers would translate C++
to C, then proceed as a C compiler.


> in C there arent the simplest things present like constants, each struct and
> enum have to be prefixed with "struct" and "enum". iam sure there is much
> more.

No, this is just a typing issue.  All those things disappear during code
execution.  One can use the typedef facility for making abbreviations.


> i don't get it why people program in C and faking OOP features(function
> pointers in structs..) instead of using C++. are they simply masochists or
> is there a logical reason?

Many people have to deal with legacy code.  Some OOP features have been
coded in C and have been tested.  Converting them to C++ means more
development and testing time.

> 
> i feel C has to benefit against C++.
> 
> --
> cody

Each language has its thorns and roses.  I just asked if I could use C++
on our next embedded project and the management said no.

-- 
Thomas Matthews

C++ newsgroup welcome message:
          http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq:   http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
          http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
     http://www.josuttis.com  -- C++ STL Library book
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
10/6/2003 6:51:20 PM
In article <clcm-20031005-0008@plethora.net>, NO.SPAM.deutronium@gmx.net 
(cody) wrote:

> no this is no trollposting and please don't get it wrong but iam very
> curious why people still use C instead of other languages especially 
> C++.

There are many reasons; here are some that I've encountered:

A very large percentage of the world's programming is maintenance and 
upgrading of existing code, rather than writing new stuff. And trying to 
change a large program written in C into C++ is not simple: in fact, it 
tends to involve a complete redesign. When you have a codebase that's 
taken several hundred man-years to write, and your current manpower 
resources are just about keeping up with the maintenance and upgrades, a 
re-design - which will inevitably introduce loads of new problems - is not 
a welcome prospect, especially when the actual benefits are less than 
clear. 

There are bunches of tasks for which C++ is not well suited. They include:
* Serious low-level programming, where it gets in the way too much, and 
  wants too much control. 
* Simple proof-of-concept tasks that consist of hooking some OS features
  together. I do this a lot on Windows. The more obscure OS calls don't 
  have C++ interfaces, and writing wrappers for them is more complicated 
  than just using them on their own terms. 
  
It can be much worse than C for incomprehensibility. Easily. It just 
requires someone who's got carried away with his own cleverness. Nesting a 
few levels of templates and a factory or two can easily get C++ code 
beyond any normal C level of incomprehensibility, with the difference that 
the people who've written it feel proud of their own insight into the 
language, and feel that they're writing positively good code. In spite of 
the fact that it won't compile on the next version of the compiler, and 
they can't understand it themselves six months later. 

And some people just don't like C++. This can happen to almost anything, 
and isn't useful in evaluating it - unless almost everyone dislikes it. 

--- 
John Dallman                                     jgd@cix.co.uk
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
jgd
10/6/2003 6:51:23 PM
"Glen Herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:747gb.415050$2x.141321@rwcrnsc52.ops.asp.att.net...
> Well, some people consider C as a glorified assembler.  It isn't quite
that,
> especially as it has changed over the years, but not so far off.

Yes, let's talk about that. When I code in C for my favorite platform I do
tend to "see" the generated assembly in my head. The picture gets bigger and
changes too as I gain more experience, but I do think a lot more like that
machine when programming in C. When I do C++ this is a lot less, I tend to
think in terms of objects and generated objects (templates). Can't decide
what I like better, I keep switching back and forth between the two.

consider this:
size_t i = strcspn(s, "\n");
std::string::size_type i = s.find_first_of("\n");

In my mind strcspn does it a lot simpler than find_first_of.

Or even simpler.
strlen(s);
s.length();

What does s.length() example do? Do strlen somewhere? (some implementations
do). Keep track of the length?
You just give up a lot of control with C++.


0
i1848 (53)
10/6/2003 6:56:32 PM
On Mon, 06 Oct 2003 14:22:06 -0400, Eric Sosman wrote:


>     It'll be right next to the place reserved for people who
> sling mud anonymously.
> 
>     If your criticism has merit 

	Notice that it is a personal opinion, based on my experience. Yours might
differ, and you are welcome to that.

> (I know too little of C++ to
> evaluate it), have the courage to put your name to it.  

	What name? How do we know, anyway, that any names at the end of a post
correspond to the poster? Is it going to make you happier if I sign as
James S. Taylor? Or as Madhusudan Patel? Or as Pierre Mattera? Can you
tell if any of those is my real name? What difference does it make?

> If the courage is lacking, what are we to make of your confidence in
> your own opinion? 

	Make whatever you want. 

> And if you have so little confidence in it, why bother us with it?

	Wrong conclusion from the wrong premise. You can't conclude anything
from my posting about my relative lack of confidence in any anything.

> May the next chimney you slide down have a roaring fire
> at the bottom.

	Hmm... We touched a raw nerve here :-)

0
santa6300 (7)
10/6/2003 7:35:08 PM
"E. Robert Tisdale" <E.Robert.Tisdale@jpl.nasa.gov> writes:

| > In C, there aren't the simplest things present like constants,
| 
| C supports the const keyword now.

but variables of integral types declared with the "const" keyword and
initialized with literals do not qualify as "integral constant expressions".
E.g.

   const int nine = 9;

   enum { NINE = nine };	// ERROR in C, OK in C++

-- Gaby
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
dosreis (12)
10/6/2003 8:11:00 PM
Santa Claus is a troll.  Please ignore him.

0
10/6/2003 8:12:44 PM
"E. Robert Tisdale" <E.Robert.Tisdale@jpl.nasa.gov> wrote in message
news:3F81CCBC.4060202@jpl.nasa.gov...
> Santa Claus is a troll.  Please ignore him.

I always thought he was an elf. :-)

-Mike


0
mkwahler (3821)
10/6/2003 9:19:13 PM
cody wrote:

>>I would argue that exceptions are "goto's on steroids". Since exceptions
>>are allowed to cross function-call boundaries, execution flow becomes
>>very non-transparant - at least to me!

> where the exception goes is well defined, it cannot go somewhere, it goes
> simply down the callstack which is more readable than gotos, imo.

"Simply down the callstack" is a bit of an oxymoron - this has some 
severe and rather complicated consequences in case the callstack that is 
being partially pop()ed contains partially executed 
constructor/destructor calls, for example. Of course it is possible to 
handle this properly, my only point is that it is complicated. Too 
complicated for me, anyway - but of course you may be one of that rare 
breed of programmers that understands what is going on in these cases. 
If so: congratulations, and more power to you! :-)

The nice thing about exceptions is that the code throwing it shouldn't 
care who catches it. This does not blend well with my preferred way of 
working where I can keep track of the execution flow. Subjective.

Exception handling in C++ can result in code that is significantly 
bloated and slower, by the way. The C++ compiler needs to insert 
instrumentation code to handle exceptions in any function that can 
possibly be the target of an exception, as far as I understand.

> but doesn't c support structured exception handling too? i heard something
> like that.

Not that I'm aware of. You do have setjmp/longjmp which allows to 
effectively save and restore the stack state, and this can be used to 
implement something similar, but that's it, as far as I know.

>>[Non-portable templates]

> that is not true. name me one example where semantics are different on
> different compilers!

My latest try on doing something with templates was with a C++ compiler 
for a Trimedia embedded processor, which failed to compile a rather 
simple program with a template class, giving me an internal compiler 
error. (this was about 2 years ago when I was graduating - can't 
reproduce the program I'm afraid). Back in those days, compilers were 
rife with problems in their template implementations.

I just did a search on Google for recent reports on this and (apart from 
some rants on VC++ 6.0 templates), I get relatively little results. 
Perhaps people have cleaned up their act (I don't know), so I guess it's 
only fair to retract this statement since I cannot back it up with 
anything other than old experience. My apologies... I just hope somebody 
could step in at this point and give a couple of relevant examples to 
prove me right after all.

> templates are a very very useful and mighty feature in c++. however it is a
> bit difficult to use.

On that we agree.

> yes and no. c++ should not be used for everything. gui's should not be made
> with c++.

Fact is that a very large percentage of GUIs _is_ made with C++.

> for libraries, c++ is good because it is very fast and flexible thanks to
> templates.

Except that it is difficult to link such a library with proprietary 
software - these usually only support linking to C code. This severely 
limits the usefulness of such libraries.

> you say the language design has failed, but do you have a better idea how it
> can be solved?

No. I'm waiting for people smarter than I am to come up with a new 
paradigm :-)

> imo for high performance applications there is no better way than c++. since
> c lacks of templates, c++ would be the choice for me.

I'm comfortable with that. People differ, that's generally a good thing. 
I haved C++ also on occasion, for a rather small self-contained data 
processing application that just cried out for a (simple) class 
hierarchy. It depends a lot on the type of project, I suppose.

>> [Stroustrup]

> right i cannot imagegine that somebody really and completely understands the
> STL.

Oh I can imagine that. I just hope these people don't expect the same of me!

Best regards, Sidney

0
sidney (345)
10/6/2003 9:44:47 PM
On Mon, 06 Oct 2003 03:00:01 +0200, in comp.lang.c , Sidney Cadot
<sidney@jigsaw.nl> wrote:

(actually I'm replying to Cody - my server lost his message)

>> no this is no trollposting and please don't get it wrong but iam very
>> curious why people still use C instead of other languages especially C++.

I missed your original post, but as far as I'm concerned, the answer
is "occam's razor". 
When I'm writing a simple tool to process raw data from one stream to
another, its faster (for me) to /write/ it in C, even tho C++ probably
has zero or little runtime penalty. 

>> i heard people say C++ is slower than C but i can't believe that. in pieces
>> of the application where speed really matters you can still use "normal"
>> functions or even static methods which is basically the same.

But whats the point of using C++ if all you do is "dumb it down" till
it matches C? 

>> in C there arent the simplest things present like constants, each struct and
>> enum have to be prefixed with "struct" and "enum". iam sure there is much
>> more.

C has constants. I'm not sure what your point is about prefixing
types. Don't you like knowing what type a type is? If so, use
typedefs. 

>> i don't get it why people program in C and faking OOP features(function
>> pointers in structs..) instead of using C++. are they simply masochists or
>> is there a logical reason?

IMHO only a theoretical scientist or someone without a C++ compiler
would fake up C++'s OOP with C. If you want OOP, then use C++. OR a
language that does it even better. 


-- 
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
0
markmcintyre (4555)
10/6/2003 10:03:07 PM
James Kuyper wrote:

>>[linking to proprietary sw]
> 
> It seems to me that only this last issue truly addresses the question.
> In all of your other issues, you're complaining about features of C++
> that you don't have to use if you don't want to.

To a certain extent you are right of course, but the original question 
mentioned 'faking' OOP-techniques in C quite explicitly, so I answered 
under the assumption that cody's focus was on using OOP from either C or 
C++. I really do feel that a great deal of discomfort of C programmers 
with C++ is that they aren't particularly fond of OOP programming for a 
variety of reasons - I know that's true for me. In my mind at least, C++ 
equals C plus syntactic sugar plus classes plus exceptions plus 
templates. Surely you can use C++ without using the complexities brought 
in by {classes, exceptions, templates}. But then, why not stick to C99?

By the way I am quite comfortable with other people having a different 
opinion on this, I really think that the fun in programming is largely 
dependent on one's comfortability with one's choice of language. I know 
people who love coding in C++, Java, Lisp, Prolog, Haskell,... fine for 
me. I love C (and a bit of Python nowadays), but there's no need to turn 
this into a holy war. When somebody asks me 'why do you prefer X over Y' 
  I think I can make a case on technical merits but reality is never 
black or white.

> I personally use C or C++ for the simple reason that our company's
> contract with NASA requires us to deliver code for either Fortran 77,
> Fortran 90, C90 (more precisely, C94), or Ada.

Interesting! I code for ESA, and for my current project we were 
basically free to choose. Could've gone with Java or C++ as far as ESA 
was concerned, but since it was a requirement to link the library to IDL 
and Matlab we decided to stick with C94 on technical merits. No regrets.

> I like C because it's a simpler language than C++, and because I've
> got a lot more experience with it. However, I love complicated things,
> and I see all kinds of interesting features in C++ that I'd love to
> have time to play with.

As for myself I'd like to have some more time to play with functional 
languages, I like the compactness with which some things can be 
expressed. I tend to think of OOP and C++ as extensions to the 
imperative paradigm, for that reason I think there's more to learn for 
me by studing a functional language.

> However, as long as all of my C++ programming
> is done at home, rather than at work, I'm never going to build up much
> experience with it. I'm hpping that the next project I work on allows
> both C++ and C99 (which also has some neat new features that aren't in
> C++).

I can imagine that could be fun. And perhaps that would be a good excude 
for brushing up those generic programming skills, from what I gather 
from Google they're really portable nowadays! :-)

Best regards,

   Sidney

0
sidney (345)
10/6/2003 10:12:51 PM
James Kuyper wrote:

> [...]

Oops! I same to have had the wrong message selected when trying to reply 
to you. Please check my 0:12am message to Mark McIntyre for a response.

I beg everyone's pardon!

Sidney

0
sidney (345)
10/6/2003 10:17:52 PM
"E. Robert Tisdale" wrote:
> 
> Santa Claus is a troll.  Please ignore him.

So's Tisdale. What's your point?




Brian Rodenborn
0
first.last4 (288)
10/6/2003 10:23:58 PM
Mike Wahler wrote in article
<l%kgb.329$av5.132@newsread3.news.pas.earthlink.net>:

> I always thought he was an elf. :-)

No, he's an aout.

-- 
Todd Stephens
ICQ# 3150790
"A witty saying proves nothing." -Voltaire
0
Todd
10/6/2003 11:24:48 PM
Greetings to the group. I'm reading the FAQ and K&R and monitoring here, 
trying to get a handle on the transition from shell programming to C.

From what I've read, I honestly don't see the need for anything BUT C
and the simple functionality of the high-level programming provided by
any decent shell. (Okay, a teeny weenie bit of assembly language too :-)

Hope I am not out-of-line here.

By-the-way, is there anyplace I can get the entire FAQ as a tarball or
something? 

-- 
Later, Alan C
You can find my email address at the website: contact.html
take control of your mailbox ----- elrav1 ----- http://tinyurl.com/l55a
0
zzzzzz (1966)
10/6/2003 11:59:42 PM
"Alan Connor" <zzzzzz@xxx.yyy> wrote in message
news:Olngb.438$av5.302@newsread3.news.pas.earthlink.net...
> Greetings to the group. I'm reading the FAQ and K&R and monitoring here,
> trying to get a handle on the transition from shell programming to C.
>
> From what I've read, I honestly don't see the need for anything BUT C
> and the simple functionality of the high-level programming provided by
> any decent shell. (Okay, a teeny weenie bit of assembly language too :-)

Which language(s) you find useful will of course depend
upon the application domain(s).  Certain languages are more
suited to particular tasks than others.  If C, shell scripting
and assembly is all you need to get the job done, nothing
wrong with that.

>
> Hope I am not out-of-line here.
>
> By-the-way, is there anyplace I can get the entire FAQ as a tarball or
> something?

The FAQ itself (at http://www.eskimo.com/~scs/C-faq/top.html)
has links to such.  Scan the first few paragraphs for the
phrase "other versions".

HTH,
-Mike


0
mkwahler (3821)
10/7/2003 1:19:23 AM
On Tue, 07 Oct 2003 01:19:23 GMT, Mike Wahler <mkwahler@mkwahler.net> wrote:
> 
> 
> "Alan Connor" <zzzzzz@xxx.yyy> wrote in message
> news:Olngb.438$av5.302@newsread3.news.pas.earthlink.net...
>> Greetings to the group. I'm reading the FAQ and K&R and monitoring here,
>> trying to get a handle on the transition from shell programming to C.
>>
>> From what I've read, I honestly don't see the need for anything BUT C
>> and the simple functionality of the high-level programming provided by
>> any decent shell. (Okay, a teeny weenie bit of assembly language too :-)
> 
> Which language(s) you find useful will of course depend
> upon the application domain(s).  Certain languages are more
> suited to particular tasks than others.  If C, shell scripting
> and assembly is all you need to get the job done, nothing
> wrong with that.
> 
>>
>> Hope I am not out-of-line here.
>>
>> By-the-way, is there anyplace I can get the entire FAQ as a tarball or
>> something?
> 
> The FAQ itself (at http://www.eskimo.com/~scs/C-faq/top.html)
> has links to such.  Scan the first few paragraphs for the
> phrase "other versions".
> 
> HTH,
> -Mike
> 
> 

Thanks Mike. Don't know how I missed that. Got it now from the FTP site.

Long...Scary  :-)  

Thanks to Steve Summit.

-- 
Later, Alan C
You can find my email address at the website: contact.html
take control of your mailbox ----- elrav1 ----- http://tinyurl.com/l55a
0
zzzzzz (1966)
10/7/2003 2:14:29 AM
Alan Connor wrote:

> From what I've read, I honestly don't see the need for anything BUT C

C is fine for all your programming needs (if you like C, that is!), right up 
until you have to do something that doesn't work in much the same way on 
all machines. At that point, you have to start using platform extensions. 
But that's okay, because any platform extension worth its salt has C 
bindings anyway.

-- 
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
0
dontmail (1886)
10/7/2003 3:24:01 AM
E. Robert Tisdale wrote:

> Santa Claus is a troll.  Please ignore him.

I think I'll have to disagree with you there. My children have seen Santa 
Claus on quite a few occasions (typically in fairytale grotto-like 
surroundings), so I have good observational evidence w.r.t. Sant Claus (or 
Father Christmas, as my children call him). My experts tell me that "he is 
short and fat and jolly"; "he has a long white beard"; "he wears a big red 
coat with gold buttons"; "he gives out presents"; "he has twinkly eyes", 
and "he drives a very special sleigh with lots of reindeer"; "he has lots 
of elves to help him". These are not characteristics typically associated 
with trolls; trolls tend to be taller and more vicious, and somehow don't 
manage to get quite the same twinkle into their eye.

Now if you'd said that ***E. Robert Tisdale*** is a troll, I think you'd 
have been closer to the mark.

-- 
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
0
dontmail (1886)
10/7/2003 3:41:05 AM
On Tue, 7 Oct 2003 03:24:01 +0000 (UTC), Richard Heathfield <dontmail@address.co.uk.invalid> wrote:
> 
> 
> Alan Connor wrote:
> 
>> From what I've read, I honestly don't see the need for anything BUT C
> 
> C is fine for all your programming needs (if you like C, that is!), right up 
> until you have to do something that doesn't work in much the same way on 
> all machines. At that point, you have to start using platform extensions. 
> But that's okay, because any platform extension worth its salt has C 
> bindings anyway.
> 

Good to know that. I aspire to a Linux distro that uses nothing but straight
ANSI C and shell scripts.

-- 
Later, Alan C
You can find my email address at the website: contact.html
take control of your mailbox ----- elrav1 ----- http://tinyurl.com/l55a
0
zzzzzz (1966)
10/7/2003 3:59:15 AM
Alan Connor <zzzzzz@xxx.yyy> writes:

> On Tue, 7 Oct 2003 03:24:01 +0000 (UTC), Richard Heathfield <dontmail@address.co.uk.invalid> wrote:
> > 
> > 
> > Alan Connor wrote:
> > 
> >> From what I've read, I honestly don't see the need for anything BUT C
> > 
> > C is fine for all your programming needs (if you like C, that is!), right up 
> > until you have to do something that doesn't work in much the same way on 
> > all machines. At that point, you have to start using platform extensions. 
> > But that's okay, because any platform extension worth its salt has C 
> > bindings anyway.
> > 
> 
> Good to know that. I aspire to a Linux distro that uses nothing but straight
> ANSI C and shell scripts.

I don't believe it's possible to implement typical shells in
straight ANSI C without extensions, so this could be a
problematic goal.

-Micah

0
micah2 (555)
10/7/2003 5:23:36 AM
On Tue, 07 Oct 2003 03:59:15 +0000, Alan Connor wrote:

> Good to know that. I aspire to a Linux distro that uses nothing but straight
> ANSI C and shell scripts.

 Why shell scripts, just install tcc and you can just do...

#! /bin/tcc -run
#include <stdio.h>

int main(void)
{
    puts("Hello World");
    return 0;
}

.... :)

-- 
James Antill -- james@and.org
Need an efficient and powerful string library for C?
http://www.and.org/vstr/

0
10/7/2003 5:37:21 AM
On 06 Oct 2003 22:23:36 -0700, Micah Cowan <micah@cowan.name> wrote:
> 
> 
> Alan Connor <zzzzzz@xxx.yyy> writes:
> 
>> On Tue, 7 Oct 2003 03:24:01 +0000 (UTC), Richard Heathfield <dontmail@address.co.uk.invalid> wrote:
>> > 
>> > 
>> > Alan Connor wrote:
>> > 
>> >> From what I've read, I honestly don't see the need for anything BUT C
>> > 
>> > C is fine for all your programming needs (if you like C, that is!), right up 
>> > until you have to do something that doesn't work in much the same way on 
>> > all machines. At that point, you have to start using platform extensions. 
>> > But that's okay, because any platform extension worth its salt has C 
>> > bindings anyway.
>> > 
>> 
>> Good to know that. I aspire to a Linux distro that uses nothing but straight
>> ANSI C and shell scripts.
> 
> I don't believe it's possible to implement typical shells in
> straight ANSI C without extensions, so this could be a
> problematic goal.
> 
> -Micah
> 

Most pipe dreams are "problematic" :-) 

I really don't know what you mean by "extensions", although I will read up
on it in the FAQ asap.

But modern shells have all sorts of features that I could do perfectly well
without, that used to be done with independent utilities.

-- 
Later, Alan C
You can find my email address at the website: contact.html
take control of your mailbox ----- elrav1 ----- http://tinyurl.com/l55a
0
zzzzzz (1966)
10/7/2003 5:59:13 AM
On Tue, 07 Oct 2003 01:37:21 -0400, James Antill <james-netnews@and.org> wrote:
> 
> 
> On Tue, 07 Oct 2003 03:59:15 +0000, Alan Connor wrote:
> 
>> Good to know that. I aspire to a Linux distro that uses nothing but straight
>> ANSI C and shell scripts.
> 
>  Why shell scripts, just install tcc and you can just do...
> 
> #! /bin/tcc -run
> #include <stdio.h>
> 
> int main(void)
> {
>     puts("Hello World");
>     return 0;
> }
> 
> ... :)
> 
> -- 
> James Antill -- james@and.org
> Need an efficient and powerful string library for C?
> http://www.and.org/vstr/
> 

Err, I couldn't a reference to tcc in the FAQ, the index to K&R2, and there's
no man page for it on my box....Nor is it in my list of available Debian
packages....

And I can't get on the internet for a while, so I give....

(but If I am reading that script correctly, it sounds like a rather more
limited shell than I had on my mind....The original sh would probably do
the trick, maybe the updated version called ash, wihich is a FreeBSD project
if I remember correctly. Tomsrtbt uses it (entire os on a floppy) and it's
pretty good. Got read, set,if,for,until,while,case, commandline history and 
completiion and so forth.)

(:-)

-- 
Later, Alan C
You can find my email address at the website: contact.html
take control of your mailbox ----- elrav1 ----- http://tinyurl.com/l55a
0
zzzzzz (1966)
10/7/2003 6:22:08 AM
"Alan Connor" <zzzzzz@xxx.yyy> wrote in message
news:RCsgb.1158$dn6.70@newsread4.news.pas.earthlink.net...
> On 06 Oct 2003 22:23:36 -0700, Micah Cowan <micah@cowan.name> wrote:
> >
> >
> > Alan Connor <zzzzzz@xxx.yyy> writes:
> >
> >> On Tue, 7 Oct 2003 03:24:01 +0000 (UTC), Richard Heathfield
<dontmail@address.co.uk.invalid> wrote:
> >> >
> >> >
> >> > Alan Connor wrote:
> >> >
> >> >> From what I've read, I honestly don't see the need for anything BUT
C
> >> >
> >> > C is fine for all your programming needs (if you like C, that is!),
right up
> >> > until you have to do something that doesn't work in much the same way
on
> >> > all machines. At that point, you have to start using platform
extensions.
> >> > But that's okay, because any platform extension worth its salt has C
> >> > bindings anyway.
> >> >
> >>
> >> Good to know that. I aspire to a Linux distro that uses nothing but
straight
> >> ANSI C and shell scripts.
> >
> > I don't believe it's possible to implement typical shells in
> > straight ANSI C without extensions, so this could be a
> > problematic goal.
> >
> > -Micah
> >
>
> Most pipe dreams are "problematic" :-)
>
> I really don't know what you mean by "extensions", although I will read up
> on it in the FAQ asap.

"Extensions" are additional nonstandard language constructs
(e.g. keywords, modified versions of standard functions, etc.)
which an implementation might provide for access to platform
specific feature of the host system.  C can also be 'extended'
by supplying platform specific libraries with a C implementation,
e.g. the Windows API supplied with compilers for Windows.

-Mike


0
mkwahler (3821)
10/7/2003 6:48:16 AM
Richard Heathfield wrote:

> E. Robert Tisdale wrote:
> 
> 
>>Santa Claus is a troll.  Please ignore him.
> 
> 
> I think I'll have to disagree with you there. My children have seen Santa 
> Claus on quite a few occasions (typically in fairytale grotto-like 
> surroundings), [...]

Well now, that's where they traditionally lurk, isn't it? :-)

Regards, Sidney

0
sidney (345)
10/7/2003 7:01:08 AM
On Tue, 07 Oct 2003 06:48:16 GMT, Mike Wahler <mkwahler@mkwahler.net> wrote:
>> >
>> > I don't believe it's possible to implement typical shells in
>> > straight ANSI C without extensions, so this could be a
>> > problematic goal.
>> >
>> > -Micah
>> >
>>
>> Most pipe dreams are "problematic" :-)
>>
>> I really don't know what you mean by "extensions", although I will read up
>> on it in the FAQ asap.
> 
> "Extensions" are additional nonstandard language constructs
> (e.g. keywords, modified versions of standard functions, etc.)
> which an implementation might provide for access to platform
> specific feature of the host system.  C can also be 'extended'
> by supplying platform specific libraries with a C implementation,
> e.g. the Windows API supplied with compilers for Windows.
> 
> -Mike
> 
> 

Doesn't sound like any sort of massive corruption of C to me. 

Thanks much. 

-- 
Later, Alan C
You can find my email address at the website: contact.html
take control of your mailbox ----- elrav1 ----- http://tinyurl.com/l55a
0
zzzzzz (1966)
10/7/2003 7:19:20 AM
Alan Connor <zzzzzz@xxx.yyy> wrote in message news:<Olngb.438$av5.302@newsread3.news.pas.earthlink.net>...
> Greetings to the group. I'm reading the FAQ and K&R and monitoring here, 
> trying to get a handle on the transition from shell programming to C.
> 
> From what I've read, I honestly don't see the need for anything BUT C
> and the simple functionality of the high-level programming provided by
> any decent shell. (Okay, a teeny weenie bit of assembly language too :-)
> 
> Hope I am not out-of-line here.
> 
> By-the-way, is there anyplace I can get the entire FAQ as a tarball or
> something?

Sometimes i wonder if *nix programmers will ever use anything but c
and shell... (ah, of course they use other languages - but sometimes
it doesn't seemt that way).

You could use C for everything, but the context of the programmer &
the project changes so other languages are consider by some to better
able to express what is required.

An OOPL can be good at describing an application where object
taxonomies make sense, you may need a programmer time 'shortcut' to a
particular thing that general purpose languages would require more
time on, a typical LISP app perhaps, or want trustrable 'built in'
advanced features so as not to rely on re-inventing the wheel or
reusing third party libs - STL for instance.   Some particular tools
(e.g. kylix/delphi) are good for more quickly desiging GUI apps.   It
all crosses over, a given language's 'unique' qualities are rarely
that unique - you could probably get a shocking amount of versatility
from QuickBasic if you tried hard enough!
0
gswork (648)
10/7/2003 8:13:12 AM
On 7 Oct 2003 01:13:12 -0700, gswork <gswork@mailcity.com> wrote:
> 
> 
> Alan Connor <zzzzzz@xxx.yyy> wrote in message news:<Olngb.438$av5.302@newsread3.news.pas.earthlink.net>...
>> Greetings to the group. I'm reading the FAQ and K&R and monitoring here, 
>> trying to get a handle on the transition from shell programming to C.
>> 
>> From what I've read, I honestly don't see the need for anything BUT C
>> and the simple functionality of the high-level programming provided by
>> any decent shell. (Okay, a teeny weenie bit of assembly language too :-)
>> 
>> Hope I am not out-of-line here.
>> 
>> By-the-way, is there anyplace I can get the entire FAQ as a tarball or
>> something?
> 
> Sometimes i wonder if *nix programmers will ever use anything but c
> and shell... (ah, of course they use other languages - but sometimes
> it doesn't seemt that way).
> 
> You could use C for everything, but the context of the programmer &
> the project changes so other languages are consider by some to better
> able to express what is required.
> 
> An OOPL can be good at describing an application where object
> taxonomies make sense, you may need a programmer time 'shortcut' to a
> particular thing that general purpose languages would require more
> time on, a typical LISP app perhaps, or want trustrable 'built in'
> advanced features so as not to rely on re-inventing the wheel or
> reusing third party libs - STL for instance.   Some particular tools
> (e.g. kylix/delphi) are good for more quickly desiging GUI apps.   It
> all crosses over, a given language's 'unique' qualities are rarely
> that unique - you could probably get a shocking amount of versatility
> from QuickBasic if you tried hard enough!

Well. I think I actually followed most of that. 

Just thought it would be cool if all the software on my computer was
in only two languages. Sort of like having the same keybindings on
every app.

As for the object-oriented languages, well, I'm not into the GUI at
all. Graphics yes. Eye-candy and plastic rodents, no. 

This post ends with

:wq

:-)

-- 
Later, Alan C
You can find my email address at the website: contact.html
take control of your mailbox ----- elrav1 ----- http://tinyurl.com/l55a
0
zzzzzz (1966)
10/7/2003 8:59:17 AM
"Alan Connor" <zzzzzz@xxx.yyy> wrote in message
news:YNtgb.956$av5.563@newsread3.news.pas.earthlink.net...
> On Tue, 07 Oct 2003 06:48:16 GMT, Mike Wahler <mkwahler@mkwahler.net>
wrote:
> >> >
> >> > I don't believe it's possible to implement typical shells in
> >> > straight ANSI C without extensions, so this could be a
> >> > problematic goal.
> >> >
> >> > -Micah
> >> >
> >>
> >> Most pipe dreams are "problematic" :-)
> >>
> >> I really don't know what you mean by "extensions", although I will read
up
> >> on it in the FAQ asap.
> >
> > "Extensions" are additional nonstandard language constructs
> > (e.g. keywords, modified versions of standard functions, etc.)
> > which an implementation might provide for access to platform
> > specific feature of the host system.  C can also be 'extended'
> > by supplying platform specific libraries with a C implementation,
> > e.g. the Windows API supplied with compilers for Windows.
> >
> > -Mike
> >
> >
>
> Doesn't sound like any sort of massive corruption of C to me.

It's not.  It cannot be, since it's not part of C.  What Micah
is telling you is that some of what is needed in order to implement
a 'typical' shell is not available with only the standard C language,
thus 'extensions' are needed.  "Extension" means "addition", not
"corruption".


-Mike

>
> Thanks much.
>
> --
> Later, Alan C
> You can find my email address at the website: contact.html
> take control of your mailbox ----- elrav1 ----- http://tinyurl.com/l55a


0
mkwahler (3821)
10/7/2003 10:04:24 AM
"Alan Connor" <zzzzzz@xxx.yyy> wrote in message
news:Ffvgb.1050$av5.304@newsread3.news.pas.earthlink.net...
>
> Well. I think I actually followed most of that.
>
> Just thought it would be cool if all the software on my computer was
> in only two languages.

All of it is in *one* language.  The instruction set of the
processor (unless you have some weird multiprocessor machine
and one or more of the processors use(s) a different instruction
set from the other(s) )

Take away the source code for all the programs, and the software
is still there.

-Mike




0
mkwahler (3821)
10/7/2003 10:08:41 AM
In <Jgwgb.1060$av5.909@newsread3.news.pas.earthlink.net> "Mike Wahler" <mkwahler@mkwahler.net> writes:

>"Alan Connor" <zzzzzz@xxx.yyy> wrote in message
>news:Ffvgb.1050$av5.304@newsread3.news.pas.earthlink.net...
>>
>> Well. I think I actually followed most of that.
>>
>> Just thought it would be cool if all the software on my computer was
>> in only two languages.
>
>All of it is in *one* language.  The instruction set of the
>processor (unless you have some weird multiprocessor machine
>and one or more of the processors use(s) a different instruction
>set from the other(s) )
>
>Take away the source code for all the programs, and the software
>is still there.

That's valid for compiled languages only.  Doesn't work for interpreted
languages, where you're left with nothing after removing the source code.

Dan
-- 
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de
0
Dan.Pop (3615)
10/7/2003 11:39:33 AM
On Tue, 07 Oct 2003 10:08:41 GMT, Mike Wahler <mkwahler@mkwahler.net> wrote:
> 
> 
> "Alan Connor" <zzzzzz@xxx.yyy> wrote in message
> news:Ffvgb.1050$av5.304@newsread3.news.pas.earthlink.net...
>>
>> Well. I think I actually followed most of that.
>>
>> Just thought it would be cool if all the software on my computer was
>> in only two languages.
> 
> All of it is in *one* language.  The instruction set of the
> processor (unless you have some weird multiprocessor machine
> and one or more of the processors use(s) a different instruction
> set from the other(s) )
> 
> Take away the source code for all the programs, and the software
> is still there.
> 
> -Mike
> 
> 
> 
> 

I was speaking in practical terms. No one is going to be entering machine
language at the prompt to copy a file.

-- 
Later, Alan C
You can find my email address at the website: contact.html
take control of your mailbox ----- elrav1 ----- http://tinyurl.com/l55a
0
zzzzzz (1966)
10/7/2003 3:59:15 PM
"Alan Connor" <zzzzzz@xxx.yyy> wrote in message
news:npBgb.1227$av5.353@newsread3.news.pas.earthlink.net...
> On Tue, 07 Oct 2003 10:08:41 GMT, Mike Wahler <mkwahler@mkwahler.net>
wrote:
> >
> >
> > "Alan Connor" <zzzzzz@xxx.yyy> wrote in message
> > news:Ffvgb.1050$av5.304@newsread3.news.pas.earthlink.net...
> >>
> >> Well. I think I actually followed most of that.
> >>
> >> Just thought it would be cool if all the software on my computer was
> >> in only two languages.
> >
> > All of it is in *one* language.  The instruction set of the
> > processor (unless you have some weird multiprocessor machine
> > and one or more of the processors use(s) a different instruction
> > set from the other(s) )
> >
> > Take away the source code for all the programs, and the software
> > is still there.
> >
> > -Mike
> >
> >
> >
> >
>
> I was speaking in practical terms. No one is going to be entering machine
> language at the prompt to copy a file.

First, a 'prompt' will not typically accept machine language,
but interpret mnemonic 'commands' which are submitted to and
acted upon by the provider of such a prompt (typically
an operating system).


Dan has already pointed out my oversight regarding interpreted
languages.  But aside from that, I still stand by what I said.

I don't need to type in, e.g. printf("Hello") etc. to run a
compiled C program.

-Mike



0
mkwahler (3821)
10/7/2003 5:58:21 PM
Alan Connor <zzzzzz@xxx.yyy> wrote in message news:<Olngb.438$av5.302@newsread3.news.pas.earthlink.net>...
> Greetings to the group. I'm reading the FAQ and K&R and monitoring here, 
> trying to get a handle on the transition from shell programming to C.
> 
> From what I've read, I honestly don't see the need for anything BUT C
> and the simple functionality of the high-level programming provided by
> any decent shell. (Okay, a teeny weenie bit of assembly language too :-)
> 

No one language is universally best at everything.  There are tasks
for which C is not the best choice.  It would not be my first choice
for a graphical client, for example.
0
john_bode (637)
10/7/2003 6:12:39 PM
On Tue, 07 Oct 2003 17:58:21 GMT, Mike Wahler <mkwahler@mkwahler.net> wrote:
> 
> 
> 
> "Alan Connor" <zzzzzz@xxx.yyy> wrote in message
> news:npBgb.1227$av5.353@newsread3.news.pas.earthlink.net...
>> On Tue, 07 Oct 2003 10:08:41 GMT, Mike Wahler <mkwahler@mkwahler.net>
> wrote:
>> >
>> >
>> > "Alan Connor" <zzzzzz@xxx.yyy> wrote in message
>> > news:Ffvgb.1050$av5.304@newsread3.news.pas.earthlink.net...
>> >>
>> >> Well. I think I actually followed most of that.
>> >>
>> >> Just thought it would be cool if all the software on my computer was
>> >> in only two languages.
>> >
>> > All of it is in *one* language.  The instruction set of the
>> > processor (unless you have some weird multiprocessor machine
>> > and one or more of the processors use(s) a different instruction
>> > set from the other(s) )
>> >
>> > Take away the source code for all the programs, and the software
>> > is still there.
>> >
>> > -Mike
>> >
>> >
>> >
>> >
>>
>> I was speaking in practical terms. No one is going to be entering machine
>> language at the prompt to copy a file.
> 
> First, a 'prompt' will not typically accept machine language,
> but interpret mnemonic 'commands' which are submitted to and
> acted upon by the provider of such a prompt (typically
> an operating system).
> 
> 
> Dan has already pointed out my oversight regarding interpreted
> languages.  But aside from that, I still stand by what I said.
> 
> I don't need to type in, e.g. printf("Hello") etc. to run a
> compiled C program.
> 
> -Mike
> 
> 
> 

You lost me, Mike, and a ways back, I think.

-- 
Later, Alan C
You can find my email address at the website: contact.html
take control of your mailbox ----- elrav1 ----- http://tinyurl.com/l55a
0
zzzzzz (1966)
10/7/2003 7:39:16 PM
On 7 Oct 2003 11:12:39 -0700, John Bode <john_bode@my-deja.com> wrote:
> 
> 
> Alan Connor <zzzzzz@xxx.yyy> wrote in message news:<Olngb.438$av5.302@newsread3.news.pas.earthlink.net>...
>> Greetings to the group. I'm reading the FAQ and K&R and monitoring here, 
>> trying to get a handle on the transition from shell programming to C.
>> 
>> From what I've read, I honestly don't see the need for anything BUT C
>> and the simple functionality of the high-level programming provided by
>> any decent shell. (Okay, a teeny weenie bit of assembly language too :-)
>> 
> 
> No one language is universally best at everything.  There are tasks
> for which C is not the best choice.  It would not be my first choice
> for a graphical client, for example.

Well this will work out well then, because I am not into the GUI at all.

-- 
Later, Alan C
You can find my email address at the website: contact.html
take control of your mailbox ----- elrav1 ----- http://tinyurl.com/l55a
0
zzzzzz (1966)
10/7/2003 7:39:16 PM
"Alan Connor" <zzzzzz@xxx.yyy> wrote in message
news:EDEgb.1499$av5.427@newsread3.news.pas.earthlink.net...
> On Tue, 07 Oct 2003 17:58:21 GMT, Mike Wahler <mkwahler@mkwahler.net>
wrote:
> >
> >
> >
> > "Alan Connor" <zzzzzz@xxx.yyy> wrote in message
> > news:npBgb.1227$av5.353@newsread3.news.pas.earthlink.net...
> >> On Tue, 07 Oct 2003 10:08:41 GMT, Mike Wahler <mkwahler@mkwahler.net>
> > wrote:
> >> >
> >> >
> >> > "Alan Connor" <zzzzzz@xxx.yyy> wrote in message
> >> > news:Ffvgb.1050$av5.304@newsread3.news.pas.earthlink.net...
> >> >>
> >> >> Well. I think I actually followed most of that.
> >> >>
> >> >> Just thought it would be cool if all the software on my computer was
> >> >> in only two languages.
> >> >
> >> > All of it is in *one* language.  The instruction set of the
> >> > processor (unless you have some weird multiprocessor machine
> >> > and one or more of the processors use(s) a different instruction
> >> > set from the other(s) )
> >> >
> >> > Take away the source code for all the programs, and the software
> >> > is still there.
> >> >
> >> > -Mike
> >> >
> >> >
> >> >
> >> >
> >>
> >> I was speaking in practical terms. No one is going to be entering
machine
> >> language at the prompt to copy a file.
> >
> > First, a 'prompt' will not typically accept machine language,
> > but interpret mnemonic 'commands' which are submitted to and
> > acted upon by the provider of such a prompt (typically
> > an operating system).
> >
> >
> > Dan has already pointed out my oversight regarding interpreted
> > languages.  But aside from that, I still stand by what I said.
> >
> > I don't need to type in, e.g. printf("Hello") etc. to run a
> > compiled C program.
> >
> > -Mike
> >
> >
> >
>
> You lost me, Mike, and a ways back, I think.

Doesn't really matter, since we're not talking about C anymore
anyway. :-)  I'll try again: I'm saying that with a compiled language
such as C, once the program has been translated into executable
form, the source text is unnecessary for it to be executed.
Contrast an "interpreted" language, where the source is parsed
every time it's run.  I suspect the "runtime" of the interpreter
is what you're referring to with "prompt", where I jumped to
the conclusion that you meant "operating system's command prompt".
Sorry for any confusion.

-Mike

>
> --
> Later, Alan C
> You can find my email address at the website: contact.html
> take control of your mailbox ----- elrav1 ----- http://tinyurl.com/l55a


0
mkwahler (3821)
10/7/2003 8:37:05 PM
"Alan Connor" <zzzzzz@xxx.yyy> wrote in message
news:EDEgb.1500$av5.426@newsread3.news.pas.earthlink.net...
> On 7 Oct 2003 11:12:39 -0700, John Bode <john_bode@my-deja.com> wrote:
> >
> >
> > Alan Connor <zzzzzz@xxx.yyy> wrote in message
news:<Olngb.438$av5.302@newsread3.news.pas.earthlink.net>...
> >> Greetings to the group. I'm reading the FAQ and K&R and monitoring
here,
> >> trying to get a handle on the transition from shell programming to C.
> >>
> >> From what I've read, I honestly don't see the need for anything BUT C
> >> and the simple functionality of the high-level programming provided by
> >> any decent shell. (Okay, a teeny weenie bit of assembly language too
:-)
> >>
> >
> > No one language is universally best at everything.  There are tasks
> > for which C is not the best choice.  It would not be my first choice
> > for a graphical client, for example.
>
> Well this will work out well then, because I am not into the GUI at all.

"GUI" is not the only thing that C is not best suited for, it's
only of of them.  E.g. text parsing *can* be done with C, but
many feel that something like Perl is more suited to it.  Darn
near "anything" can be done with C (which imo is a big reason
for its popularity), but many tasks are more quickly and "easily"
done with some other language(s). YMMV.

We're just advising you to not limit yourself to one or two
tools.  Get out to the hardware store and fill up that toolbox. :-)

-Mike


0
mkwahler (3821)
10/7/2003 8:44:24 PM
On Tue, 07 Oct 2003 20:37:05 GMT, Mike Wahler <mkwahler@mkwahler.net> wrote:
> 
>>
>> You lost me, Mike, and a ways back, I think.
> 
> Doesn't really matter, since we're not talking about C anymore
> anyway. :-)  I'll try again: I'm saying that with a compiled language
> such as C, once the program has been translated into executable
> form, the source text is unnecessary for it to be executed.
> Contrast an "interpreted" language, where the source is parsed
> every time it's run.  I suspect the "runtime" of the interpreter
> is what you're referring to with "prompt", where I jumped to
> the conclusion that you meant "operating system's command prompt".
> Sorry for any confusion.
> 
> -Mike
> 
> 


Okay, let me ask you this:

Would it be practical to run an entire OS (or the vast bulk of it) with
an interpreted language?


-------------------------------------------------------------------------
"Alan Connor" <zzzzzz@xxx.yyy> wrote in message
news:EDEgb.1500$av5.426@newsread3.news.pas.earthlink.net...
> On 7 Oct 2003 11:12:39 -0700, John Bode <john_bode@my-deja.com> wrote:
>
> Well this will work out well then, because I am not into the GUI at all.

"GUI" is not the only thing that C is not best suited for, it's
only of of them.  E.g. text parsing *can* be done with C, but
many feel that something like Perl is more suited to it.  Darn
near "anything" can be done with C (which imo is a big reason
for its popularity), but many tasks are more quickly and "easily"
done with some other language(s). YMMV.

(I prefer sed and other utilities and the shell for text editing,
 and would learn AWK before Perl, any day.)


We're just advising you to not limit yourself to one or two
tools.  Get out to the hardware store and fill up that toolbox. :-)

-Mike

One step at a time, Mike, although there is no disputing the wholesomeness
of that advice.

But I may decide to use only C and Sh.  :-)



-- 
Later, Alan C
You can find my email address at the website: contact.html
take control of your mailbox ----- elrav1 ----- http://tinyurl.com/l55a
0
zzzzzz (1966)
10/7/2003 9:20:13 PM
gswork wrote in article <81f33a98.0310070013.518295ec@posting.google.com>:

> Sometimes i wonder if *nix programmers will ever use anything but c
> and shell... (ah, of course they use other languages - but sometimes
> it doesn't seemt that way).

Shell?  Blech.  I see most *nix programming moving towards Perl and Python,
with Python being my favorite of the two.  Heavy text parsing is better
under Perl, but Python to me is far more versatile.  Perl is just like
shell on steroids anyway.


-- 
Todd Stephens
ICQ# 3150790
"A witty saying proves nothing." -Voltaire
0
Todd
10/7/2003 9:35:00 PM
On Tue, 07 Oct 2003 21:35:00 +0000, Todd Stephens wrote:

>  Perl is just like shell on steroids anyway.

	And a cryptic one, at that. I can't wait for it to fade a way, replaced
by more sensible tools.


0
skh (20)
10/7/2003 10:37:28 PM
"Alan Connor" <zzzzzz@xxx.yyy> wrote in message
news:h6Ggb.1786$dn6.43@newsread4.news.pas.earthlink.net...
> > Sorry for any confusion.
> >
> > -Mike
>
> Okay, let me ask you this:
>
> Would it be practical to run an entire OS (or the vast bulk of it) with
> an interpreted language?

We're really way off topic now.  I've sent you an email.

-Mike


0
mkwahler (3821)
10/7/2003 11:41:03 PM
On Tue, 07 Oct 2003 22:37:28 GMT, SKH <skh@yoyodyne.net> wrote:
> 
> 
> On Tue, 07 Oct 2003 21:35:00 +0000, Todd Stephens wrote:
> 
>>  Perl is just like shell on steroids anyway.
> 
> 	And a cryptic one, at that. I can't wait for it to fade a way, replaced
> by more sensible tools.
> 
> 

Or at least offer itself as a complete *substitute* for the shell.

-- 
Later, Alan C
You can find my email address at the website: contact.html
take control of your mailbox ----- elrav1 ----- http://tinyurl.com/l55a
0
zzzzzz (1966)
10/8/2003 12:39:19 AM
On Tue, 07 Oct 2003 23:41:03 GMT, Mike Wahler <mkwahler@mkwahler.net> wrote:
> We're really way off topic now.  I've sent you an email.
> 
> -Mike
> 
> 

You are passlisted....NOW :-)

-- 
Later, Alan C
You can find my email address at the website: contact.html
take control of your mailbox ----- elrav1 ----- http://tinyurl.com/l55a
0
zzzzzz (1966)
10/8/2003 12:39:22 AM
Alan Connor wrote in article
<X0Jgb.1772$av5.1148@newsread3.news.pas.earthlink.net>:

> Or at least offer itself as a complete substitute for the shell.

Now there's a thought.  I wonder how far off a Perl shell is.  With syntax
that makes tcsh look like QBasic.

-- 
Todd Stephens
ICQ# 3150790
"A witty saying proves nothing." -Voltaire
0
Todd
10/8/2003 2:24:33 AM
Alan Connor <zzzzzz@xxx.yyy> wrote in message news:<h6Ggb.1786$dn6.43@newsread4.news.pas.earthlink.net>...
> 
> Would it be practical to run an entire OS (or the vast bulk of it) with
> an interpreted language?

Although Java is not an operating system per se, it could possibly
come close.

Also, languages like Forth (which is an operating system in its own
right) sit somewhere between 'compiled' and 'interpreted'.

-- 
Peter
0
airia (1802)
10/8/2003 3:50:36 AM
"Alan Connor" <zzzzzz@xxx.yyy> wrote in message
news:_0Jgb.1773$av5.812@newsread3.news.pas.earthlink.net...
> On Tue, 07 Oct 2003 23:41:03 GMT, Mike Wahler <mkwahler@mkwahler.net>
wrote:
> > We're really way off topic now.  I've sent you an email.
> >
> > -Mike
> >
> >
>
> You are passlisted....NOW :-)

"passlisted?"  I'm not familiar with that term.

-Mike


0
mkwahler (3821)
10/8/2003 4:30:43 AM
> > i heard people say C++ is slower than C but i can't believe that. in
pieces
>
> What people?  What are their qualifications to make such a statement?
> What evidence have they provided to prove the statement?
>
> And what are your qualifications to refute such a statement?  What
> evidence do you have to disprove it?

i see you have very much problems with people who are criticize your
favourite programming language.
when you have a problem with that nobody forces you to discuss here with us.

> Obviously your knowledge of C is minimal.

what makes you believe that?

> Do you think ignorance of a
> subject qualifies you to expound on it?  Or is your wisdom to be
> inferred by your lack of proper capitalization, punctuation, and
> grammar?

dont be childish. i didn't troll so you shouldn't do this either.
when you feel my grammar or punktuation are wrong please point out the
passage and tell my what was wrong.
i'm german and my english is still not perfect.

> Why should we care about your obviously illogical feelings?

prove that my thaughts are illogical.

> C existed
> long before C++ did, and is and was extremely successful.

the same is true for forth,fortran,cobol,pl/1 but does that mean it is
reasonable
to use these languages today?

> It is the
> most portable programming language in the world.

that is a fact i already learned in this discussion. and your first
argument.

> It does not need to
> justify its existence to you or to anyone else, nor does it have to
> compare itself to any other language.

what is wrong with comparing languages?

>
> Discussions of the relative merits of various programming languages
> belong in news:comp.programming if they are cogent.  They belong in
> advocacy groups if not.  No one is asking you to use C is you don't
> think it is useful to you.
>
> But comparisons between C and any other language, C++ included, are
> not C language issues and do not belong in any of groups you posted
> to.



--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
10/8/2003 5:35:13 AM
> > pieces of the application where speed really matters you can still use
> > "normal" functions or even static methods which is basically the same.
>
> Suck it and see.

?

> int main(void)
> {
>   const int new = 6; /* I rest my case */
>   return 0;
> }

i though in standard C, there isn't such a thing like "const" you can only
use macros to fake them.

>
> > each struct
> > and enum have to be prefixed with "struct" and "enum".
>
> Poor baby.

void foo(struct MyStruct struct){}

in C you cannot omit the keyword "struct". when it compiles without "struct"
you probably using a C++ compiler.


> Yes, there is. C is simple,

agreed.

> portable,

agreed.

> and very very fast. Those are  important qualities.

not faster than C++. why should it?

> but note that C++ is /not/ available on anything like as many
> target platforms as C is.

that is true.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
10/8/2003 5:35:19 AM
In article <clcm-20031005-0008@plethora.net>, cody
<NO.SPAM.deutronium@gmx.net> writes
>no this is no trollposting and please don't get it wrong but iam very
>curious why people still use C instead of other languages especially C++.

C++ doesn't fit on to many  targets. 

>i don't get it why people program in C and faking OOP features(function
>pointers in structs..) instead of using C++.

I don't understand either... 

> are they simply masochists 

probably. 


C is good for Modular programming. In many ways there is little to
choose between modular and OO programming. 



/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
chris32 (3361)
10/8/2003 5:35:22 AM
> There is both a speed and size penalty for using C++ where
> pain C would do.  The penalty isn't as bad as it used to be.

there should be no difference between the calls of

class A{ public: static void a(){ } }

and

void a(){}

> C has constants.  We usually use typedefs rather than struct
> and enum tags.

is "const float PI=3.14" possible in plain C?

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
10/8/2003 5:35:25 AM
> C is available on nearly every machine. C++ is not. OOP is a nice thing
> but not for everything.
>
> "With OOP we can solve problems very elegant, we wouldn't have without
> it."
>
> While the above statement is not entirely true, there is some truth in it.
> ;)


agreed :)

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
10/8/2003 5:35:27 AM
> > i don't get it why people program in C and faking OOP features(function
> > pointers in structs..) instead of using C++.
>
> This is laughable.  It is C++ that is best known for faking OO features!
> If you're looking for an OO extension to C that is actually well done,
> one that is additionally a proper superset of C, you should be looking
> at Objective-C.  But that's still in the C family.  If you don't want C,
> don't use C; don't use C++ and pretend you're not using C, though.


so why is objective C used my nobody? except you maybe :)

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
10/8/2003 5:35:32 AM
> C supports the const keyword now.

since when? C99?

> > each struct and enum must be prefixed with "struct" and "enum".
>
> typedef struct X {
>   // public data members
>   } X;
>
> in C is the same as
>
> struct X {
>   // public data members
>   };
>
> in C++.

and in function declarations? is void foo(X x){} allowed?

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
10/8/2003 5:35:33 AM
In article <clcm-20031005-0008@plethora.net>,
 "cody" <NO.SPAM.deutronium@gmx.net> wrote:

> no this is no trollposting and please don't get it wrong but iam very
> curious why people still use C instead of other languages especially C++.

Because there is an ANSI/ISO C compiler for my Apple IIgs and there 
isn't a compiler for C++. Not all of us program for the x86 platform. I 
prefer the WDC65C816.
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
jalapeno1 (69)
10/8/2003 5:36:16 AM
On 05 Oct 2003 21:37:06 GMT
"cody" <NO.SPAM.deutronium@gmx.net> wrote:

> no this is no trollposting and please don't get it wrong but iam very
> curious why people still use C instead of other languages especially
> C++.
I'd just like to add my 2 $.025.
C++ is a very tool rich language and is wonderful for application level
and some systems level jobs. C is excellent for many lower level
programming jobs. I would certainly use C++ for graphical programming
and any other type of programming where one should deal with objects. 

It all comes under the heading of "use the right tool for the job". When
comparing C to C+ I think of C as assembler language and C++ as the high
level language, and there are some tasks where assembler language is
appropriate. 

-- 
Jerry Feldman <gaf-nospam-at-blu.org>
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
gaf-noSPAM (33)
10/8/2003 5:36:20 AM
Speaking for myself and no one else...

"cody" <NO.SPAM.deutronium@gmx.net> wrote in message news:<clcm-20031005-0008@plethora.net>...
> no this is no trollposting and please don't get it wrong but iam very
> curious why people still use C instead of other languages especially C++.
> 

Main reasons:

1.  It's required.  I'm supporting code that, for one reason or
another, was originally written in C, and porting it to C++ or
anything else is far more effort than it's worth.

2.  C is a smaller language than C++, and learning to use it
effectively is a bit more straightforward than learning to use C++
effectively.  Once you actually understand OOP, C++ pretty much falls
into place, but IME there's a longer flailing period with C++ (YMMV).
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
john_bode (637)
10/8/2003 5:36:42 AM
"cody" <NO.SPAM.deutronium@gmx.net> wrote in message news:<clcm-20031005-0008@plethora.net>...
> no this is no trollposting and please don't get it wrong but iam very
> curious why people still use C instead of other languages especially C++.

For small portable utilities it really is rather good, for larger
projects it can get a little confusing if you don't set about things
well.  C++ can be nice there - but then you have to watch what you're
doing as it can be a minefield.

C Compilers are plentiful and often very good, ISO C is portable and
widely implemented, there's lots of third party libraries (though that
can be confusing!).

You can structure your C code so as to be efficient for the machine -
not what you're always 'supposed' to do, but it's an option.  Many C
compilers are capable of significant optimisation too.

C++ and it's STL are a nice way to accomplish many things too though,
nothing you couldn't do it C, but sometimes clearer and less
troublesome (for me as someone of relatively low skill in both!)
 
And then there's code size, embedded apps....

> i heard people say C++ is slower than C but i can't believe that. 

intuitively i'd imagine all the safety nets might slow some parts
down, other than that i suspect there's no meaningful difference.
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
gswork (648)
10/8/2003 5:36:50 AM
In comp.std.c cody <NO.SPAM.deutronium@gmx.net> wrote:
+ no this is no trollposting and please don't get it wrong but iam very
+ curious why people still use C instead of other languages especially C++.
+ 
+ i heard people say C++ is slower than C but i can't believe that. in pieces
+ of the application where speed really matters you can still use "normal"
+ functions or even static methods which is basically the same.
+ 
+ in C there arent the simplest things present like constants, each struct and
+ enum have to be prefixed with "struct" and "enum". iam sure there is much
+ more.
+ 
+ i don't get it why people program in C and faking OOP features(function
+ pointers in structs..) instead of using C++. are they simply masochists or
+ is there a logical reason?
+ 
+ i feel C has to benefit against C++.

C is pretty much, but not quite, a sublanguage of C++.  C programmers
who don't use the non-C++ features of C are programming in C++ whether
they claim to or not.  They are restricting themselves to an older,
more established, more easily learned, and more easily implemented
subset of C++.  But they are writing in C++ --- non-idiomatic C++, but
C++ nevertheless.  AFAIK, a C++ compile is free to generate the same
code for those programs as would a C compiler, so there is no
intrinsic difference in performance.  

Compiling C programs with a C++ compiler has the benefit that C++
compilers are required to perform intermodule type checking.  But I'm
told that this intermodule type checking is a curse when one tries to
use precompiled libraries that have been compiled on different C++
compilers, since that checking is usually based on name-mangling and
there is no name-mangling standard.  (Perhaps others have more
experience with that issue.)

Tom Payne
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
thp (42)
10/8/2003 5:36:56 AM
"Mike Wahler" <mkwahler@mkwahler.net> writes:

> "Alan Connor" <zzzzzz@xxx.yyy> wrote in message
> news:_0Jgb.1773$av5.812@newsread3.news.pas.earthlink.net...
> > On Tue, 07 Oct 2003 23:41:03 GMT, Mike Wahler <mkwahler@mkwahler.net>
> wrote:
> > > We're really way off topic now.  I've sent you an email.
> > >
> > > -Mike
> > >
> > >
> >
> > You are passlisted....NOW :-)
> 
> "passlisted?"  I'm not familiar with that term.

Possibly... added to the list of people allowed to pass through
his not-a-spammer?-then-confirm-yourself filter...?

-Micah
0
micah2 (555)
10/8/2003 8:42:43 AM
Todd Stephens <Huzzah!@Huzzah.com> writes:

> Alan Connor wrote in article
> <X0Jgb.1772$av5.1148@newsread3.news.pas.earthlink.net>:
> 
> > Or at least offer itself as a complete substitute for the shell.
> 
> Now there's a thought.  I wonder how far off a Perl shell is.

A Perl shell has been in existence for some time now.

  http://www.gregorpurdy.com/gregor/psh/

-Micah
0
micah2 (555)
10/8/2003 8:47:20 AM
In <clcm-20031008-0005@plethora.net> "cody" <dont.spam.me.deutronium@gmx.de> writes:

>is "const float PI=3.14" possible in plain C?

If you're not aware of the basic standard C features, what makes you
think that you're qualified to participate to this discusion?

Dan
-- 
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de
0
Dan.Pop (3615)
10/8/2003 11:35:34 AM
In <clcm-20031008-0008@plethora.net> "cody" <dont.spam.me.deutronium@gmx.de> writes:

>> C supports the const keyword now.
>
>since when? C99?

Since C89.

Dan
-- 
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de
0
Dan.Pop (3615)
10/8/2003 11:37:50 AM
"cody" <dont.spam.me.deutronium@gmx.de> wrote in message
news:clcm-20031008-0001@plethora.net...

Attribution restored:

"Jack Klein" <jackklein@spamcop.net> wrote in message
news:clcm-20031006-0002@plethora.net...
Cody:

First, I will initially take at face value your statement
that you are not trolling.  Let's see what happens after
you read the following:

I'm writing this because you probably do not realize
that Mr. Klein is one of the select few people here
who are the most highly qualified to help people to
learn and work with with the C language, as well as
to explain its various strengths and weaknesses, and
to help you decide if C is the most appropriate tool
for a particular task.

Strictly speaking, only discussion of the language itself
is topical here, but if treated with respect, I suspect
Jack would probably extend his aid regarding those last
two issues as well.

Of the people who have replied to you, I consider Jack
and Richard Heathfield to be very far "above the crowd"
with regard to knowledge and skill with the C language.
I suspect most others here will agree.

If you want quality help and information about C, you
can hardly do better than to listen to these two gentlemen.

Let's review. See below.

> On 05 Oct 2003 21:37:06 GMT, "cody" <NO.SPAM.deutronium@gmx.net> wrote
> in comp.std.c:

> > > i heard people say C++ is slower than C but i can't believe that. in
> pieces
> >
> > What people?  What are their qualifications to make such a statement?
> > What evidence have they provided to prove the statement?
> >
> > And what are your qualifications to refute such a statement?  What
> > evidence do you have to disprove it?
>
> i see you have very much problems

I fail to see Jack expressing any "problems" in what he wrote
above. He asked legitimate questions about the statements
you made.  He did not attack you, insult you, or call you
bad names.  Nor did he shower you with love and praise.

His questions were neutral, and in my opinion designed
to cause you to stop and think.  He can only answer to
what you wrote, because as far as I know, he cannot read
minds, and I know from experience here that he will not
simply assume meanings or motives you did not express.

So when you say:

> i see you have very much problems

I can only answer: How do you know he has problems?

and:

>with people who are criticize

I answer: Assuming for the moment that he does "have
a problem with your criticism," how can you know whether
or not he "has problems with people who criticize?"
Do you claim knowledge of his interactions with everyone?

and:

> your favourite programming language.

I answer: How can you know if C is or is not his
favorite language?

> when you have a problem with that nobody forces you to discuss here with
us.

> > Obviously your knowledge of C is minimal.
>
> what makes you believe that?

Probably the part of your post to which it responded,
which you did quote, but I reproduce here:

> in pieces of the application where speed really matters
> you can still use "normal" functions or even static methods
> which is basically the same.
>
> in C there arent the simplest things present like constants,
> each struct and enum have to be prefixed with "struct" and
> "enum". iam sure there is much
> more.

Jack replied as he did because he *knows* that:

1. C does not assign an attribute of "normal" or "abnormal"
   to functions.

2. C does not define anything called a "static method" or a
   "method".

3. A function can indeed be declared as "static", but this
   attribute is not defined to have any effect at all upon
   performance.

4. The qualities of a nonstatic function are *not* the same
   as those of a static function.  Where applied to a function,
   the "static" keyword causes its scope and linkage to differ
   from one where it is not.

5. Nothing at all about speed of performance is specified
   by the C language.

6. C does indeed specify a keyword 'const' and its effect
   when applied.  A constant can also be expressed with a
   macro.

7. structure object types are defined using the 'struct' keyword
   and enumeration types are defined using the 'enum' keyword.
   Your sole implied reason for expressing dissatisfaction with
   these syntactical rules is that they differ from that of
   another language.  C is not C++, nor does it make any attempt
   to be.

You make six erroneous assertions or implications about C,
and also complain that C is not C++.  Then you say "I'm sure
there is much more."

It is not clear to me whether you mean "much more" about
C which you do not know, or "much more" about C you do
not like.  More which you do not know, I would hesitate
to deny, given the several false statements you made.
More which you do not like, I do not doubt at all.  That
last is your opinion, not a fact which can be refuted or
denied, so it doesn't matter what anyone thinks about that.


You repeated statements said by others and gave your
judgement about them. You gave no bases for such a
judgment.  So Jack asked for your premises.  You responded
by attacking him.  Then you make or imply assertions
of your own, again providing no premises for them.


>
> > Do you think ignorance of a
> > subject qualifies you to expound on it?

Another logical question, again probably designed to
cause to to stop and think about what you wrote.
No personal attacks.  (Despite the belief to the
contrary by many, ignorance is not a character flaw,
it's simply a lack of education about one or more
subjects, easily rectified, and without any reason
for shame or embarrassment.)

Jack is extremely qualified to assess one's knowledge
or ignorance about the C language.  He has accurately
assessed yours, and validly challenges your criticism
of it. (Actually he didn't need that reason anyway,
since this group is *specifically designated* for
*discussion* of C, not for advocacy or criticism of it.)

I believe I have reasonable knowledge of C, but not
perfect, and sometimes I write something here about C
which is wrong.  When Jack sees this he corrects me.
I respond with *thanks*, not by attacking him for
pointing out my errors.

>Or is your wisdom to be
> > inferred by your lack of proper capitalization, punctuation, and
> > grammar?

Perhaps this remark is justified, perhaps not.  It seems
that your irrefutable ignorance about C, combined with
your expression of conclusions without premises might
have caused him to associate your nonfluency with English
with your level of wisdom.

I can understand this reaction, since when you wrote your
first post, (in this English-speaking newsgroup), you did not
indicate that English is not your native language, and
unfortunately, a significant number of people whose native
language *is* English post here with spelling, grammar,
etc. far worse than yours.

The content of your post combined with the poor English
probably caused him to believe you were an American
or British troll.

> dont be childish.

Jack is certainly not childish.  My many years of interaction
with him here tell me this.  How long have *you* been here?

>i didn't troll so you shouldn't do this either.

Despite your disclaimer, your message gives every evidence
of being a troll.  For now, I give you the benefit of the
doubt.  Jack is certainly no troll, but once of the more
highly regarded and valued regular contributors here.

I suppose time will tell what your true character is.

> when you feel my grammar or punktuation are wrong please point out the
> passage and tell my what was wrong.

If you ask nicely, perhaps I'll do that for you.
Perhaps you might help me learn German.  But not
here.  Maybe in newsgroups about English and German.

Here, only C.

> i'm german and my english is still not perfect.

I understand very little German, but my few halfhearted
attempts to learn it quickly informed me that many more
words are capitalized in German than in English; it seems
that every noun is capitalized (only my impression, I'm
not certain.)  If your defense of your English is that
you're German, I would have expected too many capital
letters, not none at all. :-)

My brief 'learning' experiences with German also indicates
that it uses punctuation as well.  Is it true that the
only punctuation characters used consistently are periods
and apostrophes, and that commas are optional, as your
messages seem to show? Is it true that sentences are begun
in lower case?

I do see two indicators of a German learning English:
the British English spelling which uses 'ou' where the
American English uses only 'o' (meaning you probably
have more contact with British than Americans), and the
use of 'k' where all forms of English use 'c', 'k', or
'ck'.

[Restoring context for below]:

> > > i don't get it why people program in C

There is no single reason or set of reasons. The reasons
of some can and do differ from those of others.  The
only way to know is to ask each person using C.

Why do you seem to believe that if a person uses C, that
that is the only language he uses? The average programmer
I come into contact with uses between three and six programming
languages on a regular basis.  I'm acquainted with a few who
use only one, and others who use a dozen or more, but these
are the exceptions in my experience.

> > > and faking OOP
> > > features (function pointers in structs..)

1.  Why do you seem to feel that OOP is the solution to
    all programming issues?  Have you blindly believed
    the 'mass media'?

2.  OOP can be done in virtually any language.  Why do
    you feel that using a given language's available features
    to implement OOP is somehow 'fake'?

3.  Why do you believe that the insertion of a pointer to
    a function into a structure causes the use of that
    structure and its function pointer member(s) to become
    a component of OOP or OOP itself?

4.  Are you unaware of the several other concepts and
    techniques which comprise OOP?

> > > instead of
> > > using C++.

Why do you believe that C++ is the only language which
has features and constructs which directly support OOP?

> are they simply masochists

I doubt it.  More likely they're rational, logical people
applying appropriate tool(s) to particular task(s)  And
personally, I find C a joy to use.  I feel the same way
about C++.

I embrace *both* languages, I don't pit them against
one another.  Sometimes I combine the two, drawing upon
the strengths of each and/or overcoming limitations of
each, to create useful applications.

You probably have a tool box in your garage.  What's
inside?  Just a hammer?  Just a screwdriver?  I suspect
it contains a variety of useful tools. This concept
does not disappear in the programming world.

> > > or is there a
> > > logical reason?

I suspect there are many.  But I won't presume to present the
reasons of others. I've told you mine.

> > > i feel C has to benefit against C++.

I'll guess you've made a typing error here and really
meant:

  "i feel C has no benefit against C++."

You're certainly entitled to that opinion.  Nobody
has tried to force you to use C and/or to refrain
from using C++, have they?  So your expression of
this "feeling" here will garner no sympathy or support.
All we can tell you is to use any language you like.

>
> > Why should we care about your obviously illogical feelings?
>
> prove that my thaughts are illogical.

I believe I've done that above.  I've done this with the
intention of helping you.  I'm curious as to how you will
react.

>
> > C existed
> > long before C++ did, and is and was extremely successful.
>
> the same is true for forth,fortran,cobol,pl/1 but does that mean it is
> reasonable
> to use these languages today?

That question implies that you've decided it means it is not.
But you've just agreed that the same (age, past and current
success) is true for those languages.  It seems you've
just contradicted yourself, as well as made another conclusion
without premises.  Does age somehow override success?

Are you saying that when a programming language reaches a
certain age it becomes obsolete or 'unreasonable to use'?
Why?  Have you never considered the *domain* of a particular
language?  Are you unaware of the concept of "existing code
base?"  Simple economics?

I've used all of the languages you cite during my career
except Forth, and many more. I use and like C++ very
much.  But I don't use it as a basis to criticize C or
any other language. I'm uncertain about PL/1, but I *know*
that FORTRAN and COBOL are still widely used today. I don't
know if it's still true today, but not very long ago, COBOL
represented the vast majority of existing code.  Much, perhaps
most of it is still  being used without complaint or problem.

Would you have people throw away perfectly good code
which *already performs its task satisfactorily*
and write it all over again from scratch?  Expend the
resources for design alterations often necessary when
moving to a new language?  For testing and debugging?
For the extra hardware probably required for the necessary
"run in parallel" period? In a pointless, misguided quest
to be "modern?"

What about systems for which a C++ implementation is
not available?  For which only an implementation of
a single language (C for example) is available?
What about the fact that among these single-language-
available systems, the language with the highest
probability of being that single one is C?

Also, why would people expend the effort to continue to
update COBOL and FORTRAN standards if nobody found them
'reasonable' to use?  Or did you assume that these languages,
which you label by implication "ancient, obsolete, useless",
were abandoned  by everyone in favor of languages like C++,
simply because they're more recently invented?

Are you suffering from the misconception that any given
single language is or can be the solution to all programming
issues?

Jack's remark about the age of C was meant to show that
it has withstood the "test of time", and is still a very
useful and powerful tool.  In my opinion, the same is
true of FORTRAN and COBOL, and I suspect will also be
of C++ (which imo has alredy proven its power, we'll
still be in the "time test" period for a while yet).

> > It is the
> > most portable programming language in the world.
>
> that is a fact i already learned in this discussion. and your first
> argument.

Jack has successfully refuted much of what you've stated.
It would be in your best interest to listen to him if
you care to learn what C really is.  Even if you find
his mode of communication not to your absolute satisfaction,
you could learn much from him.  I certainly have.

If you want to discuss or learn about C, this is the place.
If you want to criticize it or compare it with other languages,
this is not the place.

>
> > It does not need to
> > justify its existence to you or to anyone else,

This is a key point.

>nor does it have to
> > compare itself to any other language.
>
> what is wrong with comparing languages?

Doing it here is wrong because it's not topical here.

Doing it in proper context could indeed be a fruitful
exercise.  But before you do, I strongly suggest you
base your side of a debate upon accurate knowledge,
and to the extent possible, experience, not hearsay
and speculation.


There.  I feel better now. :-)

-Mike



0
mkwahler (3821)
10/8/2003 11:44:47 AM
"Micah Cowan" <micah@cowan.name> wrote in message
news:m3smm4unlo.fsf@localhost.localdomain...
> "Mike Wahler" <mkwahler@mkwahler.net> writes:
> > > You are passlisted....NOW :-)
> >
> > "passlisted?"  I'm not familiar with that term.
>
> Possibly... added to the list of people allowed to pass through
> his not-a-spammer?-then-confirm-yourself filter...?

Ah, could be.  In which case I'll take that as a compliment. :-)

-Mike


0
mkwahler (3821)
10/8/2003 11:47:40 AM
"Mike Wahler" <mkwahler@mkwahler.net> wrote:

> "cody" <dont.spam.me.deutronium@gmx.de> wrote in message
> news:clcm-20031008-0001@plethora.net...
> 
> First, I will initially take at face value your statement
> that you are not trolling.

I've just seen some of "cody"'s posts in another programming newsgroup,
and have come to the conclusion that it _is_ a troll.

Richard
0
rlb (4118)
10/8/2003 1:55:09 PM
> > First, I will initially take at face value your statement
> > that you are not trolling.
>
> I've just seen some of "cody"'s posts in another programming newsgroup,
> and have come to the conclusion that it _is_ a troll.


what??? what makes you think that?

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk


0
10/8/2003 4:02:09 PM
that's what i call an answer :)

> First, I will initially take at face value your statement
> that you are not trolling.  Let's see what happens after
> you read the following:
>
> I'm writing this because you probably do not realize
> that Mr. Klein is one of the select few people here
> who are the most highly qualified to help people to
> learn and work with with the C language, as well as
> to explain its various strengths and weaknesses, and
> to help you decide if C is the most appropriate tool
> for a particular task.

i didn't know who he was i only knew  how he reacted to my
question and his answer seemed to me a bit aggressive.

> > in pieces of the application where speed really matters
> > you can still use "normal" functions or even static methods
> > which is basically the same.
> >
> > in C there arent the simplest things present like constants,
> > each struct and enum have to be prefixed with "struct" and
> > "enum". iam sure there is much
> > more.
>
> Jack replied as he did because he *knows* that:
>
> 1. C does not assign an attribute of "normal" or "abnormal"
>    to functions.
>
> 2. C does not define anything called a "static method" or a
>    "method".

i mean't "why C instead of C++". i assumed all C programmers would use C++
and so i said that this is no problem since in C++ they cann still use
c-functions
or static functions as they are the same as c-functions, basically.

iam sorry if i didn't made that clearer.

> 6. C does indeed specify a keyword 'const' and its effect
>    when applied.  A constant can also be expressed with a
>    macro.

i didn't knew that.

> Another logical question, again probably designed to
> cause to to stop and think about what you wrote.
> No personal attacks.  (Despite the belief to the
> contrary by many, ignorance is not a character flaw,
> it's simply a lack of education about one or more
> subjects, easily rectified, and without any reason
> for shame or embarrassment.)

iam not an ignorant. why do you think i asked this question?
i only wanted reasons why people still use C. ok now i have got enough
reasons.

- C is simpler than C++
- some people don't like OOP
- some people don't want to learn OOP
- some projects don't need OOP
- some platforms dosn't provide a proper C++ compiler.

i didn' know that i would create such a large discussion.

> >Or is your wisdom to be
> > > inferred by your lack of proper capitalization, punctuation, and
> > > grammar?
>
> Perhaps this remark is justified, perhaps not.  It seems
> that your irrefutable ignorance about C, combined with
> your expression of conclusions without premises might
> have caused him to associate your nonfluency with English
> with your level of wisdom.
>
> I can understand this reaction, since when you wrote your
> first post, (in this English-speaking newsgroup), you did not
> indicate that English is not your native language, and
> unfortunately, a significant number of people whose native
> language *is* English post here with spelling, grammar,
> etc. far worse than yours.

so what do you advise? should i write in the subject of my next posting:

"warning! german poster with probably wrong capitalization, punctuation and
grammar"

> The content of your post combined with the poor English
> probably caused him to believe you were an American
> or British troll.

i didn't know that my english is so bad. i would be very grateful if
somebody give me a hint what is wrong with my grammar.

> I understand very little German, but my few halfhearted
> attempts to learn it quickly informed me that many more
> words are capitalized in German than in English; it seems
> that every noun is capitalized (only my impression, I'm
> not certain.)

that is correct all nouns, proper names and beginnings of a sentence are
capitalised.

> If your defense of your English is that
> you're German, I would have expected too many capital
> letters, not none at all. :-)

you underestimated my lazyness :-[=]

>
> My brief 'learning' experiences with German also indicates
> that it uses punctuation as well.  Is it true that the
> only punctuation characters used consistently are periods
> and apostrophes, and that commas are optional, as your
> messages seem to show?

some commas in german are optional.

 Is it true that sentences are begun in lower case?

neither in english nor in german but my shiftkey is broken.
i brough is to the workshop last week but it is still not ready :)

> 1.  Why do you seem to feel that OOP is the solution to
>     all programming issues?  Have you blindly believed
>     the 'mass media'?

no, but you can use C++ without programming OOP sinc C++ is a hybrid
language
which supports various programming paradigms, including structured,oop,
functional and more.

> 2.  OOP can be done in virtually any language.  Why do
>     you feel that using a given language's available features
>     to implement OOP is somehow 'fake'?

oop need language support at least to a certain level. when people programm
oop in C then it is certainly faked.

> 3.  Why do you believe that the insertion of a pointer to
>     a function into a structure causes the use of that
>     structure and its function pointer member(s) to become
>     a component of OOP or OOP itself?

it was just an example how some people fake oop in c.

> 4.  Are you unaware of the several other concepts and
>     techniques which comprise OOP?

yes. i have good knowlegde about c++,c# and java. a OO-language needs
classes,ctors,dtors,virtual,abstract,static methods and access modifiers.
i consider operator overloading as optional.

does C++ have a concept of sealed classes? that are classes which cannot be
subclassed.

> Why do you believe that C++ is the only language which
> has features and constructs which directly support OOP?

surely not. it was just an example cos c++ is the successor of c.

> You probably have a tool box in your garage.  What's
> inside?  Just a hammer?  Just a screwdriver?  I suspect
> it contains a variety of useful tools. This concept
> does not disappear in the programming world.

thats what i meant. why use a tool or another when you have a tool which
combines both?
why use C when you can use C++ which contains C? thats what i meant. you can
use c++,
nobody will force you to use its additinal features.

> > prove that my thaughts are illogical.
>
> I believe I've done that above.  I've done this with the
> intention of helping you.  I'm curious as to how you will react.

iam indeed grateful as you pointed out that my question was misunderstood
here.
i was wondering why some people didn't understand it, now i know why.

> Are you saying that when a programming language reaches a
> certain age it becomes obsolete or 'unreasonable to use'?
> Why?

no, i'm not saying that.

> Have you never considered the *domain* of a particular
> language?  Are you unaware of the concept of "existing code
> base?"  Simple economics?

nobody will throw away C. it still exists in C++ as C++ is fully backward
compatible(at least C94 if iam correctly informed)

> Would you have people throw away perfectly good code
> which *already performs its task satisfactorily*
> and write it all over again from scratch?  Expend the
> resources for design alterations often necessary when
> moving to a new language?  For testing and debugging?
> For the extra hardware probably required for the necessary
> "run in parallel" period? In a pointless, misguided quest
> to be "modern?"

surely not.

> Are you suffering from the misconception that any given
> single language is or can be the solution to all programming
> issues?

surely not.

> If you want to discuss or learn about C, this is the place.
> If you want to criticize it or compare it with other languages,
> this is not the place.

i wanted to learn about C why people still use it  and now i know why :)

> There.  I feel better now. :-)

me to..

now i know why iam always misunderstood here: it certainly is my bad grammar
:-)

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk


0
10/8/2003 4:50:59 PM
> >is "const float PI=3.14" possible in plain C?
>
> If you're not aware of the basic standard C features, what makes you
> think that you're qualified to participate to this discusion?


who are you to determine who can participate here and who not?
i just determined you are a very rude &$�"$"!/�$") and
do not deserve to discuss here.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk


0
10/8/2003 5:00:54 PM
cody wrote:
> 
<snip 1>
> - C is simpler than C++
> - some people don't like OOP
> - some people don't want to learn OOP
> - some projects don't need OOP
> - some platforms dosn't provide a proper C++ compiler.
> 
<snip 2>
> why use C when you can use C++ which contains C? thats what i meant. you can
> use c++,
> nobody will force you to use its additinal features.
> 
<snip 3>
> nobody will throw away C. it still exists in C++ as C++ is fully backward
> compatible(at least C94 if iam correctly informed)

ad 2)
just do it, if 1) or policy is no showstopper

ad 3)
not true (and easily found out by googling f.e. this ng
or  http://www.google.com/search?hl=de&ie=ISO-8859-1&client=googlet& \
q=c+%22c%2B%2B%22+++compatibility&btnG=Google+Suche&lr=).

There's a whole series of articles by B. Stroustrup about pros and cons of making
them more compatible:
http://www.cuj.com/documents/s=8011/cuj0207stroustr/ ff.

a "german poster with probably wrong capitalization, punctuation and grammar"
0
10/8/2003 5:33:47 PM
cody wrote:
> 
> > >is "const float PI=3.14" possible in plain C?
> >
> > If you're not aware of the basic standard C features, what makes you
> > think that you're qualified to participate to this discusion?
> 
> who are you to determine who can participate here and who not?
> i just determined you are a very rude &$�"$"!/�$") and
> do not deserve to discuss here.
> 
> --
> cody
> 
> [Freeware, Games and Humor]
> www.deutronium.de.vu || www.deutronium.tk

you might find out ...
after being plonked by everybody knowledgeable.

*plonk*
0
10/8/2003 5:39:51 PM
cody wrote:
> 
.... snip ...
> 
> neither in english nor in german but my shiftkey is broken.
> i brough is to the workshop last week but it is still not ready :)
> 
> > 1.  Why do you seem to feel that OOP is the solution to
> >     all programming issues?  Have you blindly believed
> >     the 'mass media'?
> 
> no, but you can use C++ without programming OOP sinc C++ is a
______________________^_______________________^^^______^

Nothing broken, but showing that you fail to capitalize I and the
beginning of sentences purely to annoy.  You are rapidly
approaching PLONK status, which will harm you if some time you
really want information.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!


0
cbfalconer (19194)
10/8/2003 6:30:43 PM
cody wrote:
> 
> > >is "const float PI=3.14" possible in plain C?
> >
> > If you're not aware of the basic standard C features, what makes
> > you think that you're qualified to participate to this discusion?
> 
> who are you to determine who can participate here and who not?
> i just determined you are a very rude &$�"$"!/�$") and
> do not deserve to discuss here.

That does it.  PLONK.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

0
cbfalconer (19194)
10/8/2003 6:30:45 PM
cody <dont.spam.me.deutronium@gmx.de> scribbled the following:
>> >is "const float PI=3.14" possible in plain C?
>>
>> If you're not aware of the basic standard C features, what makes you
>> think that you're qualified to participate to this discusion?

> who are you to determine who can participate here and who not?
> i just determined you are a very rude &$�"$"!/�$") and
> do not deserve to discuss here.

I'll join the club. *PLONK*

-- 
/-- Joona Palaste (palaste@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste       W++ B OP+                     |
\----------------------------------------- Finland rules! ------------/
"Make money fast! Don't feed it!"
   - Anon
0
palaste (2323)
10/8/2003 6:37:44 PM
Dan Pop wrote:

> In <clcm-20031008-0005@plethora.net> "cody"
> <dont.spam.me.deutronium@gmx.de> writes:
> 
>>is "const float PI=3.14" possible in plain C?
> 
> If you're not aware of the basic standard C features, what makes you
> think that you're qualified to participate to this discusion?

No qualification is required for participation in Usenet discussions in 
general[1] or comp.lang.c discussions in particular.

Having said that, cody provides a good case for introducing such a 
qualification.



[1] There are occasional exceptions, such as the mildly arcane qualification 
in the scary devil monastery (I won't give away the secret, but basically 
anyone who /can/ post there is, de facto, qualified to post there).

(I presume a.s.r still requires this trick?)

-- 
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
0
dontmail (1886)
10/8/2003 7:57:40 PM
"Mike Wahler" <mkwahler@mkwahler.net> wrote in message news:<PMSgb.2532$dn6.1849@newsread4.news.pas.earthlink.net>...

<snipped rather large post concerning trollish behaviour>

> 
> There.  I feel better now. :-)
> 

<grin> do you, then ?  a really really *really* small part
of me wants to type in "so, what was your C question?" :-)

goose,
   high on sugar, feeling silly right now
0
ruse (722)
10/8/2003 8:35:33 PM
"goose" <ruse@webmail.co.za> wrote in message
news:ff82ae1b.0310081235.2b339ca7@posting.google.com...
> "Mike Wahler" <mkwahler@mkwahler.net> wrote in message
news:<PMSgb.2532$dn6.1849@newsread4.news.pas.earthlink.net>...
>
> <snipped rather large post concerning trollish behaviour>
>
> >
> > There.  I feel better now. :-)
> >
>
> <grin> do you, then ?  a really really *really* small part
> of me wants to type in "so, what was your C question?" :-)

OK, I'll bite:

Did anybody here [C] that [C]hicago [C]ubs game
yesterday? What a [C]ontest!  A [C]lash of Titans.

The opposing [C]atcher [C]rushed a three-run homer,
[C]ausing his team to [C]ome [C]loser to victory.
[C]ommentators [C]alled it a [C]rucial at-bat.
It seemed to [C]ow the formerly [C]heering home
team [C]rowd.

A [C]enter fielder [C]omitted an error, allowing a
[C]rit[C]al run to s[C]ore.

The [C]losing pit[C]her made a [C]omplaint about
the umpire's  De[C]ision [C]on[C]erning a pit[C]h he
[C]onsidered a strike. "You [C]an't [C]!" he [C]laimed.

The opposing team managed to [C]ling to their lead,
[C]lapping ea[C]h other on the ba[C]k and [C]elebrating
after the [C]lose of the game.


Yes, I'm trying to be [C]lever and [C]reative, as
you [C]an [C], although I'm probably [C]ourting
[C]ondemndation by [C]ranky [C]oders, who might
demand [C]essation or [C]loset me in their killfiles
without [C]omment.

:-)

-Mike


0
mkwahler (3821)
10/8/2003 9:43:21 PM
Micah Cowan wrote in article <m3oewsundz.fsf@localhost.localdomain>:

> A Perl shell has been in existence for some time now.
> 
>   http://www.gregorpurdy.com/gregor/psh/

Well, hush my mouth.  Though I will say development on it appears sporadic
and slow.  Not something I think I would consider using though.


-- 
Todd Stephens
ICQ# 3150790
"A witty saying proves nothing." -Voltaire
0
Todd
10/8/2003 10:13:07 PM
Richard Heathfield <dontmail@address.co.uk.invalid> wrote:

> Dan Pop wrote:
> 
> [1] There are occasional exceptions, such as the mildly arcane qualification 
> in the scary devil monastery (I won't give away the secret, but basically 
> anyone who /can/ post there is, de facto, qualified to post there).
> 
> (I presume a.s.r still requires this trick?)

Yes.

Richard
0
rlb (4118)
10/9/2003 8:07:27 AM
"cody" <dont.spam.me.deutronium@gmx.de> wrote in message
news:bm1fk8$hpt5f$1@ID-176797.news.uni-berlin.de...
> that's what i call an answer :)
>
> > First, I will initially take at face value your statement
> > that you are not trolling.  Let's see what happens after
> > you read the following:
> >
> > I'm writing this because you probably do not realize
> > that Mr. Klein is one of the select few people here
> > who are the most highly qualified to help people to
> > learn and work with with the C language, as well as
> > to explain its various strengths and weaknesses, and
> > to help you decide if C is the most appropriate tool
> > for a particular task.
>
> i didn't know who he was

A good reason to "look before you leap" :-)

>i only knew  how he reacted to my
> question and his answer seemed to me a bit aggressive.

Many new visitors here get that impression.
People here have a wide variety of personalities.
Try to see past that, and I think you'll find this
place a good source of quality information.

>
> > > in pieces of the application where speed really matters
> > > you can still use "normal" functions or even static methods
> > > which is basically the same.
> > >
> > > in C there arent the simplest things present like constants,
> > > each struct and enum have to be prefixed with "struct" and
> > > "enum". iam sure there is much
> > > more.
> >
> > Jack replied as he did because he *knows* that:
> >
> > 1. C does not assign an attribute of "normal" or "abnormal"
> >    to functions.
> >
> > 2. C does not define anything called a "static method" or a
> >    "method".
>
> i mean't "why C instead of C++". i assumed all C programmers would use C++

Why?

> and so i said that this is no problem since in C++ they cann still use
> c-functions

Nobody said that using C++ is a problem.  Some said that
they're unable or unwilling to use it, for various reasons.

> or static functions as they are the same as c-functions, basically.

Functions declared as 'static' share the same characteristics
in C and C++, with one exception:

C++ defines a construct 'static member function' which has
no counterpart in C.

>
> iam sorry if i didn't made that clearer.
>
> > 6. C does indeed specify a keyword 'const' and its effect
> >    when applied.  A constant can also be expressed with a
> >    macro.
>
> i didn't knew that.

Again, "Look before you leap" :-)

>
> > Another logical question, again probably designed to
> > cause to to stop and think about what you wrote.
> > No personal attacks.  (Despite the belief to the
> > contrary by many, ignorance is not a character flaw,
> > it's simply a lack of education about one or more
> > subjects, easily rectified, and without any reason
> > for shame or embarrassment.)
>
> iam not an ignorant.

"Ignorant" is not a noun.  It is an adjective, used to
describe a person's level of knowledge about a given
subject.  As in, "I'm ignorant of the exact arrival
time of the train, since I don't have a schedule."
Or, "I'm ignorant about auto repair, I've lever learned
it."  "Ignorant" means "Don't know."

Ignorance is not a character flaw.  But in my opinion,
denial of it when it exists (which is what you seemed
to be doing), is.

>why do you think i asked this question?

To reduce your ignorance about C and C++,
I would hope.

> i only wanted reasons why people still use C. ok now i have got enough
> reasons.
>
> - C is simpler than C++
> - some people don't like OOP
> - some people don't want to learn OOP
> - some projects don't need OOP

OOP is not the only reason people use C++.  C++
can be used with many other programming styles.

So make those last three:
  - some people don't like C++
  - some people don't want to learn C++
  - some projects don't need C++

> - some platforms dosn't provide a proper C++ compiler.
>
> i didn' know that i would create such a large discussion.

Now you know. :-)

>
> > >Or is your wisdom to be
> > > > inferred by your lack of proper capitalization, punctuation, and
> > > > grammar?
> >
> > Perhaps this remark is justified, perhaps not.  It seems
> > that your irrefutable ignorance about C, combined with
> > your expression of conclusions without premises might
> > have caused him to associate your nonfluency with English
> > with your level of wisdom.
> >
> > I can understand this reaction, since when you wrote your
> > first post, (in this English-speaking newsgroup), you did not
> > indicate that English is not your native language, and
> > unfortunately, a significant number of people whose native
> > language *is* English post here with spelling, grammar,
> > etc. far worse than yours.
>
> so what do you advise? should i write in the subject of my next posting:
>
> "warning! german poster with probably wrong capitalization, punctuation
and
> grammar"

Actually, yes, something like that.  But keep the subject
line only about the actual question.  But then in the body
of your message, write a short note at the top:

"My native language is not English, please excuse errors,
 and ask if my message is not clear."

Many other non-English speakers post here, and this is
what most of them do.

If you post here very long, people will get to know you,
and this 'warning' will not be necessary every time.

>
> > The content of your post combined with the poor English
> > probably caused him to believe you were an American
> > or British troll.
>
> i didn't know that my english is so bad. i would be very grateful if
> somebody give me a hint what is wrong with my grammar.

Actually, after reading this, I believe your grammar seems
to have already improved. However, your capitalization needs
much work, though. :-)

Compare:

I didn't know that my English is so bad. I would be very
grateful if somebody gave me a hint about what is wrong with
my grammar.

You don't need to be perfect, nobody is.  Just do the best
you can.

>
> > I understand very little German, but my few halfhearted
> > attempts to learn it quickly informed me that many more
> > words are capitalized in German than in English; it seems
> > that every noun is capitalized (only my impression, I'm
> > not certain.)
>
> that is correct all nouns, proper names and beginnings of a sentence are
> capitalised.

In English, capitalize the first word of every sentence,
and all pronouns (for example "I")  and proper nouns.

>
> > If your defense of your English is that
> > you're German, I would have expected too many capital
> > letters, not none at all. :-)
>
> you underestimated my lazyness :-[=]

Yes, sometimes I get lazy, too.

>
> >
> > My brief 'learning' experiences with German also indicates
> > that it uses punctuation as well.  Is it true that the
> > only punctuation characters used consistently are periods
> > and apostrophes, and that commas are optional, as your
> > messages seem to show?
>
> some commas in german are optional.

English has firm rules about commas, but hardly anyone
understand them all or agrees about them.  I try to
use them where, if I were speaking, I would pause.
It seems to work for me.

>  Is it true that sentences are begun in lower case?
>
> neither in english nor in german but my shiftkey is broken.
> i brough is to the workshop last week but it is still not ready :)

But how did you write "C", "C++", "OO", and "OOP" in
your messages?

>
> > 1.  Why do you seem to feel that OOP is the solution to
> >     all programming issues?  Have you blindly believed
> >     the 'mass media'?
>
> no, but you can use C++ without programming OOP sinc C++ is a hybrid
> language
> which supports various programming paradigms, including structured,oop,
> functional and more.

Yes.  But then why did you write above:

> i only wanted reasons why people still use C. ok now i have got enough
> reasons.
>
> - C is simpler than C++
> - some people don't like OOP
> - some people don't want to learn OOP
> - some projects don't need OOP

Three out of four imply that C++ == OOP and nothing else,
which is simply not true.

So it seems to me that either you still believe this,
or have changed your mind.

By the way, C++ does not have direct support for functional
programming. What you probably mean is 'procedural programming'.



>
> > 2.  OOP can be done in virtually any language.  Why do
> >     you feel that using a given language's available features
> >     to implement OOP is somehow 'fake'?
>
> oop need language support at least to a certain level.

No.  Whatever built-in support is not there can be
written using existing language features in virtually
any language.  It could even be done in assembly language,
especially one which has macros, if you have enough time. :-)

>when people programm
> oop in C then it is certainly faked.

No.  They use the language features which are available
to program in whatever paradigm they want.  This does
not make it 'fake'.  C++ is often preferred when doing
OOP, because of its built-in features which support it,
and help prevent making mistakes.

>
> > 3.  Why do you believe that the insertion of a pointer to
> >     a function into a structure causes the use of that
> >     structure and its function pointer member(s) to become
> >     a component of OOP or OOP itself?
>
> it was just an example how some people fake oop in c.

It's not 'fake'.  Also, a function pointer inside a struct
can be (and is) used for other things besides OOP.

>
> > 4.  Are you unaware of the several other concepts and
> >     techniques which comprise OOP?
>
> yes. i have good knowlegde about c++,c# and java. a OO-language needs
> classes,ctors,dtors,virtual,abstract,static methods and access modifiers.

Some of those things people will say must exist as built-in
features in order to call a language a "true" or "pure" OO
language. There is always much debate about this, which I
doubt will ever result in any consensus.

But all of those concepts can be implemented in any language
at all.  It often requires more work, but it can be (and is)
done.

> i consider operator overloading as optional.

It's a very useful tool, but is not an OO concept.
I also often see it overused and abused.

>
> does C++ have a concept of sealed classes? that are classes which cannot
be
> subclassed.

No.  It doesn't need them.  If you want to talk about
that further, post a question about it to comp.lang.c++

Many others have already asked about and discussed this
issue in that newsgroup, try reading the older messages
about it.

>
> > Why do you believe that C++ is the only language which
> > has features and constructs which directly support OOP?
>
> surely not. it was just an example cos c++ is the successor of c.

Not really.  C++ was derived from C, but is not at all
intended to replace it.

>
> > You probably have a tool box in your garage.  What's
> > inside?  Just a hammer?  Just a screwdriver?  I suspect
> > it contains a variety of useful tools. This concept
> > does not disappear in the programming world.
>
> thats what i meant. why use a tool or another when you have a tool which
> combines both?

How large or heavy is the combined tool?  How much
does is cost? I'd use the easiest to use tool that
does the job.  C++ is a very large language compared
to C, and much more difficult to learn.

> why use C when you can use C++ which contains C? thats what i meant.

Another misconception.   C++ does *not* contain C.  It has
many similar things, but many of them which *look* exactly
the same, will *behave* differently in each language, often
very subtly.  This misconception is a source of many bugs
and incorrect programs (and arguments. :-) )

> you can
> use c++,
> nobody will force you to use its additinal features.

But you must use the language itself, which is *different*
from C.  The C standard library functions are all available,
but that's not the same thing as the *language*, which is
*not* the same.

>
> > > prove that my thaughts are illogical.
> >
> > I believe I've done that above.  I've done this with the
> > intention of helping you.  I'm curious as to how you will react.
>
> iam indeed grateful as you pointed out that my question was misunderstood
> here.

Perhaps.  But we all know that you have misunderstood what
C and C++ are and are not.  We tried to tell you this.

> i was wondering why some people didn't understand it, now i know why.

It doesn't really matter why, but you didn't understand
about C *or* C++.  We tried to tell you this.

>
> > Are you saying that when a programming language reaches a
> > certain age it becomes obsolete or 'unreasonable to use'?
> > Why?
>
> no, i'm not saying that.

Your previous comments seem to indicate otherwise.

> > Have you never considered the *domain* of a particular
> > language?  Are you unaware of the concept of "existing code
> > base?"  Simple economics?
>
> nobody will throw away C. it still exists in C++

No, absolutely not.

>as C++ is fully backward
> compatible

No, absolutely not.

>(at least C94 if iam correctly informed)

You have not been correctly informed.

>
> > Would you have people throw away perfectly good code
> > which *already performs its task satisfactorily*
> > and write it all over again from scratch?  Expend the
> > resources for design alterations often necessary when
> > moving to a new language?  For testing and debugging?
> > For the extra hardware probably required for the necessary
> > "run in parallel" period? In a pointless, misguided quest
> > to be "modern?"
>
> surely not.

Your previous comments seem to indicate otherwise.

>
> > Are you suffering from the misconception that any given
> > single language is or can be the solution to all programming
> > issues?
>
> surely not.

Your previous comments seem to indicate otherwise.

>
> > If you want to discuss or learn about C, this is the place.
> > If you want to criticize it or compare it with other languages,
> > this is not the place.
>
> i wanted to learn about C why people still use it  and now i know why :)

Much more than you wanted to hear, I suspect. :-)

>
> > There.  I feel better now. :-)
>
> me to..
>
> now i know why iam always misunderstood here: it certainly is my bad
grammar
> :-)

That is only a small part of it.  Most of us understood
you well enough to know what you were saying. You *definitely*
did *not* understand what C and C++ are and are not.
That's not a crime, or anything to be ashamed about,
all you need to do is learn.  The best in the business
read and post here, and you can learn much about C from
them. I certainly have, and continue to learn more every
day. The same is true about C++ in the newsgroup comp.lang.c++

Good luck, and have a nice day.

-Mike



0
mkwahler (3821)
10/9/2003 8:36:03 PM
Sidney Cadot <sidney@jigsaw.nl> wrote in message news:<blqeq9$1lc$1@news.tudelft.nl>...
> I can't answer for people in general of course, but as a moderately
> able C programmer with a thorough dislike of C++ I can try to
> explain what my motives are.
<snip>

That was an excellent response, thank you.

For my current work (programming for an embedded device), use of C++
over C is really a matter of notational convenience.  I turn off
exceptions and I do not use templates save for one trivial vector
class (hand-written, not STL).

By notational convenience I mean,

(1) I don't need to say self->data, I can just say m_data.  It doesn't
    sound like a big deal, but all that s-> clutter really adds up.
    Applications for this device cannot use static data, so every
    piece of data must come from a struct or class.

(2) The ARM CPU doesn't have floating point.  It is an enormous
    advantage to define my own fixed-point class with +, -, *, /, etc
    operators.

(3) Virtual functions are used but not common.  In this regard I trust
    my C++ compiler.  There is very little difference in code size.  I
    always know which virtual functions are overridden by which
    subclasses so it's just a "distributed switch statement".

(4) I get a warm, fuzzy feeling using socket.open() verses
    My_Library_Socket_open(socket).  You could call this a straw man,
    but I am especially careful about name clashes.  The alternatives
    are (a) to be not so careful or (b) to rig function pointers
    inside structs.  I don't like either.

(5) 'extern "C"' can be used if you want an application such as
    Mathematica to call into your C++ library.  In fact, that's
    exactly what I'm doing.

What is your opinion on using a limited subset of C++, if only for
convenience?

Jeff
0
10/9/2003 10:40:02 PM
> "Ignorant" is not a noun.  It is an adjective, used to
> describe a person's level of knowledge about a given
> subject.

In german there "Ignorant" can be used as noun or adjective.

> In English, capitalize the first word of every sentence,
> and all pronouns (for example "I")  and proper nouns.

i know, its just my lazyness which hinders me to do that :)

> > neither in english nor in german but my shiftkey is broken.
> > i brough is to the workshop last week but it is still not ready :)
>
> But how did you write "C", "C++", "OO", and "OOP" in
> your messages?

magic :)

> No.  Whatever built-in support is not there can be
> written using existing language features in virtually
> any language.  It could even be done in assembly language,
> especially one which has macros, if you have enough time. :-)

i disagree on that. how can you make sure that all data is properly
encapsulated if
the language provides no support?

> It's not 'fake'.  Also, a function pointer inside a struct
> can be (and is) used for other things besides OOP.

i know

> > thats what i meant. why use a tool or another when you have a tool which
> > combines both?
>
> How large or heavy is the combined tool?  How much
> does is cost? I'd use the easiest to use tool that
> does the job.  C++ is a very large language compared
> to C, and much more difficult to learn.

the new tool is very heavy and hard to use, it has many buttons and if you
press the wrong one the whole thing blows up. that's C++.

> By the way, C++ does not have direct support for functional
> programming. What you probably mean is 'procedural programming'.

not C++ as language, but the STL has many functions/functors which are used
for the functional programming paradigm.
the "repeat" function is an example.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk


0
10/10/2003 12:20:06 AM
"cody" <dont.spam.me.deutronium@gmx.de> wrote in message
news:bm4tvc$j3i47$1@ID-176797.news.uni-berlin.de...
> > "Ignorant" is not a noun.  It is an adjective, used to
> > describe a person's level of knowledge about a given
> > subject.
>
> In german there "Ignorant" can be used as noun or adjective.

I wrote my message in English.

> > In English, capitalize the first word of every sentence,
> > and all pronouns (for example "I")  and proper nouns.
>
> i know, its just my lazyness which hinders me to do that :)

I think you'll find that you will be taken much
more seriously if you make the effort to write
correctly.  Around here, laziness is not well
received.

>
> > > neither in english nor in german but my shiftkey is broken.
> > > i brough is to the workshop last week but it is still not ready :)
> >
> > But how did you write "C", "C++", "OO", and "OOP" in
> > your messages?
>
> magic :)

No, you've been caught in a lie.  Just admit it,
apologize, and perhaps people will take you seriously.

>
> > No.  Whatever built-in support is not there can be
> > written using existing language features in virtually
> > any language.  It could even be done in assembly language,
> > especially one which has macros, if you have enough time. :-)
>
> i disagree on that.
>how can you make sure that all data is properly
> encapsulated if
> the language provides no support?

Most programmers use their brains, and don't
let the language do all their thinking for them.

>
> > It's not 'fake'.  Also, a function pointer inside a struct
> > can be (and is) used for other things besides OOP.
>
> i know

You know it's not 'fake'?  Then why did you call it
'fake' *two* times?

>
> > > thats what i meant. why use a tool or another when you have a tool
which
> > > combines both?
> >
> > How large or heavy is the combined tool?  How much
> > does is cost? I'd use the easiest to use tool that
> > does the job.  C++ is a very large language compared
> > to C, and much more difficult to learn.
>
> the new tool is very heavy and hard to use, it has many buttons and if you
> press the wrong one the whole thing blows up. that's C++.

So don't use it.  But your first message was claiming
that people should not use C and use C++ instead.

I use both C and C++ and have successfully written
many programs with them.  Some I have written using
a combination of both.  Nothing "blows up".

>
> > By the way, C++ does not have direct support for functional
> > programming. What you probably mean is 'procedural programming'.
>
> not C++ as language, but the STL has many functions/functors which are
used
> for the functional programming paradigm.

If you really think so, post a message (not here), but
at comp.lang.c++ and tell me what they are.

> the "repeat" function is an example.

There is no 'repeat' function in C++ (or in C either).

But if you want to talk about C++, here is not the place.
Go to comp.lang.c++ to discuss C++. But I'll warn you
that the most expert C++ people in the world are there,
and know if what you say is right or wrong.  Much of
what I learned about C++ I learned from them.

I suggest you start there by *asking questions* not
*telling* people about C++, since you obviously have many
misconceptions about it.

But be sure to read their FAQ first.


-Mike


0
mkwahler (3821)
10/10/2003 2:53:59 AM
> > In german there "Ignorant" can be used as noun or adjective.
>
> I wrote my message in English.

I just wanted to say that in german it can be used as noun, too.

> > > > neither in english nor in german but my shiftkey is broken.
> > > > i brough is to the workshop last week but it is still not ready :)
> > >
> > > But how did you write "C", "C++", "OO", and "OOP" in
> > > your messages?
> >
> > magic :)
>
> No, you've been caught in a lie.  Just admit it,
> apologize, and perhaps people will take you seriously.

you don't understand humour, do you?

> > > No.  Whatever built-in support is not there can be
> > > written using existing language features in virtually
> > > any language.  It could even be done in assembly language,
> > > especially one which has macros, if you have enough time. :-)
> >
> > i disagree on that.
> >how can you make sure that all data is properly
> > encapsulated if
> > the language provides no support?
>
> Most programmers use their brains, and don't
> let the language do all their thinking for them.

then try to programm a fully functioning OOP application in pure C.
it is impossible to make sure no one can unintentional access private
variables.

> > > It's not 'fake'.  Also, a function pointer inside a struct
> > > can be (and is) used for other things besides OOP.
> >
> > i know
>
> You know it's not 'fake'?  Then why did you call it
> 'fake' *two* times?

storing a function pointer in a struct is commonly used by C programmers.
But i noticed that some programmers abused this to fake OOP features.

> > the "repeat" function is an example.
>
> There is no 'repeat' function in C++ (or in C either).

my mistake, i thought there was. however there is a foreach function which
has
a bit of functional programming  and there is a header file which name is
<functional>.


--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk


0
10/10/2003 1:12:53 PM
On 06 Oct 2003 18:50:21 GMT, Douglas A. Gwyn <DAGwyn@null.net> wrote:
> cody wrote:
>> i heard people say C++ is slower than C but i can't believe that. in pieces
>> of the application where speed really matters you can still use "normal"
>> functions or even static methods which is basically the same.
> 
> There is both a speed and size penalty for using C++ where
> pain C would do.  The penalty isn't as bad as it used to be.
  ^^^^

I usually think of C++ as being 'painful C' myself.  ;-)

Dave
-- 
You'll need to kill a tree to mail me.
0
drdvpTREE (4)
10/10/2003 4:59:35 PM
Dave Von Pless wrote:

> On 06 Oct 2003 18:50:21 GMT, Douglas A. Gwyn <DAGwyn@null.net> wrote:
>> cody wrote:
>>> i heard people say C++ is slower than C but i can't believe that. in
>>> pieces of the application where speed really matters you can still use
>>> "normal" functions or even static methods which is basically the same.
>> 
>> There is both a speed and size penalty for using C++ where
>> pain C would do.  The penalty isn't as bad as it used to be.
>   ^^^^
> 
> I usually think of C++ as being 'painful C' myself.  ;-)
> 
> Dave

To be honest, I started programming with C++, and quite often think of C as
the more painful to use for many things.  I guess it just depends on which
direction your coming from.  Kind of like when country boys see the city as
a rude, dirty, and corrupt while the city boys see the country as
backwards, dirty, and twisted.

Sean

0
sfraley (9)
10/10/2003 6:24:51 PM
cody wrote:

> then try to programm a fully functioning OOP application in pure C.
> it is impossible to make sure no one can unintentional access private
> variables.

Well, the same is the case in C++. I hope not to be chastized too hard 
by the crowd here for showing some C++ code but here you go:

#include <iostream>

class YadaYada {
  private:
   int a;
  public:
   YadaYada() { a=0; }
   void showme() { std::cout << a << std::endl; }
};

int main()
{
   YadaYada y;
   y.showme();
   *(int *)&y=1;
   y.showme();
   return 0;
}

....Now compare this with some C code that tries to do member hiding:

#ifdef INTERNAL
#define PRIVATE(x) x
#else
#define PRIVATE(x) this_is_private_do_not_touch_me_ ## x
#endif

struct YadaYada {
   int PRIVATE(a);
};

Sure, the C way is clunky at best. My point, however, is that both in C 
and C++ it is quite possible to circumvent the measures taken for hiding 
private data; in both of the examples shown above you would simply have 
to be malicious to do it. If you're looking for OOP languages with truly 
shielded private variables, you should be reading up on programming 
languages instead of ascribing properties to C++ that it doesn't have.

> my mistake, i thought there was. however there is a foreach function which
> has a bit of functional programming  and there is a header file which name is
> <functional>.

Pardon me if I'm wrong, but you truly come across as if you haven't got 
a clue as to what you are talking about. Perhaps you care to explain 
what exactly it is you mean by 'functional programming' - we may both 
learn a thing or two.

Then again, this kind of discussion should perhaps be rerouted to 
comp.lang.functional - might I also suggest a fitting debut: "Why do 
people still use Lisp? ML is so much better..."



0
sidney (345)
10/10/2003 11:20:20 PM
Jeff Mitchell wrote:

> That was an excellent response, thank you.

Why thank you. That was written at a stage, of course, where I thought 
that cody asked his question in order to learn instead of {t|pr}each.

You provide some good reasons why C++ has notational (but no less real) 
advantages over C, I think. The important thing in my opinion is to make 
an informed decision on ones language of choice for tackling a certain 
problem, instead of just going with the tide - which nowadays probably 
favors C++ over C. I can surely imagine that using C++ is a viable 
option in many circumstances, especially if you limit yourself to the 
subset of the language you understand, and understand the possible 
ramifications with regard to portability etc.

I especially was interested in your fifth point:

> (5) 'extern "C"' can be used if you want an application such as
>     Mathematica to call into your C++ library.  In fact, that's
>     exactly what I'm doing.

I know that this is quite possible, but for my current project we 
refrained from doing this for lack of information about portability. 
Yes, we could get it to work using gcc/g++ on Intel/Apple, but our 
library also has to work on HP-UX, Solaris, AIX, SGI, ..., with their 
proprietary compiler suites.

One testimony to C portability is that this has worked out pretty well 
(with something in the order of 100,000 lines of code). There's quite a 
thrill in getting a report of a successful HP-UX compile out of the 
blue, when you haven't actually tested on such a machine!

(Then again, reading the previous sentence, I think the most important 
conclusion is that I need to get out more and get a life outside 
computers ;-))

Best regards,

   Sidney Cadot
   The Netherlands

0
sidney (345)
10/10/2003 11:40:16 PM
Sidney Cadot wrote:

<snip>

> ...Now compare this with some C code that tries to do member hiding:
> 
> #ifdef INTERNAL
> #define PRIVATE(x) x
> #else
> #define PRIVATE(x) this_is_private_do_not_touch_me_ ## x
> #endif
> 
> struct YadaYada {
>    int PRIVATE(a);
> };
> 
> Sure, the C way is clunky at best.

Well, that way is. What about this way? Here's an extract from one of my 
headers:

typedef struct TCPi_ TCP;

Beat that for data hiding!

(Yes, you can still defeat it maliciously, e.g. with an unsigned char * 
pointer or with memset, but (unless you were simply destroying existing 
values) you'd have to know what the data items are for, how big they are, 
and which order they are in, and the visible code gives you no hints 
whatsoever).

-- 
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
0
dontmail (1886)
10/11/2003 3:17:04 AM
Richard Heathfield wrote:

>>#ifdef INTERNAL
>>#define PRIVATE(x) x
>>#else
>>#define PRIVATE(x) this_is_private_do_not_touch_me_ ## x
>>#endif
>>
>>struct YadaYada {
>>   int PRIVATE(a);
>>};
>>
>>Sure, the C way is clunky at best.
> 
> 
> Well, that way is. What about this way? Here's an extract from one of my 
> headers:
> 
> typedef struct TCPi_ TCP;
> 
> Beat that for data hiding!

Yes, good point.

But suppose you want to have some private and some public members, I 
think you're stuck with a variation of what I showed (a feeble excuse 
for my clumsy example, but still a slightly valid point I think).

This touches on an interesting notational point with regard to C++ 
syntax: you are forced to expose both private and public members in the 
source code of the declaration of the class. Something similar with 
Java, where declaration and definition coincide. Your are basically 
forced to use a postprocessor on the source to be able to present a 
version that is not cluttered with internals (e.g. doxygen for C++ or 
javadoc for Java). I've always considered that to be bit untidy.

Regards,

   Sidney

0
sidney (345)
10/11/2003 10:17:17 AM
> Well, that way is. What about this way? Here's an extract from one of my
> headers:
>
> typedef struct TCPi_ TCP;
>
> Beat that for data hiding!


i don't understand what you mean with that.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk


0
10/11/2003 1:44:10 PM
Sidney Cadot wrote:

> Richard Heathfield wrote:
> 
>>>#ifdef INTERNAL
>>>#define PRIVATE(x) x
>>>#else
>>>#define PRIVATE(x) this_is_private_do_not_touch_me_ ## x
>>>#endif
>>>
>>>struct YadaYada {
>>>   int PRIVATE(a);
>>>};
>>>
>>>Sure, the C way is clunky at best.
>> 
>> 
>> Well, that way is. What about this way? Here's an extract from one of my
>> headers:
>> 
>> typedef struct TCPi_ TCP;
>> 
>> Beat that for data hiding!
> 
> Yes, good point.
> 
> But suppose you want to have some private and some public members, I
> think you're stuck with a variation of what I showed (a feeble excuse
> for my clumsy example, but still a slightly valid point I think).

I think that I'm unlikely to want a mixture. If it is vital to /have/ a 
mixture, though, I'd give serious consideration to using C++ instead. (And 
this is me saying it.)

-- 
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
0
dontmail (1886)
10/11/2003 5:50:16 PM
cody wrote:

>> Well, that way is. What about this way? Here's an extract from one of my
>> headers:
>>
>> typedef struct TCPi_ TCP;
>>
>> Beat that for data hiding!
> 
> 
> i don't understand what you mean with that.

That figures. Look up the word "struct" in your C book. Then look up 
"typedef" in the same book. Then Google for "opaque types".

-- 
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
0
dontmail (1886)
10/11/2003 6:00:35 PM
Sidney Cadot <sidney@jigsaw.nl> writes:

> #ifdef INTERNAL
> #define PRIVATE(x) x
> #else
> #define PRIVATE(x) this_is_private_do_not_touch_me_ ## x
> #endif
> 
> struct YadaYada {
>    int PRIVATE(a);
> };

That's only valid if you don't mind invoking undefined behavior.
From C99 6.2.7:

     Moreover, two structure, union, or enumerated types declared
     in separate translation units are compatible if their tags
     and members satisfy the following requirements: If one is
     declared with a tag, the other shall be declared with the
     same tag. If both are complete types, then the following
     additional requirements apply: there shall be a one-to-one
     correspondence between their members such that each pair of
     corresponding members are declared with compatible types,
     and such that if one member of a corresponding pair is
     declared with a name, the other member is declared with the
     same name.
-- 
"...deficient support can be a virtue.
 It keeps the amateurs off."
--Bjarne Stroustrup
0
blp (3955)
10/11/2003 6:35:30 PM
"Richard Heathfield" <dontmail@address.co.uk.invalid> schrieb im Newsbeitrag
news:bm9gg2$eeg$4@hercules.btinternet.com...
> cody wrote:
>
> >> Well, that way is. What about this way? Here's an extract from one of
my
> >> headers:
> >>
> >> typedef struct TCPi_ TCP;
> >>
> >> Beat that for data hiding!
> >
> >
> > i don't understand what you mean with that.
>
> That figures. Look up the word "struct" in your C book. Then look up
> "typedef" in the same book. Then Google for "opaque types".


ok, it is simply that in clients where all structure members should be
private include a header where TCP is defined as void*
and only the the clients that should see the members get a header file where
TCP is a typedef for a struct.

dirty, but interesting trick.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk


0
10/11/2003 7:04:04 PM
cody wrote:

> "Richard Heathfield" <dontmail@address.co.uk.invalid> schrieb im
> Newsbeitrag news:bm9gg2$eeg$4@hercules.btinternet.com...
>> cody wrote:
>>
>> >> Well, that way is. What about this way? Here's an extract from one of
> my
>> >> headers:
>> >>
>> >> typedef struct TCPi_ TCP;
>> >>
>> >> Beat that for data hiding!
>> >
>> >
>> > i don't understand what you mean with that.
>>
>> That figures. Look up the word "struct" in your C book. Then look up
>> "typedef" in the same book. Then Google for "opaque types".
> 
> 
> ok, it is simply that in clients where all structure members should be
> private include a header where TCP is defined as void*

No.

> and only the the clients that should see the members get a header file
> where TCP is a typedef for a struct.

No. The client code never sees the member data at all. Only the library code 
does.

> 
> dirty, but interesting trick.

Dirty? No, I don't think so. It works on the same principle as FILE, only 
more so. Interesting? Certainly. Trick? No. It's a useful production code 
technique.

-- 
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
0
dontmail (1886)
10/11/2003 8:20:52 PM
Ben Pfaff wrote:

>>#ifdef INTERNAL
>>#define PRIVATE(x) x
>>#else
>>#define PRIVATE(x) this_is_private_do_not_touch_me_ ## x
>>#endif
>>
>>struct YadaYada {
>>   int PRIVATE(a);
>>};

> That's only valid if you don't mind invoking undefined behavior.
> From C99 6.2.7:
> 
>      Moreover, two structure, union, or enumerated types declared
>      in separate translation units are compatible if their tags
>      and members satisfy the following requirements: If one is
>      declared with a tag, the other shall be declared with the
>      same tag. If both are complete types, then the following
>      additional requirements apply: there shall be a one-to-one
>      correspondence between their members such that each pair of
>      corresponding members are declared with compatible types,
>      and such that if one member of a corresponding pair is
>      declared with a name, the other member is declared with the
>      same name.

Type-compatibility may not be an issue here (I'm not sure). It would 
certainly be illegal to include the YadaYada definition twice in the 
same program, once with INTERNAL defined, once with INTERNAL not defined.

However, in the context of data hiding this idiom (with the YadaYada 
declaration in a header file) would be used once to compile e.g. a 
library (with INTERNAL defined, providing easy access to the members of 
the YadaYada type from within the library code); next, a program using 
the library (including the header file containing the YadaYada 
declaration, with INTERNAL not defined) would have no access to the 
members marked PRIVATE (except by advertantly circumventing the name 
mangling).

On the question of whether the scheme layed out above is guaranteed to 
work, let's put this question in program form:

---

#include <stdio.h>

struct A {
   int tom;
   int dick;
   int harry;
};

struct B {
   int tom;
   int george;
   int harry;
};

int main(void)
{
   struct A a;

   a.dick=3;

   /* will this print 3, guaranteed? */
   printf("%d\n", ((struct B *)&a)->george);

   return 0;
}

---

I'd like an expert opinion on this... There are limits to what a 
compiler may do to the fields in a struct, I would be curious to know if 
these limits are strong enough for the above program to have 
well-defined behavior (and thus print '3') ?

Best regards,

   Sidney Cadot




0
sidney (345)
10/12/2003 2:21:35 AM
"cody" <dont.spam.me.deutronium@gmx.de> wrote in message
news:bm91er$klpbk$1@ID-176797.news.uni-berlin.de...
> > Well, that way is. What about this way? Here's an extract from one of my
> > headers:
> >
> > typedef struct TCPi_ TCP;
> >
> > Beat that for data hiding!
>
>
> i don't understand what you mean with that.

To me, it means you do not understand at all what
"Object oriented programming" means, despite your
attempts to indicate otherwise.

-Mike


0
mkwahler (3821)
10/12/2003 5:10:57 AM
"cody" <dont.spam.me.deutronium@gmx.de> wrote in message
news:bm6b8a$iihhh$1@ID-176797.news.uni-berlin.de...
> > > In german there "Ignorant" can be used as noun or adjective.
> >
> > I wrote my message in English.
>
> I just wanted to say that in german it can be used as noun, too.
>
> > > > > neither in english nor in german but my shiftkey is broken.
> > > > > i brough is to the workshop last week but it is still not ready :)
> > > >
> > > > But how did you write "C", "C++", "OO", and "OOP" in
> > > > your messages?
> > >
> > > magic :)
> >
> > No, you've been caught in a lie.  Just admit it,
> > apologize, and perhaps people will take you seriously.
>
> you don't understand humour, do you?

Certainly I do.  Most people I know tell me I have
an extraordinary sense of humor.  But I fail to see
any humor in this.  Perhaps simply a "cultural
difference." Whatever, I won't waste any time
debating it.

> > > > No.  Whatever built-in support is not there can be
> > > > written using existing language features in virtually
> > > > any language.  It could even be done in assembly language,
> > > > especially one which has macros, if you have enough time. :-)
> > >
> > > i disagree on that.
> > >how can you make sure that all data is properly
> > > encapsulated if
> > > the language provides no support?

It does provide it.  What do you mean by "properly"?

struct data
{
    int details;
};

The value 'details' is properly encapsulated inside
the  struct type 'data'. This encapsulation could
indeed be corrupted via making coding errors, but
this does *not* mean the encapsulation is 'improper'.

> > Most programmers use their brains, and don't
> > let the language do all their thinking for them.
>
> then try to programm a fully functioning OOP application in pure C.

I certainly could, but have never had any reason to do so.
I suspect that some people actually have done this. I have
no motivation to spend the necessary time on it, but perhaps
if someone were to pay me to do it....

> it is impossible to make sure no one can unintentional access private
> variables.

The existence of the possibility of coding errors does
not preclude a program from being expressed with OOP.
A language's enforcements of OOP concepts is a very
useful tool, but need not be present for a program
to be expressed using OOP.

> > > > It's not 'fake'.  Also, a function pointer inside a struct
> > > > can be (and is) used for other things besides OOP.
> > >
> > > i know
> >
> > You know it's not 'fake'?  Then why did you call it
> > 'fake' *two* times?
>
> storing a function pointer in a struct is commonly used by C programmers.

Yes, it is used for a wide variety of purposes, one of which
could be to implement OOP.

> But i noticed that some programmers abused this to fake OOP features.

It's *not* fake.  Specialized language support (as in
C++ for example) is not a prerequiste for using that
language to write OOP programs.

> > > the "repeat" function is an example.
> >
> > There is no 'repeat' function in C++ (or in C either).
>
> my mistake, i thought there was.

I strongly suggest you research these issues before
making such statements in the future.

>however there is a foreach function which
> has
> a bit of functional programming

No.  'for_each()' is simply a function which iterates
through a sequence, and applies a function to each
member of that sequence.  It's a generalization of
a simple 'for loop', designed to be useful with
the standard library 'container' abstraction.
Nothing at all to do with 'functional programming'.


>and there is a header file which name is
> <functional>.

Which has nothing to do with 'functional programming',
("Do not judge a book by its cover.")

Again, the C++ issues you mention should be discussed
in comp.lang.c++, not here.

-Mike



0
mkwahler (3821)
10/12/2003 5:28:50 AM
Mike Wahler wrote:
....
> Most people I know tell me I have
> an extraordinary sense of humor.

This proves nothing. BTW, it could stand for "none at all" as well.

Jirka

0
jklaue2 (127)
10/12/2003 12:11:46 PM
> > > > i disagree on that.
> > > >how can you make sure that all data is properly
> > > > encapsulated if
> > > > the language provides no support?
>
> It does provide it.  What do you mean by "properly"?
>
> struct data
> {
>     int details;
> };
>
> The value 'details' is properly encapsulated inside
> the  struct type 'data'. This encapsulation could
> indeed be corrupted via making coding errors, but
> this does *not* mean the encapsulation is 'improper'.

This is no encapsulation. encapsulation means that nobody (except the class
itself)
can access the variable directly, or the direct acess is limited to certain
classes for example derived classes or friend classes.

You are talking about things you don't understand. But the same is true for
me when i talk about plain C :)

> The existence of the possibility of coding errors does
> not preclude a program from being expressed with OOP.
> A language's enforcements of OOP concepts is a very
> useful tool, but need not be present for a program
> to be expressed using OOP.

This is the point of encapsulation. it simply cannot happen that you access
a variable that you have no access to,
due to coding mistakes (Except you unintentional manipulate the variable
using a memory address if you know its offset in the struct/class)

> No.  'for_each()' is simply a function which iterates
> through a sequence, and applies a function to each
> member of that sequence.  It's a generalization of
> a simple 'for loop', designed to be useful with
> the standard library 'container' abstraction.
> Nothing at all to do with 'functional programming'.

Functional programming means you don't say how you want it done like in
[C/C++/Pascal or similar] but you just say what you want have done.

for (int i=0; i<10; i++) a[i]+=2;  /* you excatly say how to do it  */

for_each (myContainer, MultiplicateWith(2))  /* you just say what is to do
you don't care about how it should be done */

That's the way functional languages like haskell or lisp or whatever solves
problems.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk


0
10/12/2003 1:58:13 PM
On Fri, 10 Oct 2003 15:12:53 +0200, cody wrote:

> "Mike Wahler" <mkwahler@mkwahler.net> wrote:
>> Most programmers use their brains, and don't
>> let the language do all their thinking for them.
> 
> then try to programm a fully functioning OOP application in pure C.
> it is impossible to make sure no one can unintentional access private
> variables.

 See, this is a big difference in mindset. I don't often find that I need
to fight with users of my code. So if I do...

struct mystr
{
  size_t len; /* public: read-only */
  size_t sz;  /* private */
  char *data; /* private */
};

extern int mystr_allocate(struct mystr *, size_t);
extern int mystr_append_cstr(struct mystr *, const char *);

....it's obvious what you are supposed to do with the struct, and if you
are altering you should be expecting to get burnt.
 And, hey maybe somewhere someone needs to look at or alter a member in
some way.

 However if you want to fight with your co-workers, then you can do
something like...

/* external header */
struct mystr
{
  size_t len; /* public: read-only */
};

extern int mystr_allocate(struct mystr *, size_t);
extern int mystr_append_cstr(struct mystr *, const char *);

/* internal header... */
struct mystr__i
{
  struct mystr pub;
  size_t sz;  /* private */
  char *data; /* private */
};

/* C file... */
int mystr_allocate(struct mystr *passed_s1, size_t sz)
{
  struct mystr__i *s1 = (struct mystr__i *)passed_s1;
 /* ... */
}

> storing a function pointer in a struct is commonly used by C programmers.
> But i noticed that some programmers abused this to fake OOP features.

 And this is fake compared to typing "virtual" ... why?

-- 
James Antill -- james@and.org
Need an efficient and powerful string library for C?
http://www.and.org/vstr/

0
10/12/2003 6:02:14 PM
cody wrote:

>> > > > i disagree on that.
>> > > >how can you make sure that all data is properly
>> > > > encapsulated if
>> > > > the language provides no support?
>>
>> It does provide it.  What do you mean by "properly"?
>>
>> struct data
>> {
>>     int details;
>> };
>>
>> The value 'details' is properly encapsulated inside
>> the  struct type 'data'. This encapsulation could
>> indeed be corrupted via making coding errors, but
>> this does *not* mean the encapsulation is 'improper'.
> 
> This is no encapsulation.

It's not a great example of encapsulation, but it can be legitimate, 
depending on your definition of "encapsulation".

> encapsulation means that nobody (except the
> class itself)
> can access the variable directly, or the direct acess is limited to
> certain classes for example derived classes or friend classes.

That depends on your definition of "encapsulation". You seem to be using the 
"Design Patterns" definition, which isn't the one I'd have chosen. You are 
basically arguing over definitions, not concepts.

> You are talking about things you don't understand. But the same is true
> for me when i talk about plain C :)

Then stop talking about C, and start reading about it instead.

-- 
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
0
dontmail (1886)
10/12/2003 7:51:09 PM
[comp.std.c removed from follow-up list]

On Wed, 8 Oct 2003, cody wrote:
>
> > > pieces of the application where speed really matters you can still use
> > > "normal" functions or even static methods which is basically the same.
> >
> > Suck it and see.
>
> ?

A colloquialism roughly equivalent to "why don't you try it and find
out, instead of whining to me about it?"


> > int main(void)
> > {
> >   const int new = 6; /* I rest my case */
> >   return 0;
> > }
>
> i though in standard C, there isn't such a thing like "const" you can only
> use macros to fake them.

Well, you're wrong.  Your response here, and your response to ERT,
demonstrate that you apparently have a large gap in your C knowledge
spanning roughly the years 1988-1998.  (While "ancient" K&R C didn't
have 'const', it has been standard C since 1989, and C99 didn't
change much in this respect.)


> > > each struct
> > > and enum have to be prefixed with "struct" and "enum".
> >
> > Poor baby.

Translated from Brit-sarcasm again, for the hard-of-humour:

Poor baby.  Whine about it, why don't you?  Most people
here are probably inclined to say that specifying 'struct'
and 'enum' is a *good* thing, since it makes it more obvious
what you're doing.  In related news, Brussels sprouts are
good for you.

[Okay, that wasn't so much "translated" as "expounded."]


> void foo(struct MyStruct struct){}
>
> in C you cannot omit the keyword "struct". when it compiles without "struct"
> you probably using a C++ compiler.

False.  The above is neither C *nor* C++; it's a syntax error in
both languages.  (And you should read up on 'typedef'; it's the C
Gods' answer to the keyword-impaired.)

> > Yes, there is. C is simple,
>
> agreed.
>
> > portable,
>
> agreed.
>
> > and very very fast. Those are  important qualities.
>
> not faster than C++. why should it?

"Suck it and see," remember?  I could run some size and speed
benchmarks on my C and C++ compilers, and let you know the
quantitative differences, but why should I bother?  You're the
one who wants to know!  You do it!

(Oh, and re your response to Jack Klein: While IMHO Jack was a
bit harsh, and a bit defensive, his criticism of your style was
dead on.  You really *don't* seem to know very much about C,
and haven't demonstrated a terrible amount of knowledge of C++
either (not that that would be on-topic here), yet you want us
to prove to you somehow that C is "still relevant," or something.
Why not read a book or two and do your own research?  Ask a C
newsgroup, get a C answer.)

-Arthur
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
ajo (1603)
10/12/2003 10:48:13 PM
In article <clcm-20031008-0005@plethora.net>,
cody <dont.spam.me.deutronium@gmx.de> wrote:
[Somebody else, whose name cody snipped, wrote:]
>> There is both a speed and size penalty for using C++ where
>> pain C would do.  The penalty isn't as bad as it used to be.

There tends to be a speed and size penalty for using C++ features
that C doesn't support.  There would also be a speed and size penalty
(probably larger, but not noticeably so, especially not compared to the
programmer time cost) for writing C code to match the C++ features that
C doesn't have.
Note that this is a rather weaker statement than the one quoted above.

>there should be no difference between the calls of
>
>class A{ public: static void a(){ } }
>
>and
>
>void a(){}

In fact, there should be no difference between the calls of

class A{ public: void a(){} };

and

void a(struct A *){}

(Or, if you really hate typing "struct" that much:

typedef struct A A;
void a(A *){}

).  Of course, making the "this" pointer explicit probably has a
programmer time cost for keeping track of various things - if you want
to write C++ code, you're better off writing it in C++ than in C.


>> C has constants.  We usually use typedefs rather than struct
>> and enum tags.
>
>is "const float PI=3.14" possible in plain C?

Yes.  (Even C90.)  It has different semantics than in C++ (and at least
one highly respected comp.lang.c poster[1] considers C's const semantics
broken, and can give good reasons), but if you don't try to confuse
the compiler (or manage to confuse it without trying), something like
"const float Pi=3.14159" will do exactly what you expect.


dave

[1] I'm thinking of Chris Torek, though there are probably others.  See
    http://groups.google.com/groups?q=const+broken+author:chris+author:torek+group:comp.lang.c
    for enlightenment on this subject (or drop the "const+broken+",
    and perhaps the "+group:comp.lang.c", for more general enlightenment).

-- 
Dave Vandervies                                dj3vande@csclub.uwaterloo.ca
Programmers have a problem. It's a secret we try to keep among ourselves.
We really like this stuff. We do it even when they don't pay us. Don't tell
anybody.                                        --Joe Wright in comp.lang.c
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
dj3vande (669)
10/12/2003 10:48:18 PM
cody <dont.spam.me.deutronium@gmx.de> scribbled the following
on comp.lang.c:
>> > pieces of the application where speed really matters you can still use
>> > "normal" functions or even static methods which is basically the same.
>>
>> Suck it and see.

> ?

It means "try it and see".

>> int main(void)
>> {
>>   const int new = 6; /* I rest my case */
>>   return 0;
>> }

> i though in standard C, there isn't such a thing like "const" you can only
> use macros to fake them.

Well you thought wrong. Have you read a textbook about C?

>> > each struct
>> > and enum have to be prefixed with "struct" and "enum".
>>
>> Poor baby.

> void foo(struct MyStruct struct){}

> in C you cannot omit the keyword "struct". when it compiles without "struct"
> you probably using a C++ compiler.

You probably didn't understand the reply. What's so horrible about
having to type "struct" or "enum"? Are you having difficulties typing
such long words?

>> and [C is] very very fast. Those are  important qualities.

> not faster than C++. why should it?

Um, languages aren't fast or slow. Implementations of them are.

-- 
/-- Joona Palaste (palaste@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste       W++ B OP+                     |
\----------------------------------------- Finland rules! ------------/
"Remember: There are only three kinds of people - those who can count and those
who can't."
   - Vampyra
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
palaste (2323)
10/12/2003 10:48:32 PM
cody wrote:
>>>i don't get it why people program in C and faking OOP features(function
>>>pointers in structs..) instead of using C++.
>>
>>This is laughable.  It is C++ that is best known for faking OO features!
>>If you're looking for an OO extension to C that is actually well done,
>>one that is additionally a proper superset of C, you should be looking
>>at Objective-C.  But that's still in the C family.  If you don't want C,
>>don't use C; don't use C++ and pretend you're not using C, though.
> 
> 
> 
> so why is objective C used my nobody? except you maybe :)

Mostly because nobody uses it.  Many have never even heard of it, fewer 
yet have seen it, and fewer than that have ever written code in it. 
C/C++ are the industry norms and Objective-C just hasn't had its day in 
the sun yet.

Actually there are several issues with Objective-C:

* No standard.
   There is absolutely no standard that compilers must adhere to, and 
there are several variations of language abilities.  For instance, one 
language feature on some compilers called a "Category" allows you to 
attach methods to a class that already exist, this can be done through a 
loadable library.  Many compilers don't implement Categories and among 
those that do there is dispute as to how they work.

* Poor adoption - unless you use MacOS X.
   There is only one OS where Objective-C is use frequently.  Everywhere 
else it is an anomoly.

* Lack of good libraries to use except on a few systems.
   If you use MacOS then of course ObjC is perfect for your use.  In 
other environments on the other hand you have either wrappers to C 
libraries or attempts at making Unix look and act like Next or MacOS 
(which is of course unix trying to look like NeXT).  The NeXT API is 
beutiful, a work of art, but implementations should alter it when it 
runs afoul of system norms; no implementation currently does.

Objective-C is a very elegant language and as far as OO languages go it 
is the best I have ever used, but I can only compare to C++ and Java. 
The learning curve is very small compared to C++ especially if you 
already know C; this is a side effect of the language's simplicity.

I used to have a whole list of links for the language at an old site.  I 
devoted much time to advocating its use.  But I rarely use it anymore, 
all the more the pity.  If there was a nice API, like the NeXT set of 
classes, that behaved like a normal Unix library (in that I can write 
applications that expect to be on a unix filesystem instead of their own 
".app" directory) I would probably do much of my work in that language. 
  It is *much* easier to use than the alternatives.

NR
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
nroberts (863)
10/12/2003 10:48:43 PM
cody wrote:
>void foo(struct MyStruct struct){}
>
>in C you cannot omit the keyword "struct". when it compiles without "struct"
>you probably using a C++ compiler.


typedef struct
{
  int a;
  int b;
} foo;

void bar(foo data)
{
}
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
andy2366 (2)
10/12/2003 10:48:45 PM
cody wrote:
> 
> > C supports the const keyword now.
> 
> since when? C99?

I've been using it in C90 code for at least a decade now. I don't have a
copy of the C90 standard, so I can't be sure, but I suspect it was
introduced in C90.

> > > each struct and enum must be prefixed with "struct" and "enum".
> >
> > typedef struct X {
> >   // public data members
> >   } X;
> >
> > in C is the same as
> >
> > struct X {
> >   // public data members
> >   };
> >
> > in C++.
> 
> and in function declarations? is void foo(X x){} allowed?

Yes, of course. it's a typedef, like any other.

In another message, you asked:

> > Obviously your knowledge of C is minimal.
> 
> what makes you believe that?

Well, being unaware of 'const' and 'typedef struct' doesn't exactly make
you seem like an expert.
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
kuyper (156)
10/12/2003 10:48:59 PM
"cody" <dont.spam.me.deutronium@gmx.de> wrote in message news:<clcm-20031008-0005@plethora.net>...
....
> is "const float PI=3.14" possible in plain C?

Of course. Its a very bad idea, since in most cases you need a lot
more digits, but it is possible.
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
kuyper5 (433)
10/12/2003 10:49:01 PM
"cody" <dont.spam.me.deutronium@gmx.de> wrote in message news:<clcm-20031008-0003@plethora.net>...
...
> > int main(void)
> > {
> >   const int new = 6; /* I rest my case */
> >   return 0;
> > }
> 
> i though in standard C, there isn't such a thing like "const" you can only
> use macros to fake them.

In C++, a const-qualified integer variable can be used in places where
an integer constant expression is required; that's not true in C.
However, both languages allow const-qualification.

> > > each struct
> > > and enum have to be prefixed with "struct" and "enum".
> >
> > Poor baby.
> 
> void foo(struct MyStruct struct){}

C isn't as clumsy as you think. The second 'struct' is not only not
necessary, but actually a syntax error.

> in C you cannot omit the keyword "struct". when it compiles without "struct"
> you probably using a C++ compiler.

Or typedefs.
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
kuyper5 (433)
10/12/2003 10:49:03 PM
cody wrote:
> 
> no this is no trollposting and please don't get it wrong but iam very
> curious why people still use C instead of other languages especially C++.
> 
> i heard people say C++ is slower than C but i can't believe that. in pieces
> of the application where speed really matters you can still use "normal"
> functions or even static methods which is basically the same.

I am an embedded systems programmer.  There are many small target
platforms that do not have a C++ compiler.  I am not a C++ programmer,
but understand that supporting the ability to handle exceptions forces
an overhead that isn't easily removed, even if exceptions aren't used.  

> in C there arent the simplest things present like constants, each struct and
> enum have to be prefixed with "struct" and "enum". iam sure there is much
> more.

C does have constants -- 5 is an example.  Of course, the macro
processor can be used to assign a symbolic name to a constant, as well. 
Having to type "struct" or "enum" is not a big burden and is usually
eliminated by the use of typedef.

> i don't get it why people program in C and faking OOP features(function
> pointers in structs..) instead of using C++. are they simply masochists or
> is there a logical reason?

C has wider portability.  The functionality resulting from C code, in
general, is more obvious because of the lack of overloaded functions,
operators, constructors, and destructors.  This more obvious
functionality makes debugging easier.

C++, of course, does have its advantages, especially for large
projects.  For smaller projects I think C yields a simpler, more
understandable solution.  For very small embedded projects, assembly
code is better.  At the point that I need more support for large complex
systems,  I will look closely at Java.

Thad
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
Thad
10/12/2003 10:49:08 PM
In article <clcm-20031008-0017@plethora.net>, thp@cs.ucr.edu writes
>In comp.std.c cody <NO.SPAM.deutronium@gmx.net> wrote:
>
>C is pretty much, but not quite, a sublanguage of C++.

C++ is based on C90  However C++ is no longer a super set of C. They are
different languages.

>  C programmers
>who don't use the non-C++ features of C are programming in C++ whether
>they claim to or not.  They are restricting themselves to an older,
>more established, more easily learned, and more easily implemented
>subset of C++.  But they are writing in C++ --- non-idiomatic C++, but
>C++ nevertheless. 

This is not true. The are using C.  C++ Inherits from C NOT the other
way round.

Chris
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
chris32 (3361)
10/12/2003 10:49:25 PM
[Followups set to comp.lang.c]

cody wrote:

>> > pieces of the application where speed really matters you can still use
>> > "normal" functions or even static methods which is basically the same.
>>
>> Suck it and see.
> 
> ?

The only way to /know/ what the performance of your program will be like is 
to try it out. Even then, your results will not be generally applicable.

> 
>> int main(void)
>> {
>>   const int new = 6; /* I rest my case */
>>   return 0;
>> }
> 
> i though in standard C, there isn't such a thing like "const" you can only
> use macros to fake them.

That is an indication that you should spend less time insulting experts and 
more time reading what they write, if you wish to be taken seriously in the 
C programming community.

> void foo(struct MyStruct struct){}
> 
> in C you cannot omit the keyword "struct". when it compiles without
> "struct" you probably using a C++ compiler.

Your example code will not compile in either language.

Here is an extract from a C header file of my own devising. As you can see, 
it uses a type named TCP. As you can't see, the word "struct" is completely 
missing, despite the fact that TCP /is/ indeed a name I have chosen for a 
struct type.

/*! Transmission Control Protocol connection abstractions */
/*! Connect to a TCP server */
TCP *TCPConnect(const char *server, unsigned short port, FILE *fplog);

/*! Set the logging level */
int TCPSetLogLevel(TCP *connection, unsigned long LogLevel);
/*! Disconnect from the server (invalidates the connection) */
int TCPDisconnect(TCP *connection);
/*! Send a TCP packet */
int TCPSend(TCP *connection, const void *p, size_t len);
/*! Receive a TCP packet */
int TCPReceive(TCP *connection, void *p, size_t len);

Can you say "typedef"?

-- 
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
dontmail (1886)
10/12/2003 10:49:27 PM
>>C supports the const keyword now.
cody wrote:
> since when? C99?

No, since the first C standard in 1989.

> and in function declarations? is void foo(X x){} allowed?
[where X is a typedef for a structure]

Of course it's allowed.

For somebody who feels free to criticize C,
you sure don't seem to know much about it.
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
DAGwyn (797)
10/12/2003 10:49:29 PM
thp@cs.ucr.edu wrote:
> Compiling C programs with a C++ compiler has the benefit that C++
> compilers are required to perform intermodule type checking.  But I'm
> told that this intermodule type checking is a curse when one tries to
> use precompiled libraries that have been compiled on different C++
> compilers, since that checking is usually based on name-mangling and
> there is no name-mangling standard.  (Perhaps others have more
> experience with that issue.)

On essentially any platform there is a unique standard API
for C linkage.  And it is easy to get that linkage from C++
by using "extern C".  Therefore, libraries written in C are
readily used from both C and C++ applications.  Libraries
that rely on C++-specific features (e.g. classes) are not
readily used from C applications.
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
DAGwyn (797)
10/12/2003 10:49:31 PM
> void foo(struct MyStruct struct){}
>
> in C you cannot omit the keyword "struct". when it compiles without
"struct"
> you probably using a C++ compiler.

unless:

typedef struct X {   int x; } X;

void foo(X x) {}

foo((X){1});
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
i1848 (53)
10/12/2003 10:49:32 PM
"cody" <dont.spam.me.deutronium@gmx.de> wrote in news:clcm-20031008-0005
@plethora.net:

> 
> is "const float PI=3.14" possible in plain C?
> 

You just confirmed Jack Klein's assesment of your knowledge of C.

-- 
A. Sinan Unur
asu1@c-o-r-n-e-l-l.edu
Remove dashes for address
Spam bait: mailto:uce@ftc.gov
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
asu1 (32)
10/12/2003 10:49:34 PM
C is much more alike the final machine code, and that is a benefit
that some programmers take advantage of. This is handy when coding
microprocessors, which are mostly done in C, since assembler quickly
gets out of hand. Also when core are to be translated in to HDL
language to be realized in hardware, most often C (and SystemC) is
used.

A wild guess is that every minute of the day, there is more micro
processor code running than PC code running. (?)

If this benefit is not used, I don't think that there are any big
advantages with C except that it might be easier to learn.

Best regards,
Andreas Lundgren
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
d99alu (33)
10/12/2003 10:49:39 PM
On 08 Oct 2003 05:35:19 GMT
"cody" <dont.spam.me.deutronium@gmx.de> wrote:

> i though in standard C, there isn't such a thing like "const" you can
> only use macros to fake them.
Maybe you should read the standard. 
The const keyword is certainly defined, but it has a different meaning
than in C++. 
const int foo = 4;
In C, foo is a variable and will be treated as such. 
	int *pf = (int *)&foo;
	*pf = x;
By using casts, you can defeat the const. 

In C++, foo would be treated as a true compile-time constant, and would
not actually be placed in memory. 
-- 
Jerry Feldman <gaf-nospam-at-blu.org>
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
gaf-noSPAM (33)
10/12/2003 10:49:40 PM
On 08 Oct 2003 05:35:25 GMT
"cody" <dont.spam.me.deutronium@gmx.de> wrote:

> > There is both a speed and size penalty for using C++ where
> > pain C would do.  The penalty isn't as bad as it used to be.
> 
> there should be no difference between the calls of
> 
> class A{ public: static void a(){ } }
> 
> and
> 
> void a(){}
> 
> > C has constants.  We usually use typedefs rather than struct
> > and enum tags.
> 
> is "const float PI=3.14" possible in plain C?
Define "plain C". This is possible in standard C, but not in K&R C.
-- 
Jerry Feldman <gaf-nospam-at-blu.org>
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
gaf-noSPAM (33)
10/12/2003 10:49:43 PM
In article <clcm-20031008-0003@plethora.net>, cody 
<dont.spam.me.deutronium@gmx.de> writes
>>
>> > each struct
>> > and enum have to be prefixed with "struct" and "enum".
>>
>> Poor baby.
>
>void foo(struct MyStruct struct){}
>
>in C you cannot omit the keyword "struct". when it compiles without "struct"
>you probably using a C++ compiler.

Of course you can, but in C you have to explicitly create a typename 
with typedef.

-- 
Francis Glassborow      ACCU
If you are not using up-to-date virus protection you should not be reading
this. Viruses do not just hurt the infected but the whole community.
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
francis (122)
10/12/2003 10:49:44 PM
In article <clcm-20031006-0016@plethora.net>, Darrell Grainger 
<darrell@NOMORESPAMcs.utoronto.ca.com> writes
>1) Not all environments have a good C++ compiler.

And for some targets writing a C++ compiler is simply not commercially 
viable. For example, exactly why would I want a C++ cross compiler for 
an 8051 type embedded processor? I already need an extended C compiler 
(to handle such things as bit variables) so I am not going to pay for a 
tool that has a lot of unnecessary (for my needs) fat.


-- 
Francis Glassborow      ACCU
If you are not using up-to-date virus protection you should not be reading
this. Viruses do not just hurt the infected but the whole community.
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
Francis
10/12/2003 10:49:53 PM
In article <clcm-20031008-0017@plethora.net>,  <thp@cs.ucr.edu> wrote:
>C is pretty much, but not quite, a sublanguage of C++.  C programmers
>who don't use the non-C++ features of C are programming in C++ whether
>they claim to or not.

I thought about this a bit, and I have concluded that I disagree.

>Compiling C programs with a C++ compiler has the benefit that C++
>compilers are required to perform intermodule type checking.  But I'm
>told that this intermodule type checking is a curse when one tries to
>use precompiled libraries that have been compiled on different C++
>compilers, since that checking is usually based on name-mangling and
>there is no name-mangling standard.  (Perhaps others have more
>experience with that issue.)

It also breaks certain very useful idioms of standard C, such as automatic
(void *) conversions.

Anyway, there is a great deal more to a language than "this compiler will
accept it".  Your argument works just as well for Objective C; so far as
I can tell, any valid C program is a valid Objective C program.  It works
even better for "C With Classes", even though that's a dead language, than
it does for C++.

In reality, to say you are "programming in C++" means not just that your
code happens to be syntactically C++, but that you have adopted the philosophy
and design of that language.  Often, people whose code passes through a C++
compiler are really writing FORTRAN IV; I've seen such code.

Stylistically, I use C instead of C++ because I am better able to express
what I mean in C, and in particular, because I have then some small hope of
being able to read the code later.  If you exclude all of the features of
C++ which have tended to produce awful and unreadable code, you might as
well just write in plain old C, and avoid the "enhancements" all together.
If I want an OO bag on the side of C, I prefer Objective C; it makes the
magic features explicit, rather than implicit.  If I want an OO language with
C-like syntax, I'll use Java.  So far, I've found no tasks for which C++
seemed to be a good fit, except for maintaining existing code that was written
in C++.

-s
-- 
   Copyright 2003, all wrongs reversed.  Peter Seebach / seebs@plethora.net
   http://www.seebs.net/log/ - YA blog.   http://www.seebs.net/ - homepage.
     C/Unix wizard, pro-commerce radical, spam fighter.  Boycott Spamazon!
Consulting, computers, web hosting, and shell access: http://www.plethora.net/
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
seebs (39)
10/12/2003 10:55:32 PM
> > void foo(struct MyStruct struct){}
>
> C isn't as clumsy as you think. The second 'struct' is not only not
> necessary, but actually a syntax error.


sorry my mistake. should read void foo(struct MyStruct myStruct){}

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk


0
10/13/2003 12:34:54 AM
"Jirka Klaue" <jklaue@ee.tu-berlin.de> wrote in message
news:bmbgi7$4e9$1@mamenchi.zrz.TU-Berlin.DE...
> Mike Wahler wrote:
> ...
> > Most people I know tell me I have
> > an extraordinary sense of humor.
>
> This proves nothing.

It was not an attempt to prove anything.

>BTW, it could stand for "none at all" as well.

Or anything else you like.  I treat it as what it was,
an exchange of opinions between Cody and myself about
"sense of humor."

-Mike


0
mkwahler (3821)
10/13/2003 6:22:42 PM
In comp.std.c Douglas A. Gwyn <DAGwyn@null.net> wrote:
+ thp@cs.ucr.edu wrote:
+> Compiling C programs with a C++ compiler has the benefit that C++
+> compilers are required to perform intermodule type checking.  But I'm
+> told that this intermodule type checking is a curse when one tries to
+> use precompiled libraries that have been compiled on different C++
+> compilers, since that checking is usually based on name-mangling and
+> there is no name-mangling standard.  (Perhaps others have more
+> experience with that issue.)
+ 
+ On essentially any platform there is a unique standard API
+ for C linkage.  And it is easy to get that linkage from C++
+ by using "extern C".  Therefore, libraries written in C are
+ readily used from both C and C++ applications.  Libraries
+ that rely on C++-specific features (e.g. classes) are not
+ readily used from C applications.

Is it feasible to interpose a proxy library whose headers are
conforming C code that's compiled with a C++ compiler and that calls
functions from the C++ library?

Tom Payne
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
thp (42)
10/13/2003 6:49:35 PM
In comp.std.c Chris Hills <chris@phaedsys.org> wrote:
+ In article <clcm-20031008-0017@plethora.net>, thp@cs.ucr.edu writes
+>In comp.std.c cody <NO.SPAM.deutronium@gmx.net> wrote:
+>
+>C is pretty much, but not quite, a sublanguage of C++.
+ 
+ C++ is based on C90  However C++ is no longer a super set of C. They are
+ different languages.
+ 
+>C programmers who don't use the non-C++ features of C are
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+> programming in C++ whether
+>they claim to or not.  They are restricting themselves to an older,
+>more established, more easily learned, and more easily implemented
+>subset of C++.  But they are writing in C++ --- non-idiomatic C++, but
+>C++ nevertheless. 
+ 
+ This is not true. 

We are speaking of "C programmers to don't use the non-C++ features of
C", i.e., they use only those features of C that are C++ compatible.

+ The are using C.  

That's why I  referred to them as "C programmers".

+ C++ Inherits from C NOT the other way round.

I'm told that C has actually imported a few C++ features, but that's
beside the point.

Tom Payne
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
thp (42)
10/13/2003 6:49:47 PM
> > > > pieces of the application where speed really matters you can still
use
> > > > "normal" functions or even static methods which is basically the
same.
> > >
> > > Suck it and see.
> >
> > ?
>
> A colloquialism roughly equivalent to "why don't you try it and find
> out, instead of whining to me about it?"

I said that some people said that C would be faster and I don't believe
that.
So why should i test it? I don't blieve it, as i said. But for the case that
people
where right, i asked that if somebody would know a case where C is faster
than C++, should tell me.

> > i though in standard C, there isn't such a thing like "const" you can
only
> > use macros to fake them.
>
> Well, you're wrong.  Your response here, and your response to ERT,
> demonstrate that you apparently have a large gap in your C knowledge
> spanning roughly the years 1988-1998.  (While "ancient" K&R C didn't
> have 'const', it has been standard C since 1989, and C99 didn't
> change much in this respect.)

Well, i'read books about C++ but this is long ago, and as we all know, books
are not
very up-to-date anyway and the knowlegde of some authors is alarming. how
many C++ books keep you telling to include <iostream.h> instead of
<iostream> or void main() instead of int main()?

> > void foo(struct MyStruct struct){}
> >
> > in C you cannot omit the keyword "struct". when it compiles without
"struct"
> > you probably using a C++ compiler.
>
> False.  The above is neither C *nor* C++; it's a syntax error in
> both languages.

sorry, my mistake. it should read

void foo(struct MyStruct myStruct){}

or something similar :)

> (And you should read up on 'typedef'; it's the C
> Gods' answer to the keyword-impaired.)

you mean a typedef let you omit the keyword? thanks, i didn't know that.

> > not faster than C++. why should it?
>
> "Suck it and see," remember?  I could run some size and speed
> benchmarks on my C and C++ compilers, and let you know the
> quantitative differences, but why should I bother?  You're the
> one who wants to know!  You do it!

as i said, why should it? i asked just in case somebody could tell me a case
where
this assumption could be true, but i think it is an illogigal assumption.

> (Oh, and re your response to Jack Klein: While IMHO Jack was a
> bit harsh, and a bit defensive, his criticism of your style was
> dead on.

sorry i don't know the term "dead on". what does it mean?

> You really *don't* seem to know very much about C,

you're right. before i asked my question here, i wasn't aware that there are
so many
differences between C and C++. i always though of C as simply a subset of
C++
which is, as i learned here, not true.

> and haven't demonstrated a terrible amount of knowledge of C++

i don't consider myself as a expert in C++ but i think i have reasonable
knowlegde of
it. the last year i programmed only Java and C# so my C++ knowledge might be
a bit
rusty.

> either (not that that would be on-topic here), yet you want us
> to prove to you somehow that C is "still relevant," or something.

this already was proven to me by other posters.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
10/13/2003 6:50:00 PM
In comp.std.c Seebs <seebs@plethora.net> wrote:
[...]
+ In reality, to say you are "programming in C++" means not just that your
+ code happens to be syntactically C++, but that you have adopted the philosophy
+ and design of that language.  Often, people whose code passes through a C++
+ compiler are really writing FORTRAN IV; I've seen such code.

Hence, the distinction between idiomatic and non-idiomatic C++.

Tom Payne
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
thp (42)
10/13/2003 6:50:05 PM
"Andy Sinclair" <andy@r2g2.nospamplease.co.uk> schrieb im Newsbeitrag
news:clcm-20031012-0005@plethora.net...
> cody wrote:
> >void foo(struct MyStruct struct){}
> >
> >in C you cannot omit the keyword "struct". when it compiles without
"struct"
> >you probably using a C++ compiler.
>
>
> typedef struct
> {
>   int a;
>   int b;
> } foo;
>
> void bar(foo data)
> {
> }


Thank you! I always said it, a snippet of code can tell more than hundreds
words!

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
10/13/2003 6:50:07 PM
In article <clcm-20031012-0014@plethora.net>, Douglas A. Gwyn
<DAGwyn@null.net> writes
>>>C supports the const keyword now.
>cody wrote:
>> since when? C99?
>
>No, since the first C standard in 1989.

That was just a local standard :-)


/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
chris32 (3361)
10/13/2003 6:50:18 PM
In article <clcm-20031012-0018@plethora.net>, Andreas
<d99alu@efd.lth.se> writes
>C is much more alike the final machine code, and that is a benefit
>that some programmers take advantage of. This is handy when coding
>microprocessors, which are mostly done in C, since assembler quickly
>gets out of hand. Also when core are to be translated in to HDL
>language to be realized in hardware, most often C (and SystemC) is
>used.
>
>A wild guess is that every minute of the day, there is more micro
>processor code running than PC code running. (?)

According to figures I have seen from several silicon vendors (they vary
slightly but they average out at about 1 in 3 processors on (and above)
the planet is an 8051....

PC x86 processors make up less than 10% of the total the other 88% are
embedded systems... (the 2% are MACs and mainframes.)

I am sure the figures have changed in detail but it gives a fair
picture.




/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
chris32 (3361)
10/13/2003 6:50:21 PM
"cody" <dont.spam.me.deutronium@gmx.de> wrote in message
news:bmbml2$kn7pe$1@ID-176797.news.uni-berlin.de...
> > > > > i disagree on that.
> > > > >how can you make sure that all data is properly
> > > > > encapsulated if
> > > > > the language provides no support?
> >
> > It does provide it.  What do you mean by "properly"?
> >
> > struct data
> > {
> >     int details;
> > };
> >
> > The value 'details' is properly encapsulated inside
> > the  struct type 'data'. This encapsulation could
> > indeed be corrupted via making coding errors, but
> > this does *not* mean the encapsulation is 'improper'.
>
> This is no encapsulation. encapsulation means that nobody (except the
class
> itself)
> can access the variable directly,
> or the direct acess is limited to certain
> classes for example derived classes or friend classes.

Go ahead and believe that if you like.  I'm done trying
to correct your misconceptions.

You also still seem to be insisting that OO concepts must
be expressed with C++ constructs, which is certainly
untrue.  However my example is still valid in that language
anyway.  It's not the way I'd actually do it with C++, but
that doesn't mean it's not encapsulation.

> You are talking about things you don't understand.

If it pleases you to believe that, I don't mind.
However your opinion of my level of knowlege matters
to me not at all, given the statements you've made
in this forum.

> But the same is true for
> me when i talk about plain C :)

So you admit that when talking about C, you are talking
about something you don't understand.  So why do you
make the claims about it that you have?

> > The existence of the possibility of coding errors does
> > not preclude a program from being expressed with OOP.
> > A language's enforcements of OOP concepts is a very
> > useful tool, but need not be present for a program
> > to be expressed using OOP.
>
> This is the point of encapsulation. it simply cannot happen that you
access
> a variable that you have no access to,

Feel free to believe that if you like.  A couple of suggestions:

1. Research the terms 'data hiding' and 'interface'.

2. Call upon your knowledge of English in considering
   why certain OO concepts have the names they do.

> due to coding mistakes (Except you unintentional manipulate the variable
> using a memory address if you know its offset in the struct/class)

> > No.  'for_each()' is simply a function which iterates
> > through a sequence, and applies a function to each
> > member of that sequence.  It's a generalization of
> > a simple 'for loop', designed to be useful with
> > the standard library 'container' abstraction.
> > Nothing at all to do with 'functional programming'.
>
> Functional programming means you don't say how you want it done like in
> [C/C++/Pascal or similar] but you just say what you want have done.
>
> for (int i=0; i<10; i++) a[i]+=2;  /* you excatly say how to do it  */
>
> for_each (myContainer, MultiplicateWith(2))  /* you just say what is to do
> you don't care about how it should be done */

1. That does *not* express an invocation of the C++
   library function 'for_each()'

2. A correct invocation of 'for_each' expresses exactly
   the same concept as your 'for' example above, only
   using different words.

3. 'for_each' behavior is not an example of functional programming.

> That's the way functional languages like haskell or lisp or whatever
solves
> problems.

I don't think so.


I'm going to stop trying to correct your misconceptions now.
If you'd like personal tutoring in C and/or C++, I'll need
some compensation.

-Mike


0
mkwahler (3821)
10/13/2003 6:58:59 PM
thp@cs.ucr.edu wrote:
[...]
> C is pretty much, but not quite, a sublanguage of C++.  C programmers
> who don't use the non-C++ features of C are programming in C++ whether
> they claim to or not.  They are restricting themselves to an older,
> more established, more easily learned, and more easily implemented
> subset of C++.  But they are writing in C++ --- non-idiomatic C++, but
> C++ nevertheless.  AFAIK, a C++ compile is free to generate the same
> code for those programs as would a C compiler, so there is no
> intrinsic difference in performance.

In C without exceptions (stuff like MS or DEC/HP SEH extensions), all 
functions are kinda "throw()". In the current C++ (without mandatory 
2-phase EH and with brain-damaged exception specifications instead), 
throw() is kinda expensive. So, there is some "intrinsic difference 
in performance", I'm afraid.

http://lists.boost.org/MailArchives/boost/msg53807.php
http://lists.boost.org/MailArchives/boost/msg53808.php
http://lists.boost.org/MailArchives/boost/msg53826.php

regards,
alexander.

P.S. WRT to the last link: "Stack overflow is no problem on *entry* 
to a throw() region..." is about explicit throw()-regions apart from 
scope cleanup -- I mean {throw()-nothing} dtors... they shall have 
implicit throw() ES by default, of course. We just can't retry thier
destruction because objects are gone. Optional stack checking (for 
objects that live in throw-something routines) can be done prior to 
construction (and, of course, the entire "landing pad" shall to be 
protected by MS SEH like "__try/__except(goto_unexpected()) {}" or
"something like that").

<quote>

LANDING PADS

The runtime transfers control to a landing pad whenever an exception 
is thrown from a given call site. The landing pad contains code in 
the following order:

- compensation code, restoring program state to what it would be if 
  optimizations had not been done in the main control flow;

- destructor invocation to destroy any local object that needs to be 
  destroyed;

- exception switches to select which catch handler, if any, to jump 
  to (an appropriate switch value is computed by the runtime from 
  the C++ exceptions table and placed in a temporary register); and

- a landing pad exit, which either returns to a catch block and 
  moves from there to the main control flow or resumes unwinding if 
  no appropriate exception handler is found in  this subroutine.

 <snip>

- If the variable is allocated to a different register in different 
  sections of code, the landing pad can simply copy that register to 
  the target register that represents the variable in the exception 
  handler.

- A value known to be constant that is replaced with the constant 
  value can be loaded into the appropriate register by the landing 
  pad, for use by the user code in the exception handler.

- Pending memory operations that have been delayed in the main 
  control flow can simply be executed in the landing pad should an 
  exception be thrown. Compensation code therefore lets the compiler 
  use any of the optimizations that were prevented by simpler table-
  driven techniques. 

</quote>

regards,
alexander.
0
terekhov (1920)
10/13/2003 8:18:56 PM
"Mike Wahler" <mkwahler@mkwahler.net> schrieb im Newsbeitrag
news:TBCib.9526$dn6.8405@newsread4.news.pas.earthlink.net...
> > > struct data
> > > {
> > >     int details;
> > > };
> > >
> > > The value 'details' is properly encapsulated inside
> > > the  struct type 'data'. This encapsulation could
> > > indeed be corrupted via making coding errors, but
> > > this does *not* mean the encapsulation is 'improper'.
> >
> > This is no encapsulation. encapsulation means that nobody (except the
> class
> > itself)
> > can access the variable directly,
> > or the direct acess is limited to certain
> > classes for example derived classes or friend classes.
>
> Go ahead and believe that if you like.  I'm done trying
> to correct your misconceptions.

OK, OK i already learned that in C proper encapsulation is possible.
But i could not know what you mean if you just say:

"struct data{  int details; };
The value 'details' is properly encapsulated inside the struct type 'data' "

That is no encapsulation. Combined with the concept of opaque types, it is.
I already learned that.

> You also still seem to be insisting that OO concepts must
> be expressed with C++ constructs, which is certainly
> untrue.  However my example is still valid in that language
> anyway.  It's not the way I'd actually do it with C++, but
> that doesn't mean it's not encapsulation.

You are right. I used to see the concept of OOP only in OOP-languages, which
made
me blind for other approaches implementing OOP.

> So you admit that when talking about C, you are talking
> about something you don't understand.  So why do you
> make the claims about it that you have?

I hope to learn.

> > > The existence of the possibility of coding errors does
> > > not preclude a program from being expressed with OOP.
> > > A language's enforcements of OOP concepts is a very
> > > useful tool, but need not be present for a program
> > > to be expressed using OOP.

Agreed.

> 1. Research the terms 'data hiding' and 'interface'.

I know how to hide data with C. but I wonder how a C programmer would
implement
an Interface.

> > for_each (myContainer, MultiplicateWith(2))  /* you just say what is to
do
> > you don't care about how it should be done */
>
> 1. That does *not* express an invocation of the C++
>    library function 'for_each()'

for_each(myContainer.begin(), myContainer.end(), MultiplicateWith<2>());

better? (consider MultiplicateWith as a functor with <int> as template
parameter)

> 2. A correct invocation of 'for_each' expresses exactly
>    the same concept as your 'for' example above, only
>    using different words.

for_each is using iterators, that means the container knows how it can be
traversed.
you only say: iterate through this thing!

> 3. 'for_each' behavior is not an example of functional programming.

Is it. I googled a bit and found some good results:
Multi Paradigm programming in C++:
http://www.fz-juelich.de/zam/FACT/glossary/glossary.html
http://www.oreillynet.com/pub/a/network/2003/05/06/cplusplusian.html?page=la
st


--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk


0
10/13/2003 8:36:12 PM
Alexander Terekhov wrote:

> So, there is some "intrinsic difference in performance", I'm afraid.

No.

There is no difference in performance
unless an exception is actually thrown.
But C++ programs that handle exceptions
can be much "fatter" than C (or C++) programs
that don't handle exception.
This doesn't usually make much difference
on modern microprocessors with large code memories.

0
10/13/2003 8:39:43 PM
"E. Robert Tisdale" wrote:
> 
> Alexander Terekhov wrote:
> 
> > So, there is some "intrinsic difference in performance", I'm afraid.
> 
> No.
> 
> There is no difference in performance
> unless an exception is actually thrown.

To begin with, read this:

http://www.computer.org/concurrency/pd2000/p4072abs.htm
("C++ Exception Handling", Christophe de Dinechin,
 IEEE Concurrency October-December 2000 (Vol. 8, No. 4))

regards,
alexander.
0
terekhov (1920)
10/13/2003 10:37:42 PM
Alexander Terekhov wrote:

> E. Robert Tisdale wrote:
> 
>>Alexander Terekhov wrote:
>>
>>>So, there is some "intrinsic difference in performance", I'm afraid.
>>
>>No.
>>
>>There is no difference in performance
>>unless an exception is actually thrown.
> 
> To begin with, read this:
> 
> http://www.computer.org/concurrency/pd2000/p4072abs.htm
> ("C++ Exception Handling", Christophe de Dinechin,
>  IEEE Concurrency October-December 2000 (Vol. 8, No. 4))

According to Bjarne Stoustrup, "The C++ Programming Language:
Third Edition", Chapter 14 Exception Handling,
Section 8 Exceptions and Efficiency, page 381:

"In principle, exception handling can be implemented so that
  there is no run-time overhead when no exception is thrown."

This principle has been realized in practice.

0
10/13/2003 10:59:47 PM
In comp.std.c Alexander Terekhov <terekhov@web.de> wrote:
+ 
+ thp@cs.ucr.edu wrote:
+ [...]
+> C is pretty much, but not quite, a sublanguage of C++.  C programmers
+> who don't use the non-C++ features of C are programming in C++ whether
+> they claim to or not.  They are restricting themselves to an older,
+> more established, more easily learned, and more easily implemented
+> subset of C++.  But they are writing in C++ --- non-idiomatic C++, but
+> C++ nevertheless.  AFAIK, a C++ compile is free to generate the same
+> code for those programs as would a C compiler, so there is no
+> intrinsic difference in performance.
+ 
+ In C without exceptions (stuff like MS or DEC/HP SEH extensions), all 
+ functions are kinda "throw()". In the current C++ (without mandatory 
+ 2-phase EH and with brain-damaged exception specifications instead), 
+ throw() is kinda expensive. So, there is some "intrinsic difference 
+ in performance", I'm afraid.

Huh?  We're talking about code that is conforming under both C
(perhaps I should specify C89/90) and C++.  Are you saying that there
are some such programs for which a C++ compiler must generate code
that is somehow different from what a C compiler would/could generate?

Tom Payne
0
thp (42)
10/14/2003 3:04:16 AM
E. Robert Tisdale wrote:

> But C++ programs that handle exceptions
> can be much "fatter" than C (or C++) programs
> that don't handle exception.

"Fatter" is some sort of technical term here?
Anything to do with "bloat"?

-- 
Allin Cottrell
Department of Economics
Wake Forest University, NC

0
cottrell (169)
10/14/2003 3:31:45 AM
"E. Robert Tisdale" <E.Robert.Tisdale@jpl.nasa.gov> writes:

>Alexander Terekhov wrote:
>
>> E. Robert Tisdale wrote:
>> 
>>>Alexander Terekhov wrote:
>>>
>>>>So, there is some "intrinsic difference in performance", I'm afraid.
>>>
>>>No.
>>>
>>>There is no difference in performance
>>>unless an exception is actually thrown.

There is certainly a difference in performance between languages which
support exception handling (or equivalent feature) and those that don't.
The difference is generally small, but it does exist.  Compilers have
less freedom to reorder code that might throw exceptions.

Consider, for example, the following function:

	int foo() {
		static int x = 0;
		bar();
		x = x + 1;
		return x;
	}

Since the address of "x" is not taken, the compiler can be sure that
it won't be used in bar().  If it is sure that bar() won't throw an
exception, then it can evaluate "x + 1" and store the result back into
"x" _in parallel_ with evaluating the function call.

However, in C, any function might call longjmp(). 
This feature is quite similar in power to exception handling --
it can for instance easily be used to implement exception handling
(see e.g. my C exception handling library CXCPT
<http://www.cs.mu.oz.au/~fjh/CXCPT/index.html>).
So I'm not sure if there is any intrinsic difference between
C and C++ in this regard.

>> http://www.computer.org/concurrency/pd2000/p4072abs.htm
>> ("C++ Exception Handling", Christophe de Dinechin,
>>  IEEE Concurrency October-December 2000 (Vol. 8, No. 4))
>
>According to Bjarne Stoustrup, "The C++ Programming Language:
>Third Edition", Chapter 14 Exception Handling,
>Section 8 Exceptions and Efficiency, page 381:
>
>"In principle, exception handling can be implemented so that
>  there is no run-time overhead when no exception is thrown."

That's true to a first approximation, but I'm not yet convinced
that it is true to a second approximation.

>This principle has been realized in practice.

Are you sure?  Which implementation realizes it?

The following is from a KAI C++ exception exception handling tutorial
<http://www.hlrs.de/organization/tsc/services/tools/docu/kcc/tutorials/exceptions.html>:

 | General point: Some implementations of C++ claim to have "zero overhead"
 | exceptions. This is impossible as exceptions inherently add new paths of
 | control flow to a program. What they really mean by "zero overhead" is
 | "prepaid overhead". (I like the vendor who advertises "zero overhead",
 | but has a switch to turn off exceptions to enable a "faster smaller
 | executable".)
 | 
 | The way to find out what the overhead is for exception handling is
 | to benchmark your own application with it turned on and off. In our
 | experience, the overhead is usually in the 1-10% range.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
0
fjh (268)
10/14/2003 4:54:59 AM
In article <bmfp3g$512$1@glue.ucr.edu>, thp@cs.ucr.edu wrote:

> In comp.std.c Alexander Terekhov <terekhov@web.de> wrote:
> + 
> + thp@cs.ucr.edu wrote:
> + [...]
> +> C is pretty much, but not quite, a sublanguage of C++.  C programmers
> +> who don't use the non-C++ features of C are programming in C++ whether
> +> they claim to or not.  They are restricting themselves to an older,
> +> more established, more easily learned, and more easily implemented
> +> subset of C++.  But they are writing in C++ --- non-idiomatic C++, but
> +> C++ nevertheless.  AFAIK, a C++ compile is free to generate the same
> +> code for those programs as would a C compiler, so there is no
> +> intrinsic difference in performance.
> + 
> + In C without exceptions (stuff like MS or DEC/HP SEH extensions), all 
> + functions are kinda "throw()". In the current C++ (without mandatory 
> + 2-phase EH and with brain-damaged exception specifications instead), 
> + throw() is kinda expensive. So, there is some "intrinsic difference 
> + in performance", I'm afraid.
> 
> Huh?  We're talking about code that is conforming under both C
> (perhaps I should specify C89/90) and C++.  Are you saying that there
> are some such programs for which a C++ compiler must generate code
> that is somehow different from what a C compiler would/could generate?

size_t s = sizeof ('a'); 

will set s to sizeof (char) = 1 on all C++ compilers, and set s to 
sizeof (int) on C compilers, which is in practice greater than 1.
0
10/14/2003 6:42:24 AM
"E. Robert Tisdale" <E.Robert.Tisdale@jpl.nasa.gov> wrote:

> Alexander Terekhov wrote:
> 
> > So, there is some "intrinsic difference in performance", I'm afraid.
> 
> No.
> 
> There is no difference in performance
> unless an exception is actually thrown.
> But C++ programs that handle exceptions
> can be much "fatter" than C (or C++) programs
> that don't handle exception.
> This doesn't usually make much difference
> on modern microprocessors with large code memories.

You are Bill Gates, and I claim my five pounds.

Richard
0
rlb (4118)
10/14/2003 8:09:15 AM
Fergus Henderson wrote:
[...]
> However, in C, any function might call longjmp().

Oh yeah. Apart from straight deprecation, that thing just ought to 
throw "std::jump_exception" (caught by a handler kinda "injected" by 
setjmp()) or something like that.

> This feature is quite similar in power to exception handling --
> it can for instance easily be used to implement exception handling
> (see e.g. my C exception handling library CXCPT
> <http://www.cs.mu.oz.au/~fjh/CXCPT/index.html>).
> So I'm not sure if there is any intrinsic difference between
> C and C++ in this regard.

"All accessible objects have values, and all other components of the 
 abstract machine 209) have state, as of the time the longjmp function 
 was called, except that the values of objects of automatic storage 
 duration that are local to the function containing the invocation of 
 the corresponding setjmp macro that do not have volatile-qualified 
 type and have been changed between the setjmp invocation and longjmp 
 call are indeterminate."

http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V51_HTML/ARH9RBTE/DOCU0011.HTM#excep_rules_volatile

"1. Values of updated_volatile and updated_before_try are reliable. 
    Values of updated and updated_static are unreliable. 

 2. Regardless of the path to this code, the values of 
    updated_volatile and updated_before_try are reliable. If this 
    code is reached after the ENDTRY macro is invoked and no 
    exception has been raised, the values of updated and 
    updated_static are reliable. If this code is reached after the 
    exception fully_handled_exception has been caught, 
    the values of updated and updated_static are unreliable. 

 The code in Example 5-15 demonstrates: 

 - For variables referenced within exception handler code blocks, 
   it is necessary to distinguish between those whose value is set 
   before versus after the TRY macro is invoked in order to declare 
   those variables properly. 

 - The requirement to use the volatile type qualifier pertains to 
   a variable regardless of its C storage class -- that is, for both 
   automatic and static variables). "

;-)

Now, don't you think that "landing pads" is kinda better approach?

> 
> >> http://www.computer.org/concurrency/pd2000/p4072abs.htm
> >> ("C++ Exception Handling", Christophe de Dinechin,
> >>  IEEE Concurrency October-December 2000 (Vol. 8, No. 4))
> >
> >According to Bjarne Stoustrup, "The C++ Programming Language:
> >Third Edition", Chapter 14 Exception Handling,
> >Section 8 Exceptions and Efficiency, page 381:
> >
> >"In principle, exception handling can be implemented so that
> >  there is no run-time overhead when no exception is thrown."
> 
> That's true to a first approximation, but I'm not yet convinced
> that it is true to a second approximation.
> 
> >This principle has been realized in practice.
> 
> Are you sure?  Which implementation realizes it?
> 
> The following is from a KAI C++ exception exception handling tutorial
> <http://www.hlrs.de/organization/tsc/services/tools/docu/kcc/tutorials/exceptions.html>:
> 
>  | General point: Some implementations of C++ claim to have "zero overhead"
>  | exceptions. This is impossible as exceptions inherently add new paths of
>  | control flow to a program. What they really mean by "zero overhead" is
>  | "prepaid overhead". (I like the vendor who advertises "zero overhead",
>  | but has a switch to turn off exceptions to enable a "faster smaller
>  | executable".)
>  |
>  | The way to find out what the overhead is for exception handling is
>  | to benchmark your own application with it turned on and off. In our
>  | experience, the overhead is usually in the 1-10% range.

I believe that "the right thing" is that if you have declared ALL your
functions throw()-nothing (and don't use any try-catch/throw... I 
mean things like setjmp/longjmp ;-) ) than the only "overhead" shall be 
one single "phase one" handler:

  __try {
    // ... ctors for non-local objects of static duration in C++
    exit(main());
    // ... dtors for local objects of static duration in C++
  }
  __except(goto_unexpected()) {}

(threads and "better main" aside for a moment)

This does require two-phase EH and a bit different semantics for ES -- 
violations shall NOT unwind, they shall simply trigger std::unexpected()
processing at throw points.

regards,
alexander.
0
terekhov (1920)
10/14/2003 8:44:13 AM
On Tue, 14 Oct 2003 03:04:16 +0000 (UTC), in comp.lang.c ,
thp@cs.ucr.edu wrote:

>In comp.std.c Alexander Terekhov <terekhov@web.de> wrote:

Stuff which seemed to mostly be about C vs C++, and offtopic in both
CLC and CSC.  This thread is dead I think ?

Also Tom can you use "normal" quotation style, your + signs doesn't
work with my newsreader. 
-- 
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
0
markmcintyre (4555)
10/14/2003 9:02:38 AM
Mark McIntyre wrote:
> 
> On Tue, 14 Oct 2003 03:04:16 +0000 (UTC), in comp.lang.c ,
> thp@cs.ucr.edu wrote:
> 
> >In comp.std.c Alexander Terekhov <terekhov@web.de> wrote:
> 
> Stuff which seemed to mostly be about C vs C++, and offtopic in both
> CLC and CSC.  This thread is dead I think ?

Next silly question?

regards,
alexander.
0
terekhov (1920)
10/14/2003 9:08:42 AM
> Is it feasible to interpose a proxy library whose headers are
> conforming C code that's compiled with a C++ compiler and that calls
> functions from the C++ library?


when you have a C++ Library you can only call C-Style-Functions from that
Library. You cannot export Classes/Methods from that Library.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
10/14/2003 10:01:39 AM
Chris Hills <chris@phaedsys.org> writes:
> In article <clcm-20031008-0017@plethora.net>, thp@cs.ucr.edu writes
> >In comp.std.c cody <NO.SPAM.deutronium@gmx.net> wrote:
> >
> >C is pretty much, but not quite, a sublanguage of C++.
> 
> C++ is based on C90  However C++ is no longer a super set of C. They are
> different languages.

C++ has never been a strict superset of any version of C.  C++ has
several keywords that are not reserved in C; that alone makes prevents
it from being a superset.

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
kst (247)
10/14/2003 10:01:56 AM
On 12 Oct 2003 22:49:25 GMT
Chris Hills <chris@phaedsys.org> wrote:

> C++ is based on C90  However C++ is no longer a super set of C. They
> are different languages.
<snip>
> This is not true. The are using C.  C++ Inherits from C NOT the other
> way round.
I think that members of both the standards committee tried to keep the
standards as coordinated as possible. C++ dropped a lot of the C legacy
(K&R) stuff. 
But also C99 added the // comment which is illegal in C90. 
-- 
Jerry Feldman <gaf-nospam-at-blu.org>
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
gaf-noSPAM (33)
10/14/2003 10:02:52 AM
In article <clcm-20031013-0007@plethora.net>, Chris Hills 
<chris@phaedsys.org> writes
>>A wild guess is that every minute of the day, there is more micro
>>processor code running than PC code running. (?)
>
>According to figures I have seen from several silicon vendors (they vary
>slightly but they average out at about 1 in 3 processors on (and above)
>the planet is an 8051....
>
>PC x86 processors make up less than 10% of the total the other 88% are
>embedded systems... (the 2% are MACs and mainframes.)
>
>I am sure the figures have changed in detail but it gives a fair
>picture.

No one who understands the degree to which embedded systems pervade our 
technological societies would argue that the processors in general 
purpose computers represent anything but a a very small part of the 
population of processors in use. However the step from that to the 
volume of code running at any given time is far more debatable. 8051 
based equipment tends to be running very small amounts of code 
relatively slowly, quite apart from anything else high clock speeds are 
very power hungry so running an 8051 at 2GHz would be inappropriate.

General purpose computer tend to run very large volumes of, often flaky, 
code very fast. Of course there is embedded code running on very fast 
processors (e.g. the latest high end graphics cards that are so power 
hungry that they need to take power directly from the power unit and not 
from the motherboard.) OTOH embedded processor code tends to be compact 
and carefully honed code which is relatively error free. I would hazard 
a guess that the hours of development time per code instruction is an 
order of magnitude (or possibly 2 or even 3 orders) higher than that for 
even for operating systems for PCs.

There is also the issue as to whether the code running on the graphics 
card, sound card etc. counts as PC code or embedded processor code.



-- 
Francis Glassborow      ACCU
If you are not using up-to-date virus protection you should not be reading
this. Viruses do not just hurt the infected but the whole community.
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
francis (122)
10/14/2003 10:03:16 AM
Fergus Henderson <fjh@cs.mu.oz.au> wrote in message news:<3f8b819c$1@news.unimelb.edu.au>...
....
> The difference is generally small, but it does exist.  Compilers have
> less freedom to reorder code that might throw exceptions.

An issue that does not apply to code which uses only the common subset
of C and C++, where care is taken to ensure that the code has the same
meaning in both languages.
0
kuyper5 (433)
10/14/2003 6:19:55 PM
In article <8b42afac.0310141019.1d4158fd@posting.google.com>, kuyper@wizard.net 
says...
> Fergus Henderson <fjh@cs.mu.oz.au> wrote in message news:<3f8b819c$1@news.unimelb.edu.au>...
> ...
> > The difference is generally small, but it does exist.  Compilers have
> > less freedom to reorder code that might throw exceptions.
> 
> An issue that does not apply to code which uses only the common subset
> of C and C++, where care is taken to ensure that the code has the same
> meaning in both languages.

Not so.  A function written in C++ that calls another function cannot assume 
that the called function will not throw an exception.  Therefore it *must* 
retain enough information to reconstruct the call stack so that the exception 
handling mechanisms still work (and it can't do code reording as suggested by 
Fergus Henderson.)  In C, on the other hand, the mechanism for reconstructing 
the stack need only preserve the ability to properly return to the calling 
function.  This difference can result in substantially different object code.

--
Paul Hsieh
http://www.pobox.com/~qed/
0
qed (328)
10/14/2003 7:15:36 PM
James Kuyper wrote:
> 
> Fergus Henderson <fjh@cs.mu.oz.au> wrote in message news:<3f8b819c$1@news.unimelb.edu.au>...
> ...
> > The difference is generally small, but it does exist.  Compilers have
> > less freedom to reorder code that might throw exceptions.
> 
> An issue that does not apply to code which uses only the common subset
> of C and C++, where care is taken to ensure that the code has the same
> meaning in both languages.

The Hewlett-Packard PA-RISC aC++ compiler (table-driven EH, maximum 
optimization level):

                SPEC           SPEED        SIZE 
                BENCHMARK      PENALTY(%)   PENALTY(%)

                099.go         15.60        0.21
                129.compress    2.00       <0.01
                130.li         11.15        1.24
                132.ijpeg      �0.49        0.06
                134.perl        0.81        1.02
                147.vortex      0.66       �0.04

(source: computer.org/concurrency/pd2000/p4072abs.htm)

regards,
alexander.
0
terekhov (1920)
10/14/2003 7:34:53 PM
cody wrote:

>>Is it feasible to interpose a proxy library whose headers are
>>conforming C code that's compiled with a C++ compiler and that calls
>>functions from the C++ library?

> when you have a C++ Library you can only call C-Style-Functions from that
> Library. You cannot export Classes/Methods from that Library.

Unfortunately, "doh" doesn't map well to ascii (the question already 
suggests 'interposing a proxy library').

This means writing a number of C++ functions to get rid of the classes, 
declaring the functions extern "C", and linking to a C program using a 
C++ aware linker.

And yes, this should work (does so with gcc, at least). Things like 
global C++ object constructors/destructors are properly executed, and 
exceptions are properly handled (but cannot, of course, be propagated 
into the C domain - the proxy library should take care of them).

   Sidney

0
sidney (345)
10/14/2003 7:39:28 PM
> size_t s = sizeof ('a');
>
> will set s to sizeof (char) = 1 on all C++ compilers, and set s to
> sizeof (int) on C compilers, which is in practice greater than 1.

sizeof (int)==sizeof ('a') is never true on no C nor C++ compiler on this
world.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk


0
10/14/2003 8:03:35 PM
Alexander Terekhov wrote:
>                 SPEC           SPEED        SIZE 
>                 BENCHMARK      PENALTY(%)   PENALTY(%)

Don't bring reality into this discussion!

0
DAGwyn (797)
10/14/2003 8:06:05 PM
cody wrote:
> sizeof (int)==sizeof ('a') is never true on no C nor C++ compiler on this
> world.

To the contrary, it is required of every C compiler that
conforms to the standard.  (C++ is a different story.)

I suggest that you consider that perhaps the posters to
whom you're responding know more than you do about the
subjects they're discussing.  In order to contribute in
a positive way, you need to learn more.

0
DAGwyn (797)
10/14/2003 8:34:35 PM
"cody" <dont.spam.me.deutronium@gmx.de> wrote:

>> size_t s = sizeof ('a');
>>
>> will set s to sizeof (char) = 1 on all C++ compilers, and set s to
>> sizeof (int) on C compilers, which is in practice greater than 1.
>
>sizeof (int)==sizeof ('a') is never true on no C nor C++ compiler on this
>world.

That would mean that there is no conforming implementation available 
at all; once more you show your lack of C knowledge.  Lookup ISO/IEC 
9899:1999 6.4.4.4#10 for an explanation why you are wrong.

Hint: what is the type of 'a'?

Regards
-- 
Irrwahn 
(irrwahn33@freenet.de)
0
irrwahn33 (608)
10/14/2003 8:47:49 PM
cody wrote:
 
> sizeof (int)==sizeof ('a') is never true on no C nor C++ compiler on this
> world.


Don't you ever get tired of looking like a fool? 




Brian Rodenborn
0
first.last3 (701)
10/14/2003 9:09:32 PM
> Hint: what is the type of 'a'?

char???????

that would mean sizeof((char)1), sizeof((short)1) would output sizeof(int),
too.

But I tried it using the microsoft C Compiler and

printf("%i",sizeof('a'));

prints 1 (as expected from me), whereas

printf("%i",sizeof('a'+'b'));

outputs 4 (as expected)

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk


0
10/14/2003 9:18:53 PM
cody wrote:

>> Hint: what is the type of 'a'?
> 
> char???????

Wrong.

> 
> that would mean sizeof((char)1), sizeof((short)1) would output
> sizeof(int), too.
> 
> But I tried it using the microsoft C Compiler and
> 
> printf("%i",sizeof('a'));
> 
> prints 1 (as expected from me),

That's not the C compiler. That's the C++ compiler. Change your file 
extension to .c if you wish to invoke the C compiler.

-- 
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
0
dontmail (1886)
10/14/2003 9:34:40 PM
Brian Rodenborn wrote:

> Don't you ever get tired of looking like a fool?

I don't think there was any call for that.

0
10/14/2003 9:36:17 PM
> >> Hint: what is the type of 'a'?
> >
> > char???????
>
> Wrong.
>
> >
> > that would mean sizeof((char)1), sizeof((short)1) would output
> > sizeof(int), too.
> >
> > But I tried it using the microsoft C Compiler and
> >
> > printf("%i",sizeof('a'));
> >
> > prints 1 (as expected from me),
>
> That's not the C compiler. That's the C++ compiler. Change your file
> extension to .c if you wish to invoke the C compiler.

Damn you are right :(

But the strange thing is, that

printf("%i",sizeof((char)'a'));

outputs 1. char is not the same as char. funny.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk


0
10/14/2003 9:47:54 PM
"cody" <dont.spam.me.deutronium@gmx.de> wrote:

[crosspost to c.s.c removed]

>> Hint: what is the type of 'a'?
>
>char???????
<sigh> Nooo!!!!!!!

Now that you are unwilling, unable or just too lazy, here you go:

ISO/IEC 9899:1999 
6.4.4.4 Character constants
[...]
10 An integer character constant has type int. The value of an integer 
   character constant containing a single character that maps to a 
   single-byte execution character is the numerical value of the 
   representation of the mapped character interpreted as an integer.  
   The value of an integer character constant containing more than one 
   character (e.g., 'ab'), or containing a character or escape sequence 
   that does not map to a single-byte execution character, is 
   implementation-defined. If an integer character constant contains a 
   single character or escape sequence, its value is the one that 
   results when an object with type char whose value is that of the 
   single character or escape sequence is converted to type int.
[...]


>that would mean sizeof((char)1), sizeof((short)1) would output sizeof(int),
>too.
>
>But I tried it using the microsoft C Compiler and

No.  If at all, you tried it using a C++ compiler.  And, as we all know:

<chorus> Cee plus plus is off topic in comp lang cee </chorus>

[drivel snipped]
-- 
No man is an island -- but some of us are long peninsulas.
0
irrwahn33 (608)
10/14/2003 9:50:44 PM
In article <bmhp8a$n2a2i$2@ID-176797.news.uni-berlin.de>,
 "cody" <dont.spam.me.deutronium@gmx.de> wrote:

> > Hint: what is the type of 'a'?
> 
> char???????
> 
> that would mean sizeof((char)1), sizeof((short)1) would output sizeof(int),
> too.
> 
> But I tried it using the microsoft C Compiler and
> 
> printf("%i",sizeof('a'));
> 
> prints 1 (as expected from me), whereas
> 
> printf("%i",sizeof('a'+'b'));
> 
> outputs 4 (as expected)

Try again. This time make sure that you use the compiler as a C 
compiler, not a C++ compiler.
0
10/14/2003 9:53:40 PM
cody wrote:

> sizeof (int)==sizeof ('a') is never true
> on [any] C nor C++ compiler on this world.

         > cat main.c
         #include<stdio.h>

         int main(int argc, char* argv[]) {
           fprintf(stdout, "%u = sizeof 'a'\n", sizeof 'a');
           return 0;
           }

         > gcc -Wall -std=c99 -pedantic -O2 -o main main.c
         > ./main
         4 = sizeof 'a'

Our indigenous trolls are more interested
in making new subscribers look foolish
than they are in helping them to understand
the C computer programming language.

0
10/14/2003 9:54:06 PM
"cody" <dont.spam.me.deutronium@gmx.de> writes:
> > Hint: what is the type of 'a'?
> 
> char???????

Let me explain why you're wrong.

The type of 'a' is int.  The C99 standard, section 6.4.4.4 paragraph 2,
says:

    An integer character constant is a sequence of one or more
    multibyte characters enclosed in single-quotes, as in 'x'.

Paragraph 10 says:

    An integer character constant has type int.

Any decent C textbook should explain this.  Any C compiler (i.e., not
a C++ compiler) should allow you to demonstrate that sizeof('a') ==
sizeof(int).  If you find that sizeof('a') != sizeof(int), you're not
using a C compiler.

(In C++, a character constant has type char, and sizeof('a') == 1.
We don't discuss C++ here.)

In most contexts, it doesn't matter whether a character constant has
type int or char; it's usually going to be implicitly converted
anyway.  Personally, I would actually prefer it if character constants
had type char rather than int, but my preference isn't strong enough
to suggest changing the language.

If you're going to make definitive statements about these things,
please keep in mind that you're hanging out with experts.  Some of us
(not including myself) helped write the standard; a lot of us have a
copy of it just an arm's reach or a few keystrokes away.

If you want to learn, we'll be delighted to help.  At your current
level of knowledge, I think you're generally better off asking
questions than answering them.  And in many cases you can find the
answers in the C FAQ or in a good textbook.

And speaking of the FAQ, I strongly suggest you read the whole thing.
It's at <http://www.eskimo.com/~scs/C-faq/top.html>.  In particular, I
call your attention to question 8.9, "Why is sizeof('a') not 1?".

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
0
kst (247)
10/14/2003 10:02:57 PM
"cody" <dont.spam.me.deutronium@gmx.de> wrote:

>But the strange thing is, that
>
>printf("%i",sizeof((char)'a'));
>
>outputs 1. char is not the same as char. 

No. A /character constant/ is not of type char.


-- 
Irrwahn 
(irrwahn33@freenet.de)
0
irrwahn33 (608)
10/14/2003 10:16:54 PM
On Tue, 14 Oct 2003 23:18:53 +0200, in comp.lang.c , "cody"
<dont.spam.me.deutronium@gmx.de> wrote:

>> Hint: what is the type of 'a'?
>
>char???????

No its an int. For goodness sake, stop now, you're showing woeful
ignorance. 
 

-- 
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
0
markmcintyre (4555)
10/14/2003 10:20:16 PM
> The type of 'a' is int.  The C99 standard, section 6.4.4.4 paragraph 2,
> says:
>
>     An integer character constant is a sequence of one or more
>     multibyte characters enclosed in single-quotes, as in 'x'.


Was is the same in other versions of C besides C99?

> (In C++, a character constant has type char, and sizeof('a') == 1.
> We don't discuss C++ here.)

template <class T>
void FillBuf(T * buf, int nelements)
{
  memset(buf, 0, sizeof(T)*nelements);
}

Would be very dangerous called with a char argument if C++ would behave like
C
in this context.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk


0
10/14/2003 10:21:21 PM
In article <3F8C707E.90109@jpl.nasa.gov>,
 "E. Robert Tisdale" <E.Robert.Tisdale@jpl.nasa.gov> wrote:

> cody wrote:
> 
> > sizeof (int)==sizeof ('a') is never true
> > on [any] C nor C++ compiler on this world.
> 
>          > cat main.c
>          #include<stdio.h>
> 
>          int main(int argc, char* argv[]) {
>            fprintf(stdout, "%u = sizeof 'a'\n", sizeof 'a');
>            return 0;
>            }
> 
>          > gcc -Wall -std=c99 -pedantic -O2 -o main main.c
>          > ./main
>          4 = sizeof 'a'
> 
> Our indigenous trolls are more interested
> in making new subscribers look foolish
> than they are in helping them to understand
> the C computer programming language.

If you post in comp.std.c and don't understand the C language then you 
deserve everything that is coming. And if you don't know why that is so 
then you don't understand usenet, so you have it coming twice.
0
10/14/2003 10:25:07 PM
"cody" <dont.spam.me.deutronium@gmx.de> wrote in message
news:bmhkqv$mr9d5$1@ID-176797.news.uni-berlin.de...
> > size_t s = sizeof ('a');
> >
> > will set s to sizeof (char) = 1 on all C++ compilers, and set s to
> > sizeof (int) on C compilers, which is in practice greater than 1.
>
> sizeof (int)==sizeof ('a') is never true on no C nor C++ compiler on this
> world.
>
> --
> cody
>
> [Freeware, Games and Humor]
> www.deutronium.de.vu || www.deutronium.tk
>
>

# cat qed.c
#include <stdio.h>
int main(void)
{
    if(sizeof(int) == sizeof 'a')
        puts("Read c99 6.4.4.4#10 -- Q.E.D");
    return 0;
}
# ./qed
Read c99 6.4.4.4#10 -- Q.E.D
#

As Dan Pop would say: ``Engage your brain before posting''



0
10/14/2003 10:26:48 PM
Christian Bau wrote:

> If you post in comp.std.c and don't understand the C language
> then you deserve everything that is coming.

The only thing that cody deserved was to be ignored.

> And, if you don't know why that is so,
> then you don't understand usenet
> so you have it coming twice.

If you think that it is clever or smart to bully new subscribers,
you are nothing more than an indigenous troll.
And *you* should expect to be ignored.

0
10/14/2003 10:36:31 PM
In article <bmhsta$msiaf$1@ID-176797.news.uni-berlin.de>,
 "cody" <dont.spam.me.deutronium@gmx.de> wrote:

> > The type of 'a' is int.  The C99 standard, section 6.4.4.4 paragraph 2,
> > says:
> >
> >     An integer character constant is a sequence of one or more
> >     multibyte characters enclosed in single-quotes, as in 'x'.
> 
> 
> Was is the same in other versions of C besides C99?
> 
> > (In C++, a character constant has type char, and sizeof('a') == 1.
> > We don't discuss C++ here.)
> 
> template <class T>
> void FillBuf(T * buf, int nelements)
> {
>   memset(buf, 0, sizeof(T)*nelements);
> }
> 
> Would be very dangerous called with a char argument if C++ would behave like
> C
> in this context.

I don't think you did understand a thing. You should _really_ stop 
posting to comp.std.c for a year or so; by that time people might have 
forgotten what a fool you are making of yourself right now.
0
10/14/2003 10:37:43 PM
E. Robert Tisdale wrote:

>> Don't you ever get tired of looking like a fool?

> I don't think there was any call for that.

Au contraire, I think everybody has been showing remarkable constraint 
so far. I would like to point out that again and again he was given the 
advice to read up on stuff before blurting out, and *wham* there comes 
another one.

I was tempted for just a second to go across cody's posts of the last 
couple of days and collect some of the highlights, but that would be 
uncalled for. I would hope though that some gentle and, perhaps, 
not-so-gentle reminders of silly behavior would help to bring about a 
change.

It is important to consider that he didn't ask a question, he was trying 
to answer it. Obviously, he has been unable to get his MSVC compiler to 
compile in C mode. This would be amusing in a rather sad way, were it 
not for the fact that he stated:

 >>> sizeof (int)==sizeof ('a') is never true on no C nor C++ compiler on
 >>> this world.

There's matters of intellectual hygiene to consider. Extrapolating one 
(1) observation to a statement of such generality (obviously unburdened 
by knowledge) warrants a slight slap on the wrist.

The reason I take some issue with this is that it took me the better 
part of two hours to reply to his original "Why still use C?" post, 
under the assumption that he wanted an answer. Now it appears he's not a 
troll in the traditional sense, but his attitude definitely needs some 
work. He's acting like a kid sitting for the first time at the grown-ups 
table, trying to take part in the conversation while he's supposed to 
just sit in and listen.

Just my 5 eurocents,

Best regards,

   Sidney Cadot

0
sidney (345)
10/14/2003 10:43:17 PM
"cody" <dont.spam.me.deutronium@gmx.de> writes:
> > The type of 'a' is int.  The C99 standard, section 6.4.4.4 paragraph 2,
> > says:
> >
> >     An integer character constant is a sequence of one or more
> >     multibyte characters enclosed in single-quotes, as in 'x'.
> 
> Was is the same in other versions of C besides C99?

Yes.  If you had carefully read question 8.9 of the C FAQ, you
wouldn't have had to ask that; "ANSI Sec. 3.1.3.4" is a reference to
the previous version of the C standard.

> > (In C++, a character constant has type char, and sizeof('a') == 1.
> > We don't discuss C++ here.)
> 
[C++ code snippet deleted]

We don't discuss C++ here.  Really.  If you'd like to discuss C++,
there are several C++ newsgroups.  (There's also a C++ FAQ you should
read before you post there; google "C++ FAQ" to find it.)

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
0
kst (247)
10/14/2003 10:46:14 PM
cody wrote:

> But I tried it using the microsoft C Compiler [...]

That's a far cry from your previous statement:

 >>> sizeof (int)==sizeof ('a') is never true on no C nor C++ compiler
 >>> on this world.

Ok, you made the honest mistake to not properly instruct your compiler 
to behave as a C compiler (there's a flag for that). The not-very-clever 
thing to do is to extrapolate this to the grandiose statement you made 
earlier. You do realize this no doubt.

The funny thing is, you're probably a nice guy and all. Judging from 
your posts you show some genuine interest in C/C++ issues, combined, 
unfortunately, with a lack of in-depth of knowledge of these topics.

Now from your viewpoint, I will probably come across as an old pedantic 
arrogant fart, but in reality it's not that bad, I can assure you - I'm 
not _that_ old ;-). So putting aside all heated posts of the last days 
for a moment, I would just urge you to take in the advice given on 
several occasions (to think & learn a bit more before you type).

Nobody's perfect and mistakes are ok, but when you are pointed to 
similar mistakes on several occasions, this is often a good clue that 
you need to adjust a bit.

As to the flags, I think you'll need '/TC'. For good measure I'd suggest 
you put in '/W4' as well, this will give a lot of warnings; 
understanding them can really shape up your understanding of C.

Best regards,

   Sidney Cadot

0
sidney (345)
10/14/2003 11:14:34 PM
On Wed, 15 Oct 2003 00:21:21 +0200, in comp.lang.c , "cody"
<dont.spam.me.deutronium@gmx.de> wrote:

>> The type of 'a' is int.  The C99 standard, section 6.4.4.4 paragraph 2,
>> says:
>>
>>     An integer character constant is a sequence of one or more
>>     multibyte characters enclosed in single-quotes, as in 'x'.
>
>
>Was is the same in other versions of C besides C99?

Always been this way. 


-- 
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
0
markmcintyre (4555)
10/14/2003 11:53:51 PM
cody wrote:

> sorry i don't know the term "dead on". what does it mean?

http://dict.leo.org/?search=dead+on

/Sven ;)

-- 
Remove the "-usenet" part of the mail address to mail me. The Gibe/Swen
worm forced me to shutdown my usenet email address for a limited time.
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
10/15/2003 4:50:57 AM
On 14 Oct 2003 10:01:56 GMT
Keith Thompson <kst@cts.com> wrote:

> Chris Hills <chris@phaedsys.org> writes:
> > In article <clcm-20031008-0017@plethora.net>, thp@cs.ucr.edu writes
> > >In comp.std.c cody <NO.SPAM.deutronium@gmx.net> wrote:
> > >
> > >C is pretty much, but not quite, a sublanguage of C++.
> > 
> > C++ is based on C90  However C++ is no longer a super set of C. They
> > are different languages.
> 
> C++ has never been a strict superset of any version of C.  C++ has
> several keywords that are not reserved in C; that alone makes prevents
> it from being a superset.
I agree that "C++ has never been a strict superset of any version of C",
but I disagree with your logic. A superset can define new keywords (and
comment operators). However there are many constructs in standard C that
are illegal in C++. One example that comes to mine is:
In C:
void foo(void);
In C++ this will cause a syntax error because C++ requires fully
prototyped functions. So, the C++ equivalent is:
void foo();
Since in C++, an empty parameter list means just that, where in C, it
may indicate a legacy function declaration. 

Additionally, C++ disallows most of the older legacy (K&R) code that the
C standard had to allow. 

So, to be a superset, C++ must be able to compile any legal C program,
and clearly C++ was not intended to do so. 
-- 
Jerry Feldman <gaf-nospam-at-blu.org>
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
gaf-noSPAM (33)
10/15/2003 4:51:23 AM
In article <clcm-20031014-0011@plethora.net>, Francis Glassborow
<francis@robinton.demon.co.uk> writes
>volume of code running at any given time is far more debatable. 8051 
>based equipment tends to be running very small amounts of code 
>relatively slowly, quite apart from anything else high clock speeds are 
>very power hungry so running an 8051 at 2GHz would be inappropriate.

Francis, AFAIK you have absolutely no knowledge of the 8051 other than
what I have told you in various ACCU and BSI meetings.... and that has
been very superficial. It would be best if you did not use it as an
example.

Being power hungry is not the reason why an 8051 does not (normally) run
at 2Ghz.... Many 8051's work in areas where power is not a factor.  They
run code from 2Kbytes to 16Mega bytes.

There are also many 32 and 64 bit embedded systems running that have
megabytes of code.... virtually any car radio or engine management
system. I did have the figures for the line of code in a car radio. It
was in the 100's of thousand lines! It surprised me.  Engine management
systems have the odd megabyte of code. 

Then there is the telephone & internet system... based on MIPs and PPC.
One SDH switch I worked on had a PPS and 12  486 parts as slaves running
gigabytes of code.... 

Every aircraft is running a million or two lines of code as soon as the
inverters go on..... 

Actually most things run far more code than you would imagine. From a
washing machine upwards.

>General purpose computer tend to run very large volumes of, often flaky, 
>code very fast. Of course there is embedded code running on very fast 
>processors 

Some of it faster than the average PC.

>(e.g. the latest high end graphics cards that are so power 
>hungry that they need to take power directly from the power unit and not 
>from the motherboard.) 

Actually some of the more powerful embedded processors like the Power PC
don't have a power )or the associated heat) problem. Just listen to an
iMac running for hours with no fan.... 



>OTOH embedded processor code tends to be compact 
>and carefully honed code which is relatively error free. I would hazard 
>a guess that the hours of development time per code instruction is an 
>order of magnitude (or possibly 2 or even 3 orders) higher than that for 
>even for operating systems for PCs.

No so from my experience. though it is true that the average PC
programmer will be pulling in a large overhead of library code for the
GUi and other libraries.


>There is also the issue as to whether the code running on the graphics 
>card, sound card etc. counts as PC code or embedded processor code.

Good point.....  very debatable. You get to choose do you want to be
Bill Gates or Plato for this one? :-)



/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
chris32 (3361)
10/15/2003 4:51:27 AM
"cody" <dont.spam.me.deutronium@gmx.de> wrote in message news:<clcm-20031013-0003@plethora.net>...
,,,
> you mean a typedef let you omit the keyword? thanks, i didn't know that.

Of course. Without typedefs, normal type specifiers have to contain at
least one keyword (such as 'int'), and usually contain many of them
(such as 'const' and 'volatile'). Typedefs allow you to replace the
entire type specifier with a single typedef name.

....
> > (Oh, and re your response to Jack Klein: While IMHO Jack was a
> > bit harsh, and a bit defensive, his criticism of your style was
> > dead on.
> 
> sorry i don't know the term "dead on". what does it mean?

It means "exactly correct". The relevant image for this phrase is
someone shooting at a target; when they hit the target, their shooting
is said to be "dead on".
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
kuyper5 (433)
10/15/2003 4:51:31 AM
cody wrote:
> But I tried it using the microsoft C Compiler and
> printf("%i",sizeof('a'));

If you mean Visual C++, that is not a C compiler but
rather some sort of C++ compiler.  Perhaps it has some
option you can specify to make it operate as a C
compiler, in which case you should see a different
result.  As was already explained, C and C++ differ
with regard to the type of a character constant.

By the way, you don't need the extra parentheses,
which obscure the distinction between the two forms
of sizeof.

0
DAGwyn (797)
10/15/2003 5:41:18 AM
cody wrote:
> printf("%i",sizeof((char)'a'));
> outputs 1. char is not the same as char. funny.

char *is* the same as char.  Your error is in thinking
that in C a character constant has type char.  As has
ben explained several times, it has type int.  I could
explain the historical reasons for this but they are
beside the point.

0
DAGwyn (797)
10/15/2003 5:42:59 AM
E. Robert Tisdale wrote:
> Our indigenous trolls are more interested
> in making new subscribers look foolish
> than they are in helping them to understand
> the C computer programming language.

Cody doesn't need anybody's help to look foolish.
If he would stop asserting misinformation and instead
ask questions, he would get a different response.

0
DAGwyn (797)
10/15/2003 5:45:22 AM

[cross-post to comp.lang.c.moderated removed, for chronological reasons
- I like to see my posts appear within a week, thankyouverymuch :) ]

On Wed, 15 Oct 2003, Jerry Feldman wrote:
>
> Keith Thompson <kst@cts.com> wrote:
> > > thp@cs.ucr.edu writes
> > > >
> > > >C is pretty much, but not quite, a sublanguage of C++.
> >
> > C++ has never been a strict superset of any version of C.  C++ has
> > several keywords that are not reserved in C; that alone makes prevents
> > it from being a superset.
>
> I agree that "C++ has never been a strict superset of any version of C",
> but I disagree with your logic.

"That's impossible!  Logic cannot be refuted!"

> A superset can define new keywords (and comment operators).

....however, if any of those additions mean that there exist C programs
that are not C++ programs, then (the set of) C++ (programs) is no
longer a superset of (the set of) C (programs).  For example:

   int test(int size)
   {
      int *new = malloc(size);  /* two non-C++isms in this line */
      return 1 //*
             -1 + 1;   /* 0 in C99, 1 in C++ */
   }


> However there are many constructs in standard C that
> are illegal in C++. One example that comes to mine is:
> In C:
> void foo(void);
> In C++ this will cause a syntax error because C++ requires fully
> prototyped functions.

How long have you been programming in C++?

> So, the C++ equivalent is:
> void foo();

<snip>

> So, to be a superset, C++ must be able to compile any legal C program,
> and clearly C++ was not intended to do so.

Right.  There's no shame in not being a superset of C; many
languages aren't.  And they get along just fine. :-)

-Arthur

0
ajo (1603)
10/15/2003 5:49:37 AM
Keith Thompson wrote:
> Personally, I would actually prefer it if character constants
> had type char rather than int, but my preference isn't strong enough
> to suggest changing the language.

There are a large number of things about C that deserve
to be changed, if we were to go about cleaning up the
language.  Unfortunately, nearly all of these would
cause existing carefully written programs to behave
differently.  Legacy is a severe constraint.

I'm thinking seriously about using my copious free time
(when I finally get some!) to go back to ~7th Edition
Unix and explore an alternate evolution using a clean
C-inspired language that takes into account lessons
learned over decades of C programming.  I don't think
it would look much like Limbo, but it might borrow some
ideas such as tuples:  (a;b) := (b;a); // swap a & b

0
DAGwyn (797)
10/15/2003 5:53:02 AM
cody wrote:
>>The type of 'a' is int.  ...
> Was is the same in other versions of C besides C99?

It has "always" been that way.

> template <class T>
> void FillBuf(T * buf, int nelements)
> {
>   memset(buf, 0, sizeof(T)*nelements);
> }
> Would be very dangerous called with a char argument if C++ would behave like
> C
> in this context.

No, you stll don't understand what has been explained
several times now.  Char has nothing to do with this.

0
DAGwyn (797)
10/15/2003 5:56:14 AM
In article <0YSdnZUx6N0hfRGiU-KYgw@comcast.com>,
 "Douglas A. Gwyn" <DAGwyn@null.net> wrote:

> Keith Thompson wrote:
> > Personally, I would actually prefer it if character constants
> > had type char rather than int, but my preference isn't strong enough
> > to suggest changing the language.
> 
> There are a large number of things about C that deserve
> to be changed, if we were to go about cleaning up the
> language.  Unfortunately, nearly all of these would
> cause existing carefully written programs to behave
> differently.  Legacy is a severe constraint.
> 
> I'm thinking seriously about using my copious free time
> (when I finally get some!) to go back to ~7th Edition
> Unix and explore an alternate evolution using a clean
> C-inspired language that takes into account lessons
> learned over decades of C programming.  I don't think
> it would look much like Limbo, but it might borrow some
> ideas such as tuples:  (a;b) := (b;a); // swap a & b

With a slightly different syntax

   (a;b) = (b;a);

this could be added to C. The semantics would be interesting. I assume 
that you would want this to have defined behaviour. Tuple r-values would 
be obvious, and something like (a;a;a) is no problem as an r-value. I 
guess modifying a tuple l-value that contains the same object twice is 
undefined behavior, for example (a;a) = (1;2); would be undefined 
behavior. Apart from that, if a tuple l-value is used in an assignment 
statement, then all the components of the tuple form one object which is 
the only object that is modified. 

   (a;b) += (b;a);

would be no problem because it is by definition the same as

   (a;b) = (a;b) + (b;a);
0
10/15/2003 7:11:02 AM
"E. Robert Tisdale" <E.Robert.Tisdale@jpl.nasa.gov> wrote:

> Christian Bau wrote:
> 
> > If you post in comp.std.c and don't understand the C language
> > then you deserve everything that is coming.
> 
> The only thing that cody deserved was to be ignored.

What, and allow other newbies to believe that his erroneous statements
are correct? _That_ would be far less than courteous, perhaps not to
cody (though a good programmer is aware of his own failings and grateful
for correct information), but certainly to all other beginners trying to
find good C information here.

Richard
0
rlb (4118)
10/15/2003 8:25:00 AM
>    int test(int size)
>    {
>       int *new = malloc(size);  /* two non-C++isms in this line */
>       return 1 //*
>              -1 + 1;   /* 0 in C99, 1 in C++ */
>    }

is the missing semicolon at the end of a block allowed in C?

> > However there are many constructs in standard C that
> > are illegal in C++. One example that comes to mine is:
> > In C:
> > void foo(void);
> > In C++ this will cause a syntax error because C++ requires fully
> > prototyped functions.
>
> How long have you been programming in C++?

Was there something incorrect?

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk


0
10/15/2003 8:17:35 PM
"Douglas A. Gwyn" <DAGwyn@null.net> schrieb im Newsbeitrag
news:FZmcncvzrfFhQBGiXTWJlg@comcast.com...
> cody wrote:
> > But I tried it using the microsoft C Compiler and
> > printf("%i",sizeof('a'));
...
> By the way, you don't need the extra parentheses,
> which obscure the distinction between the two forms
> of sizeof.


You mean sizeof for types and sizeof for variables?
In C++ sizeof for variables needs parantheses, sizeof for types don't.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk


0
10/15/2003 8:30:30 PM
> Cody doesn't need anybody's help to look foolish.
> If he would stop asserting misinformation and instead
> ask questions, he would get a different response.


The problem is that i believe that my assertions are correct. But iam very
very
thankful for the many many valuable responses i got here.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk


0
10/15/2003 8:35:02 PM
cody wrote:
> In C++ sizeof for variables needs parantheses, sizeof for types don't.

First, you're posting in C newsgroups, not C++.
Second, I doubt very much that that is true for C++;
it is certainly wrong for C.
Third, they're not variables, they're expressions.

0
DAGwyn (797)
10/15/2003 9:13:04 PM
cody wrote:
> The problem is that i believe that my assertions are correct.

Yes, that is a problem.  You should work on a better
understanding of what it is that you definitely know
versus what it is that you're just guessing about.

0
DAGwyn (797)
10/15/2003 9:15:39 PM
OK i tried it and:

int i = sizeof (int);
// int j = sizeof int; // invalid in both C and C++
int k = sizeof i;
int l = sizeof (i);

The form of sizeof that gets a type as parameter has to use parantheses,
while the sizeof that gets non-expressions as parameter do not need them.
This seems to be true for both C and C++ compilers (I tried both).

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk


0
10/15/2003 9:54:47 PM
On Wed, 15 Oct 2003 22:17:35 +0200
"cody" <dont.spam.me.deutronium@gmx.de> wrote:

Please don't trim the attributions since it prevents people from seeing
who said what.

> >    int test(int size)
> >    {
> >       int *new = malloc(size);  /* two non-C++isms in this line */
> >       return 1 //*
> >              -1 + 1;   /* 0 in C99, 1 in C++ */
> >    }
> 
> is the missing semicolon at the end of a block allowed in C?

A semicolon is required to terminate every C statement, however in C99
there is no missing semicolon in the above.

HINT: C99 added a form of // commenting.

<snip>
-- 
Mark Gordon
Paid to be a Geek & a Senior Software Developer
Although my email address says spamtrap, it is real and I read it.
0
spamtrap606 (150)
10/15/2003 10:22:09 PM
"Douglas A. Gwyn" wrote:
> 
> cody wrote:
> > In C++ sizeof for variables needs parantheses, sizeof for types don't.
> 
> First, you're posting in C newsgroups, not C++.
> Second, I doubt very much that that is true for C++;
> Third, they're not variables, they're expressions.

Section 5.3p1 of the C++ standard says pretty much the same thing that
6.5.3 says in the C standard: 

_unary-expression_:
        ...
	sizeof _unary-expression_
	sizeof ( _type-id_ )

Paragraph 3 says the same thing in words: "... The operand is either an
expression, ..., or a parenthesized _type-id_. ..."

So cody has it almost exactly backwards. It's only "almost", not because
there's some truth in his claim, but because he used the wrong words.
This seems to fit his track record. I wonder when he'll decide to start
checking the validity of his claims before posting them?
0
kuyper (156)
10/15/2003 10:42:09 PM
cody wrote:

>>    int test(int size)
>>    {
>>       int *new = malloc(size);  /* two non-C++isms in this line */
>>       return 1 //*
>>              -1 + 1;   /* 0 in C99, 1 in C++ */
>>    }
> 
> is the missing semicolon at the end of a block allowed in C?

No, and that wasn't his only mistake.

int test(int size)
{
  int *new = malloc(size);
  return 1 //*
      -1 + 1 /* 0 in C90, 1 in C++ and C99 */
    ;
}

> 
>> > However there are many constructs in standard C that
>> > are illegal in C++. One example that comes to mine is:
>> > In C:
>> > void foo(void);
>> > In C++ this will cause a syntax error because C++ requires fully
>> > prototyped functions.
>>
>> How long have you been programming in C++?
> 
> Was there something incorrect?

Yes. void foo(void); /is/ a full prototype, in both C and C++.

It is as well for your real-world reputation that you post under a 
pseudonym.

-- 
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
0
dontmail (1886)
10/15/2003 11:37:07 PM
cody wrote:

> OK i tried it and:
> 
> int i = sizeof (int);
> // int j = sizeof int; // invalid in both C and C++
> int k = sizeof i;
> int l = sizeof (i);

Wrong type. Use size_t for capturing the value yielded by sizeof.

> The form of sizeof that gets a type as parameter has to use parantheses,
> while the sizeof that gets non-expressions as parameter do not need them.

Wrong. In your example, i is an unary-expression, not a non-expression.

Specifically, the grammar says:

unary-expression:
  postfix-expression
  ++ unary-expression
  -- unary-expression
  unary-operator cast-expression
  sizeof unary-expression
  sizeof ( type-name )

(taken from K&R2, p238, since it happened to be on my desk, opened to that 
page!)

Note also that sizeof takes an operand, not a parameter.

> This seems to be true for both C and C++ compilers (I tried both).

It really is time to stop guessing at this stuff. The C language is defined 
by an international standard, not by your apparently random guesses.

-- 
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
0
dontmail (1886)
10/15/2003 11:42:23 PM
Douglas A. Gwyn wrote:

> cody wrote:
>> The problem is that i believe that my assertions are correct.
> 
> Yes, that is a problem.

I hope the sig-monsters are awake.

-- 
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
0
dontmail (1886)
10/15/2003 11:43:37 PM
Richard Heathfield <dontmail@address.co.uk.invalid> writes:
> cody wrote:
> 
> > OK i tried it and:
> > 
> > int i = sizeof (int);
> > // int j = sizeof int; // invalid in both C and C++
> > int k = sizeof i;
> > int l = sizeof (i);
> 
> Wrong type. Use size_t for capturing the value yielded by sizeof.

It's not entirely unreasonable to use int rather than size_t in this
particular case.  The result of the sizeof operator, which is of
course of type size_t, is implicitly converted to type int, which is
virtually certain to be able to hold the result.  (I say "virtually
certain" rather than "certain" because I can just barely imagine that
some insanely evil implementer might shove enough padding bits into
type int to make its size overflow an int without breaking
conformance.)

Richard's other criticisms are, of course, dead on.

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
0
kst (247)
10/16/2003 12:40:31 AM
On Wed, 15 Oct 2003, Richard Heathfield wrote:
>
> cody wrote:
> [Arthur wrote:]
> >>    int test(int size)
> >>    {
> >>       int *new = malloc(size);  /* two non-C++isms in this line */
> >>       return 1 //*
> >>              -1 + 1;   /* 0 in C99, 1 in C++ */
> >>    }
> >
> > is the missing semicolon at the end of a block allowed in C?
>
> No, and that wasn't his only mistake.

Whew, I'm lucky I was lazy in responding. :)  I completely forgot
about // comments' being legal C99.  But your code still has a
bug; under C90, the /**/ comments disappear to create

  int foo = 1/;

don't they?  So I guess after fixing that, we could throw in a
sizeof('x') for good measure.  [ACTUAL TESTED CODE FOLLOWS(!)]


#include <stdio.h>

int test_version(void)
{
    /* Returns 0 under C90, 1 under C99, and 2 under C++ */

    int isnt_c90 = 1 //*
                   -1   /* 0 in C90, 1 in C99/C++ */
                   +2 / 2;
    int is_cxx = (sizeof('x') == 1);  /* not completely guaranteed
                                       * to work, but the best I know
                                       * off the top of my head */
    return isnt_c90 + is_cxx;
}

int main(void)
{
    printf("%d\n", test_version());
    /* gcc -std=c89: 0 */
    /* gcc -std=c99: 1 */
    /* g++: 2 */
    return 0;
}



Now, what silly mistakes have I made *this* time?  :-)

-Arthur
0
ajo (1603)
10/16/2003 1:21:37 AM
In article <Pine.LNX.4.58-035.0310152107200.21719@unix47.andrew.cmu.edu>
Arthur J. O'Dwyer <ajo@nospam.andrew.cmu.edu> writes, in part:
>    int is_cxx = (sizeof('x') == 1);  /* not completely guaranteed
>                                       * to work, but the best I know
>                                       * off the top of my head */

As you note, this can falsely claim "is C++" if sizeof(int)==1.

A test that does not have this failing -- that *is* guaranteed
to distinguish between C and C++ -- is one that relies on the
differing scope rules.  Here is a complete test program.

    #include <stdio.h>

    struct A { char c; };

    int is_cplusplus(void) {
        struct B { struct A { char c[2]; } b; };
        struct A x;
     
        return sizeof x.c == 1;
    }

    int main(void) {
        printf("this was compiled with a %s compiler\n",
            is_cplusplus() ? "C++" : "C");
        return 0;
    }

The trick is that the name "struct A" refers to the *inner* "struct
A" in C, but to the global (outer) "struct A" in C++.  (In C++-ese,
x is defined as ::A instead of ::B::A.  Thus in C++ x.c is a single
"char", while in C++ x.c is an array of two "char"s.)

This particular difference between the two languages can turn a
correct C program -- one that writes into both bytes of x.c[] --
into an incorrect C++ program when compiled with a C++ compiler.
Thus, even putting aside the obvious syntactic incompatibilities
between the two languages, I claim it is dangerous to compile C
code with a C++ compiler.  You might overrun arrays, as this
program could do if it assumed it was compiled with a C compiler
(if is_cplusplus() were to write on x.c[1]).
-- 
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40�39.22'N, 111�50.29'W)  +1 801 277 2603
email: forget about it   http://67.40.109.61/torek/index.html (for the moment)
Reading email is like searching for food in the garbage, thanks to spammers.
0
nospam240 (154)
10/16/2003 3:01:20 AM
Arthur J. O'Dwyer wrote:

<snip> 
> I completely forgot
> about // comments' being legal C99.  But your code still has a
> bug; under C90, the /**/ comments disappear to create
> 
>   int foo = 1/;
> 
> don't they?  So I guess after fixing that, we could throw in a
> sizeof('x') for good measure.  [ACTUAL TESTED CODE FOLLOWS(!)]

"ACTUAL TESTED CODE"? Isn't that cheating?

-- 
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
0
dontmail (1886)
10/16/2003 6:42:20 AM
Jerry Feldman <gaf-noSPAM@blu.org> writes:

>Keith Thompson <kst@cts.com> wrote:
>
>> C++ has never been a strict superset of any version of C.  C++ has
>> several keywords that are not reserved in C; that alone makes prevents
>> it from being a superset.
>
>I agree that "C++ has never been a strict superset of any version of C",
>but I disagree with your logic. A superset can define new keywords (and
>comment operators).

A strict superset can't, if those keywords have names which are not
already reserved for use by the implementation, because adding new
keywords will invalidate existing C programs that happen to use those
keywords as identifiers.

Adding new comment operators can also change the meaning of existing code.
Consider the following program:

	int main() {
		printf(1//**/2
		  ? "fail\n" : "pass\n");
		return 0;
	}

On a conforming C89 implementation, this will print "pass",
but on a C++ or C99 implementation, it will print "fail".

>However there are many constructs in standard C that
>are illegal in C++. One example that comes to mine is:
>In C:
>void foo(void);
>In C++ this will cause a syntax error because C++ requires fully
>prototyped functions.

That's not correct either.  C++ allows "void foo(void);".

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
fjh (268)
10/16/2003 8:02:50 AM
In article <clcm-20031014-0015@plethora.net>, Chris Hills 
<chris@phaedsys.org> writes
>Francis, AFAIK you have absolutely no knowledge of the 8051 other than
>what I have told you in various ACCU and BSI meetings.... and that has
>been very superficial. It would be best if you did not use it as an
>example.


It would also be nice if you avoided assuming that you are my only 
source of information.

However one factor often missed is that these days we often use 
micro-processors to do things that are note remotely related to a 
traditional view of their uses. The growth of digital sound and vision 
systems is largely driven by the ability to bring computing power to 
tasks that thirty years ago would have been considered as completely 
outside the domain of computing.

One interesting point is that in times gone by much effort was put into 
developing analogue computing technology in order to improve data 
throughput where some loss of quality was acceptable. These days we 
develop digital systems with the same motive:-)

I suspect that LSI has changed the world in ways that neither of us 
could have imagined in our youth and that most people do not have the 
slightest grasp of the extent to which modern technology relies on 
computing technology.


-- 
Francis Glassborow      ACCU
If you are not using up-to-date virus protection you should not be reading
this. Viruses do not just hurt the infected but the whole community.
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
francis (122)
10/16/2003 8:03:03 AM
"Sven Semmler" <sven-usenet@semmlerconsulting.com> schrieb im Newsbeitrag
news:clcm-20031014-0012@plethora.net...
> cody wrote:
>
> > sorry i don't know the term "dead on". what does it mean?
>
> http://dict.leo.org/?search=dead+on
>
> /Sven ;)


thankx

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
10/16/2003 8:03:14 AM
Chris Hills <chris@phaedsys.org> wrote in message news:<clcm-20031014-0015@plethora.net>...
> 
> Being power hungry is not the reason why an 8051 does not (normally) run
> at 2Ghz.... Many 8051's work in areas where power is not a factor.  They
> run code from 2Kbytes to 16Mega bytes.
> 

Yes, the usual reasons for slower clock speeds are (in my business):
 - Slower rated chips are cheaper
 - You don't usually need that speed
 - Heat dissipation becomes a problem at high speeds

> There are also many 32 and 64 bit embedded systems running that have
> megabytes of code.... virtually any car radio or engine management
> system. I did have the figures for the line of code in a car radio. It
> was in the 100's of thousand lines! It surprised me.  Engine management
> systems have the odd megabyte of code. 

and when things are programmed in assembler, an 8K processor can still
hold 6-8 KLOC!.

Keith Derrick (ACCU member)
PS Don't bother sending mail to my posting address, it's a spam trap.
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
kderrick (1)
10/16/2003 8:03:22 AM
On Mon, 13 Oct 2003 22:18:56 +0200 in comp.std.c, Alexander
Terekhov <terekhov@web.de> wrote:

>
>thp@cs.ucr.edu wrote:
>[...]
>> C is pretty much, but not quite, a sublanguage of C++.  C programmers
>> who don't use the non-C++ features of C are programming in C++ whether
>> they claim to or not.  They are restricting themselves to an older,
>> more established, more easily learned, and more easily implemented
>> subset of C++.  But they are writing in C++ --- non-idiomatic C++, but
>> C++ nevertheless.  AFAIK, a C++ compile is free to generate the same
>> code for those programs as would a C compiler, so there is no
>> intrinsic difference in performance.
>
>In C without exceptions (stuff like MS or DEC/HP SEH extensions), all 
>functions are kinda "throw()". 

I take exception to the object of that last block! ;^>
In idiomatic C, each function is like a try block, each return is
like a throw, and each call is like a catch. 

Thanks. Take care, Brian Inglis 	Calgary, Alberta, Canada
-- 
Brian.Inglis@CSi.com 	(Brian dot Inglis at SystematicSw dot ab dot ca)
    fake address		use address above to reply
0
10/16/2003 10:07:10 AM
On Wed, 15 Oct 2003 00:21:21 +0200 in comp.std.c, "cody"
<dont.spam.me.deutronium@gmx.de> wrote:

>> The type of 'a' is int.  The C99 standard, section 6.4.4.4 paragraph 2,
>> says:
>>
>>     An integer character constant is a sequence of one or more
>>     multibyte characters enclosed in single-quotes, as in 'x'.
>
>
>Was is the same in other versions of C besides C99?

As far back as K&R1 -- common C idiom was 'ab' (16 bit) or 'abcd'
(32 bit) to handle packed chars -- undefined behaviour as of C89
-- but still allowed and works? 

Thanks. Take care, Brian Inglis 	Calgary, Alberta, Canada
-- 
Brian.Inglis@CSi.com 	(Brian dot Inglis at SystematicSw dot ab dot ca)
    fake address		use address above to reply
0
10/16/2003 10:20:13 AM
"Fergus Henderson" <fjh@cs.mu.oz.au> wrote in message
news:clcm-20031016-0001@plethora.net...
> Jerry Feldman <gaf-noSPAM@blu.org> writes:
>
> >Keith Thompson <kst@cts.com> wrote:
> >
> >> C++ has never been a strict superset of any version of C.  C++ has
> >> several keywords that are not reserved in C; that alone makes prevents
> >> it from being a superset.
> >
> >I agree that "C++ has never been a strict superset of any version of C",
> >but I disagree with your logic. A superset can define new keywords (and
> >comment operators).
>
> A strict superset can't, if those keywords have names which are not
> already reserved for use by the implementation, because adding new
> keywords will invalidate existing C programs that happen to use those
> keywords as identifiers.
>

I don't know why people mold terms to fit things how they would like to see
them.
C++ is not a superset, period. ``strict superset'' throw it out of the
window.
When something is a ``superset'' of something else, that something else is
considered to be a ``subset''.
Now inorder for C to be a subset of C++, you would be able to compile _any_
C program with a C++ compiler. This can't be done, because C is not a subset
of C++, and that is because C++ is not a superset of C. It is a
``derivative'' of C. Nothing more and nothing less.

> Adding new comment operators can also change the meaning of existing code.
> Consider the following program:
>
> int main() {
> printf(1//**/2
>   ? "fail\n" : "pass\n");
> return 0;
> }
>
> On a conforming C89 implementation, this will print "pass",
> but on a C++ or C99 implementation, it will print "fail".
>
> >However there are many constructs in standard C that
> >are illegal in C++. One example that comes to mine is:
> >In C:
> >void foo(void);
> >In C++ this will cause a syntax error because C++ requires fully
> >prototyped functions.
>
> That's not correct either.  C++ allows "void foo(void);".
>
> --
> Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the
pursuit
> The University of Melbourne         |  of excellence is a lethal habit"
> WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
> --
> comp.lang.c.moderated - moderation address: clcm@plethora.net


0
10/16/2003 10:20:51 AM
Arthur J. O'Dwyer wrote:

[C89/C99/C++ tests]
> Now, what silly mistakes have I made *this* time?  :-)

Failure to use the standard macros? ;-)

#include "stdio.h"
int main(void)
{
   int
#ifdef __cplusplus
   i = 2;
#elif defined __STDC_VERSION__ && __STDC_VERSION__ == 199901L
   i = 1;
#else
   i = 0;
#endif
   puts(i == 2 ? "C++" : i == 1 ? "C99" : "C89");
   return 0;
}

Jirka

0
jklaue2 (127)
10/16/2003 12:38:30 PM
Jirka Klaue wrote:
> #include "stdio.h"
> int main(void)
> {
>    int
> #ifdef __cplusplus
>    i = 2;
> #elif defined __STDC_VERSION__ && __STDC_VERSION__ == 199901L
>    i = 1;
> #else
>    i = 0;
> #endif
>    puts(i == 2 ? "C++" : i == 1 ? "C99" : "C89");
>    return 0;
> }

A C89 implementation is allowed to define a __cplusplus macro, AFAICT.
(You also classify C0X as C89).

Jeremy.
0
jeremy63 (294)
10/16/2003 1:49:51 PM
On Wed, 15 Oct 2003 23:42:23 +0000 (UTC), Richard Heathfield
<dontmail@address.co.uk.invalid> wrote:

>cody wrote:
[...]
>
>> This seems to be true for both C and C++ compilers (I tried both).
>
>It really is time to stop guessing at this stuff. The C language is defined 
>by an international standard, not by your apparently random guesses.

"It works on my compiler" is never a good argument in c.s.c.

Regards,

                               -=Dave
-- 
Change is inevitable, progress is not.
0
iddw (680)
10/16/2003 2:14:30 PM
"Mark Gordon" <spamtrap@flash-gordon.me.uk> schrieb im Newsbeitrag
news:20031015232209.128f9a60.spamtrap@flash-gordon.me.uk...
> On Wed, 15 Oct 2003 22:17:35 +0200
> "cody" <dont.spam.me.deutronium@gmx.de> wrote:
>
> Please don't trim the attributions since it prevents people from seeing
> who said what.
>
> > >    int test(int size)
> > >    {
> > >       int *new = malloc(size);  /* two non-C++isms in this line */
> > >       return 1 //*
> > >              -1 + 1;   /* 0 in C99, 1 in C++ */
> > >    }
> >
> > is the missing semicolon at the end of a block allowed in C?
>
> A semicolon is required to terminate every C statement, however in C99
> there is no missing semicolon in the above.
>
> HINT: C99 added a form of // commenting.


int test(int size)
{
       int *new = malloc(size);  /* two non-C++isms in this line */

       return 1 //*          <-- the c version misses a semicolon here,
additionally //* will imho produce no valid comment in c.

             -1 + 1;   /* 0 in C99, 1 in C++ */
}

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk


0
10/16/2003 9:57:20 PM
> > int i = sizeof (int);
> > // int j = sizeof int; // invalid in both C and C++
> > int k = sizeof i;
> > int l = sizeof (i);
> >
> > The form of sizeof that gets a type as parameter has to use parantheses,
> > while the sizeof that gets non-expressions as parameter do not need
them.
>
> Wrong. In your example, i is an unary-expression, not a non-expression.

I don't know why i wrote non-expression. My example clearly showed how to
use sizeof:

The form of sizeof that gets a type (NON-EXPRESSION) as parameter has to use
parantheses,
while the sizeof that gets expressions (NON-TYPES) as parameter do not need
them.

Is it now correctly stated?

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk


0
10/16/2003 10:04:59 PM
"Richard Heathfield" <dontmail@address.co.uk.invalid> schrieb im Newsbeitrag
news:bmkm38$3pe$5@titan.btinternet.com...
> Douglas A. Gwyn wrote:
>
> > cody wrote:
> >> The problem is that i believe that my assertions are correct.
> >
> > Yes, that is a problem.
>
> I hope the sig-monsters are awake.


What is a sig-monster?

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk


0
10/16/2003 10:09:41 PM
On Thu, 16 Oct 2003 23:57:20 +0200
"cody" <dont.spam.me.deutronium@gmx.de> wrote:

> "Mark Gordon" <spamtrap@flash-gordon.me.uk> schrieb im Newsbeitrag
> news:20031015232209.128f9a60.spamtrap@flash-gordon.me.uk...
> > On Wed, 15 Oct 2003 22:17:35 +0200
> > "cody" <dont.spam.me.deutronium@gmx.de> wrote:
> >
> > Please don't trim the attributions since it prevents people from
> > seeing who said what.
> >
> > > >    int test(int size)
> > > >    {
> > > >       int *new = malloc(size);  /* two non-C++isms in this line
> > > >       */ return 1 //*
> > > >              -1 + 1;   /* 0 in C99, 1 in C++ */
> > > >    }
> > >
> > > is the missing semicolon at the end of a block allowed in C?
> >
> > A semicolon is required to terminate every C statement, however in
> > C99 there is no missing semicolon in the above.
> >
> > HINT: C99 added a form of // commenting.
> 
> 
> int test(int size)
> {
>        int *new = malloc(size);  /* two non-C++isms in this line */
> 
>        return 1 //*          <-- the c version misses a semicolon
                  ^^ This starts a comment, the * is just a commented
out character.
>        here,
> additionally //* will imho produce no valid comment in c.

In C99, once it has seen the // everything after on the line is
considered a comment.

Copied from section 6.4 of a copy of n897.pdf...

   // comments were added for C9X ....

   In certain unusual situations, code could have different semantics
   for C90 and C9X. for example

      a = b //*divisor:*/ c
      + d;

   In C90 this was equivalent to

      a = b  c + d;

   but in C9X it is equivalent to

      a = b + d;

As you can see from the above in C99, //* is treated as a // style
comment the first character of which happens to be a * and the // style
comment ends at the end of the line. So for the example at the top in
C99, which is what it refers to, the first comment starts with a // and
ends at the end of the line, then the next line starts off not being a
comment until the /* ... */ style comment which is AFTER the semi-colon.

If neither myself nor whoever posted the example had referred to C99
then you would have been correct in thinking that there was a missing
semicolon.

>              -1 + 1;   /* 0 in C99, 1 in C++ */
               ^^^^^^^ not commented out because // comment ended at end
of last line.
> }

I'm sure that Dan or one of the others who know the C standards better
than me would have corrected me if I was wrong. They have certainly
corrected me in the past when I made mistakes and I definitely want them
to continue to point out anything I get wrong.
-- 
Mark Gordon
Paid to be a Geek & a Senior Software Developer
Although my email address says spamtrap, it is real and I read it.
0
spamtrap606 (150)
10/16/2003 11:02:49 PM
"cody" <dont.spam.me.deutronium@gmx.de> wrote:
<snip>
>
>       return 1 //*          <-- the c version misses a semicolon here,
>additionally //* will imho produce no valid comment in c.
>
>             -1 + 1;   /* 0 in C99, 1 in C++ */
>}

In C90:  //*  will be tokenized as 
         /    (division operator) followed by 
         /*   (comment start)

In C99:  //*  will be tokenized as
         //   (single line comment start)

Thus, after stripping the comments and newlines

       return 1 //* 
             -1 + 1;  /* ... */

in C90 results in:

       return 1 /

but in C99 results in:
 
       return 1 -1 + 1;

Regards
-- 
Irrwahn 
(irrwahn33@freenet.de)
0
irrwahn33 (608)
10/16/2003 11:14:54 PM
"cody" <dont.spam.me.deutronium@gmx.de> wrote:
<snip>
>What is a sig-monster?

I am a <insert your favourite attribute here> one.  Groooarrrchrr.
-- 
Three is no spimle sbtsuuttie for cearful, cercrot, 
wtlirtew-len Esglinh. Tehre is no slveir beullt.

 - Rhacrid Hfiaehlted in comp.programming, 2003-09-25
0
irrwahn33 (608)
10/16/2003 11:14:55 PM
"Brian Inglis" <Brian.Inglis@SystematicSw.ab.ca> wrote in message
news:41ssovg05n4knsfs06o86nepi2qj2nn8lk@4ax.com...
> >>     An integer character constant is a sequence of one or more
> >>     multibyte characters enclosed in single-quotes, as in 'x'.
> >Was is the same in other versions of C besides C99?
>
> As far back as K&R1 -- common C idiom was 'ab' (16 bit) or 'abcd'
> (32 bit) to handle packed chars -- undefined behaviour as of C89
> -- but still allowed and works?

Not undefined, implementation-defined in both C89 and C99.

    Dennis


0
dmr (16)
10/17/2003 12:53:31 AM
cody wrote:

>> > int i = sizeof (int);
>> > // int j = sizeof int; // invalid in both C and C++
>> > int k = sizeof i;
>> > int l = sizeof (i);
>> >
>> > The form of sizeof that gets a type as parameter has to use
>> > parantheses, while the sizeof that gets non-expressions as parameter do
>> > not need
> them.
>>
>> Wrong. In your example, i is an unary-expression, not a non-expression.
> 
> I don't know why i wrote non-expression. My example clearly showed how to
> use sizeof:

It's improving, but still not quite there. You should really use size_t 
rather than int here, and note that // comments are valid in C99 but /not/ 
in C90, and most of the world is still using C90, so they are best avoided, 
at least for now.


> The form of sizeof that gets a type (NON-EXPRESSION) as parameter has to
> use parantheses,
> while the sizeof that gets expressions (NON-TYPES) as parameter do not
> need them.
> 
> Is it now correctly stated?

Why make up a description? Why not just say:

3.3.3.4 The sizeof operator

Constraints

   The sizeof operator shall not be applied to an expression that has
function type or an incomplete type, to the parenthesized name of such
a type, or to an lvalue that designates a bit-field object.

Semantics

   The sizeof operator yields the size (in bytes) of its operand,
which may be an expression or the parenthesized name of a type.  The
size is determined from the type of the operand, which is not itself
evaluated.  The result is an integer constant.

-- 
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
0
dontmail (1886)
10/17/2003 4:42:27 AM
cody wrote:

> What is a sig-monster?

http://www.google.com/search?q=sig-monster

/Sven ;)

PS: No offence intended, but you should really start using stuff like 
books and search engines. It makes your life far easier!

-- 
Remove "-usenet" from the email address to contact me.
0
10/17/2003 8:03:08 AM
Mark Gordon <spamtrap@flash-gordon.me.uk> wrote:
<snip>
>
>   In certain unusual situations, code could have different semantics
>   for C90 and C9X. for example
>
>      a = b //*divisor:*/ c
>      + d;
>
>   In C90 this was equivalent to
>
>      a = b  c + d;
ITYM:
       a = b / c + d;

I had a spare slash, so I thought I just place it in the gap  :)

>
>   but in C9X it is equivalent to
>
>      a = b + d;
>
<snip>

Regards
-- 
Irrwahn 
(irrwahn33@freenet.de)
0
irrwahn33 (608)
10/17/2003 9:42:51 AM
"cody" <dont.spam.me.deutronium@gmx.de> wrote in message news:<bmn482$ogdds$1@ID-176797.news.uni-berlin.de>...
> "Mark Gordon" <spamtrap@flash-gordon.me.uk> schrieb im Newsbeitrag
> news:20031015232209.128f9a60.spamtrap@flash-gordon.me.uk...
....
> > HINT: C99 added a form of // commenting.
> 
> 
> int test(int size)
> {
>        int *new = malloc(size);  /* two non-C++isms in this line */
> 
>        return 1 //*          <-- the c version misses a semicolon here,
> additionally //* will imho produce no valid comment in c.
> 
>              -1 + 1;   /* 0 in C99, 1 in C++ */
> }

You would be correct in C89, but not in C99 (see section 6.4.9). Did
you think that Mark Gordon was lying with his hint? Did you even
bother to check?

Both C99 and C++ recognise // comments, and the rules for handling
them are similar. In both languages, after comments have been removed,
your example code would look like:

int test(int size)
{
       int *new = malloc(size);

       return 1 
additionally

             -1 + 1;
}
In both languages, the word "additionally" is a syntax error, so I
suspect it was typo, or maybe an artifact of your lines getting
wrapped at the wrong location. In both languages, the absence of a
#include of a standard header file means that there's no prototype in
scope for your call to malloc(), which presents a problem in either
language (though the nature of the problem is slightly different in
each case).

Assuming that you add a line which says

#include <stdlib.h>

and move the "additionally" so that it's inside a comment, the code
still has a syntax error as far as C++ is concerned, because 'new' is
a keyword. However, both languages see a 'return' statement that is
correctly terminated by a ';', and the value returned would be 1, if
it weren't for the other problems.
0
kuyper5 (433)
10/17/2003 4:59:14 PM
On Fri, 17 Oct 2003 11:42:51 +0200
Irrwahn Grausewitz <irrwahn33@freenet.de> wrote:

> Mark Gordon <spamtrap@flash-gordon.me.uk> wrote:
> <snip>
> >
> >   In certain unusual situations, code could have different semantics
> >   for C90 and C9X. for example
> >
> >      a = b //*divisor:*/ c
> >      + d;
> >
> >   In C90 this was equivalent to
> >
> >      a = b  c + d;
> ITYM:
>        a = b / c + d;
> 
> I had a spare slash, so I thought I just place it in the gap  :)

Damn. I knew I should have bought more slashes when I went shopping last
weekend. :-)

Also proves my point that I would have been corrected if I had made a
mist ook.
-- 
Mark Gordon
Paid to be a Geek & a Senior Software Developer
Although my email address says spamtrap, it is real and I read it.
0
spamtrap606 (150)
10/17/2003 9:21:18 PM
In comp.std.c j <jake30NOSPAM@bellsouth.net> wrote:
[...]
+ I don't know why people mold terms to fit things how they would like to see
+ them.  C++ is not a superset, period. ``strict superset'' throw it out of the
+ window.  When something is a ``superset'' of something else, that something else is
+ considered to be a ``subset''.
+ Now inorder for C to be a subset of C++, you would be able to compile _any_
+ C program with a C++ compiler. This can't be done, because C is not a subset
+ of C++, and that is because C++ is not a superset of C. It is a
+ ``derivative'' of C. Nothing more and nothing less.

C and C++ have a relatively large semantic intersection, i.e., set of
programs to which C and C++ attach identical behavior.  It's my
impession that the intersecton includes the majority of actual C
programs.

Tom Payne

0
thp (42)
10/18/2003 9:27:07 AM
In article <bmr11b$7jf$1@glue.ucr.edu>, thp@cs.ucr.edu wrote:

> C and C++ have a relatively large semantic intersection, i.e., set of
> programs to which C and C++ attach identical behavior.  It's my
> impession that the intersecton includes the majority of actual C
> programs.

I think the majority of actual C programs will not compile as C++ 
programs at all; if the programmer never heard of C++ then it is just 
too easy to have "new", "class" or "template" as an identifier. 

However, the majority of actual C programs can be changed with little 
effort into source code that has identical behavior as C and C++ 
programs. The most annoying difference is having to cast the result of 
malloc in C++, which is considered bad practice in C and necessary in 
C++.
0
10/18/2003 10:28:49 AM
thp@cs.ucr.edu wrote:

>In comp.std.c j <jake30NOSPAM@bellsouth.net> wrote:
>[...]
>+ Now inorder for C to be a subset of C++, you would be able to compile _any_
>+ C program with a C++ compiler. This can't be done, because C is not a subset
>+ of C++, and that is because C++ is not a superset of C. It is a
>+ ``derivative'' of C. Nothing more and nothing less.

Correct. 

>C and C++ have a relatively large semantic intersection, i.e., set of
>programs to which C and C++ attach identical behavior.  It's my
>impession that the intersecton includes the majority of actual C
>programs.

It may be your impression, but if it would be like that in Reality[tm], 
the majority of actual C programs would be bad C programs.
(Well, maybe they _are_, but that's not my point.)

If you don't believe this, feed some production level C code to a C++ 
compiler of your choice, but be prepared to face an army of nasal 
demons.  =%O 

Regards
-- 
Irrwahn 
(irrwahn33@freenet.de)
0
irrwahn33 (608)
10/18/2003 10:50:05 AM
Christian Bau wrote:

> [snip]

> However, the majority of actual C programs can be changed with little 
> effort into source code that has identical behavior as C and C++ 
> programs. The most annoying difference is having to cast the result of 
> malloc in C++, which is considered bad practice in C and necessary in 
> C++.

Why is it considered "bad practice"? I know it is frowned upon 
sometimes, but I fail to see the rationale for that.

One advantage of casting malloc() results is that, like you say, one has 
a fighting chance of getting a clean (error/warning-less) compile using 
C++ in addition to getting a clean compile in C.

For me, compiling a piece of code with as many compilers as I can get my 
hands on (with maximum warning levels) has proven to be a great way of 
catching problems; different compilers give different warnings.

Having one's C program compilable by a C++-compiler also helps, since 
this can sometimes flag potential problems in the C code that are not 
noticed by a C compiler.

Best regards,

   Sidney Cadot

0
sidney (345)
10/18/2003 11:18:17 AM
Sidney Cadot <sidney@jigsaw.nl> wrote:

>Christian Bau wrote:
>
>> [snip]
>
>> However, the majority of actual C programs can be changed with little 
>> effort into source code that has identical behavior as C and C++ 
>> programs. The most annoying difference is having to cast the result of 
>> malloc in C++, which is considered bad practice in C and necessary in 
>> C++.
>
>Why is it considered "bad practice"? I know it is frowned upon 
>sometimes, but I fail to see the rationale for that.

1. You don't need the cast in C.  If you have to cast (e.g. to shut up 
   a compiler warning) you most probably try to do something dangerous. 
   Implicit conversions to/from pointer-to-void from/to any other 
   pointer-to-<type> are explicitly permitted in C.

2. Casting malloc's return value may hide the (admittedly simple to fix)
   error of not providing a proper prototype for malloc.  

>One advantage of casting malloc() results is that, like you say, one has 
>a fighting chance of getting a clean (error/warning-less) compile using 
>C++ in addition to getting a clean compile in C.

If you feel the need to insert spurious casts to make your C code pass a
C++ compiler without complaints, well, just do so, but IMHO this doesn't
make it good coding style.  It is probably feasible to make e.g. Pascal 
programs pass C compilers, but you end up with something that is neither
well written Pascal nor well written C.

>For me, compiling a piece of code with as many compilers as I can get my 
>hands on (with maximum warning levels) has proven to be a great way of 
>catching problems; different compilers give different warnings.

I second that, as long as all these are compilers for the language the 
code is written in.

>Having one's C program compilable by a C++-compiler also helps, since 
>this can sometimes flag potential problems in the C code that are not 
>noticed by a C compiler.

Can you please eloborate on this?
AFAIK now it is possible to write code that compiles fine, but has 
different semantics when compiled as C or C++ respectively.

Regards
-- 
Irrwahn 
(irrwahn33@freenet.de)
0
irrwahn33 (608)
10/18/2003 1:00:11 PM
Hi Irrwahn,

>>> [[casting malloc() result to target type]]
>>
>>Why is it considered "bad practice"? I know it is frowned upon 
>>sometimes, but I fail to see the rationale for that.
> 
> 
> 1. You don't need the cast in C.  If you have to cast (e.g. to shut up 
>    a compiler warning) you most probably try to do something dangerous. 

There are circumstances where it is really needed of course, mostly in 
low-level programming, and reading binary data formats. Casting is bad 
if you just do it to shut down a compiler warning (I've assisted with 
programming practicals at university, for novices this seems to be the 
#1 reason to use casts), so you really have to understand what you're doing.

>    Implicit conversions to/from pointer-to-void from/to any other 
>    pointer-to-<type> are explicitly permitted in C.

I think that is a mistake, and I am not going to drop casts that are not 
needed just because the standard allows me to. I feel my code looks 
prettier with malloc() casts.

> 2. Casting malloc's return value may hide the (admittedly simple to fix)
>    error of not providing a proper prototype for malloc.  

If this is the case, I seriously doubt the quality of the compiler:

/* don't include stdlib.h */
int main(void)
{
   char *x = (char *)malloc(100);
   return 0;
}

The standard doesn't require the compiler to issue a warning of course 
(never does), but I think, the year being AD2003 and all, that a 
good-quality compiler should issue a warning whether the (char *) cast 
is there or not.

/* don't include stdlib.h */
int main(void)
{
   char *x = malloc(100);
   return 0;
}

This version is legal C as well, so a compiler is free to not issue a 
warning. So the only thing that is lost when including the (char *) cast 
is that a compiler that would balk at program #2 might not balk at 
program #1. I think that's a bad-quality compiler, and I think the 
advantage of code that is both legal C and legal C++ outweighs the fact 
that some bad compiler would fail to see the problem in program #1.

> If you feel the need to insert spurious casts to make your C code pass a
> C++ compiler without complaints, well, just do so, but IMHO this doesn't
> make it good coding style.

I'm trying to argue it's not a black-and-white issue.

> It is probably feasible to make e.g. Pascal 
> programs pass C compilers, but you end up with something that is neither
> well written Pascal nor well written C.

Making a caricature of my position surely doesn't help much :-)

>>For me, compiling a piece of code with as many compilers as I can get my 
>>hands on (with maximum warning levels) has proven to be a great way of 
>>catching problems; different compilers give different warnings.
> 
> I second that, as long as all these are compilers for the language the 
> code is written in.

If, with minor hassle, it also passed C++, I think that's worth it, 
given that C++ is (rightly, I think) stricter in some things than C. 
Such as casting void pointers (one can disagree on that) and handling of 
enums (see below).

>>Having one's C program compilable by a C++-compiler also helps, since 
>>this can sometimes flag potential problems in the C code that are not 
>>noticed by a C compiler.

> Can you please eloborate on this?

Example:

#include <stdio.h>
#include <assert.h>
#include <stdlib.h>

enum EType {
   a,b,c
};

void f(enum EType x)
{
   switch(x)
     {
     case a: printf("a\n"); break;
     case b: printf("b\n"); break;
     case c: printf("c\n"); break;
     default: printf("yikes!\n"); exit(1); break;
     }
}

int main(void)
{
   f(b);
   f(1); /* uncasted call */
   return 0;
}

This is a perfectly legal C program as far as I can tell, and it's 
illegal in C++ due to the attempt to implicitly casting 1 to EType.

I think C++ is right to flag this as erroneous, and require a cast.

> AFAIK now it is possible to write code that compiles fine, but has 
> different semantics when compiled as C or C++ respectively.

Sure it is possible. I am, however, advocating writing code that 
complies with the intersection of C and C++, and works as intended. You 
are coming perilously close to putting up a strawman here.

Best regards,

   Sidney Cadot

0
sidney (345)
10/18/2003 3:23:02 PM
Sidney Cadot wrote:
....
> /* don't include stdlib.h */
> int main(void)
> {
>   char *x = malloc(100);
>   return 0;
> }
> 
> This version is legal C as well, so a compiler is free to not issue a 
> warning.

It is not legal C. C99 requires a valid prototype and C89 does not
allow the assignment of int to char *. A diagnostic is *required*.

Jirka

0
jklaue2 (127)
10/18/2003 3:35:32 PM
"Sidney Cadot" <sidney@jigsaw.nl> wrote in message
news:bmrlsm$ar3$1@news.tudelft.nl...
> Hi Irrwahn,
>
> >>> [[casting malloc() result to target type]]
> >>
> >>Why is it considered "bad practice"? I know it is frowned upon
> >>sometimes, but I fail to see the rationale for that.
> >
> >
> > 1. You don't need the cast in C.  If you have to cast (e.g. to shut up
> >    a compiler warning) you most probably try to do something dangerous.
/snip/

Actually, casting the result of malloc() is *good*
programming practice, because it verifies that you
are assigning the result to the pointer-type that
you expect of the target variable.


fubar = (Gronk *) malloc(whatever_size_you_want);


This verifies that "fubar" is declared as a
pointer type to whatever Gronk is. If the
type of "fubar" is not (Gronk *), then the
compiler will complain about the pointer conversion.
The explicit cast clearly documents your intention
and allows the compiler to verify it.

OTOH, without the explicit cast, the compiler
will happily assign the (void*) result to fubar and
you won't know that you did something wrong. (Perhaps
you are assigning the result to the wrong variable?)

Finding burps like this at compile time is far more preferable
than tracking down runtime errors.

2 cents worth. Your mileage may vary.



0
xarax (448)
10/18/2003 3:47:53 PM
Sidney Cadot wrote:
> Christian Bau wrote:
> 
> > [snip]
> 
> > However, the majority of actual C programs can be changed with
> > little effort into source code that has identical behavior as C
> > and C++ programs. The most annoying difference is having to cast
> > the result of malloc in C++, which is considered bad practice in
> > C and necessary in C++.
> 
> Why is it considered "bad practice"? I know it is frowned upon
> sometimes, but I fail to see the rationale for that.
> 
> One advantage of casting malloc() results is that, like you say,
> one has a fighting chance of getting a clean (error/warning-less)
> compile using C++ in addition to getting a clean compile in C.

It can hide errors that the compiler could otherwise pick up.  It
prevents controlling the type of that object in only one place,
and having all other code slaved to that.

Casts are fundamentally evil things, and very often serve only to
conceal errors.

I have yet to see a C++ compiler that does not have a C mode, and
there is no problem linking C++ code with C code when the headers
are properly designed.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!


0
cbfalconer (19194)
10/18/2003 5:02:48 PM
On Sat, 18 Oct 2003, xarax wrote:
>
> "Sidney Cadot" <sidney@jigsaw.nl> wrote...
> >
> > >>> [[casting malloc() result to target type]]
> > >>
> > >>Why is it considered "bad practice"? I know it is frowned upon
> > >>sometimes, but I fail to see the rationale for that.
> > >
> > > 1. You don't need the cast in C.  If you have to cast (e.g. to shut up
> > >    a compiler warning) you most probably try to do something dangerous.
>
> Actually, casting the result of malloc() is *good*
> programming practice, because it verifies that you
> are assigning the result to the pointer-type that
> you expect of the target variable.

That's just silly.  You, as the programmer, already *know* the type
of the target object, correct?  And besides, well-written (i.e.,
idiomatic for c.l.c) malloc calls don't require *any* type information,
correct *or* incorrect -- it lets the compiler handle all the type
information by itself.  Which of the following is most likely to
do the right thing, given that the type of 'p' might be hard to
remember?

    extern Gronk *p;

       p = (Gronk *) malloc(sizeof (Gronk));
       p = (Gronk *) malloc(sizeof *p);
       p = malloc(sizeof (Gronk));
       p = malloc(sizeof *p);


(Hint: the last one.)


> fubar = (Gronk *) malloc(whatever_size_you_want);

Where 'whatever_size_you_want' is an integral multiple of
sizeof *fubar, sure.  But in that case, why bother with the
cast?

> This verifies that "fubar" is declared as a
> pointer type to whatever Gronk is. If the
> type of "fubar" is not (Gronk *), then the
> compiler will complain about the pointer conversion.
> The explicit cast clearly documents your intention
> and allows the compiler to verify it.

True, but IMO not nearly as strong an argument as the "clarity,
brevity, and <stdlib.h> warning" arguments given by proponents
of the idiomatic (non-cast) style.


> OTOH, without the explicit cast, the compiler
> will happily assign the (void*) result to fubar and
> you won't know that you did something wrong. (Perhaps
> you are assigning the result to the wrong variable?)

Do you commonly write code in which two pointers to different
types are in scope at the same time?  Unless you write compilers
for a living (which IMVLE often have pointers to symbol tables and
other things co-existing), I can't think of any context in which

    Foo *my_foo;
    Bar *my_bar;

       my_bar = malloc(sizeof *my_foo);

could ever happen as a legitimate typo/error.  And even if it
*did* happen, it's a fairly easy bug to find, especially now that
the code is made less cluttered by the removal of all those
spurious casts.  Or did you have some other context in mind?


> Finding burps like this at compile time is far more preferable
> than tracking down runtime errors.
>
> 2 cents worth. Your mileage may vary.

MMDIV, as they say.  You write a program with malloc casting that
you think will lose clarity or robustness by their removal, and I will
personally re-write the malloc-casting code to become clearer without
loss of robustness.

-Arthur
0
ajo (1603)
10/18/2003 5:35:17 PM
Sidney Cadot <sidney@jigsaw.nl> wrote:

>Hi Irrwahn,
>
>>>> [[casting malloc() result to target type]]
>>>
>>>Why is it considered "bad practice"? I know it is frowned upon 
>>>sometimes, but I fail to see the rationale for that.
>> 
>> 1. You don't need the cast in C.  If you have to cast (e.g. to shut up 
>>    a compiler warning) you most probably try to do something dangerous. 
>
>There are circumstances where it is really needed of course, mostly in 
>low-level programming, and reading binary data formats. 

The special cases are the reason why I said "most probably" and not 
"certainly".  However, low-level code is unlikely to be pure portable 
ISO-C anyway.

>Casting is bad 
>if you just do it to shut down a compiler warning (I've assisted with 
>programming practicals at university, for novices this seems to be the 
>#1 reason to use casts), so you really have to understand what you're doing.

We both agree on this. 

>>    Implicit conversions to/from pointer-to-void from/to any other 
>>    pointer-to-<type> are explicitly permitted in C.
>
>I think that is a mistake, and I am not going to drop casts that are not 
>needed just because the standard allows me to. 

If you think that C99 6.3.2.3 is a mistake, you should submit a DR or a 
proposal to the standards comittee.  ;-)

>I feel my code looks 
>prettier with malloc() casts.

We couldn't disagree more on this aspect, but it's a style question and 
therefore IMHO not /that/ important.

>> 2. Casting malloc's return value may hide the (admittedly simple to fix)
>>    error of not providing a proper prototype for malloc.  
>
>If this is the case, I seriously doubt the quality of the compiler:
>
>/* don't include stdlib.h */
>int main(void)
>{
>   char *x = (char *)malloc(100);
>   return 0;
>}

warning: implicit declaration of function `malloc'
result:  undefined behaviour; malloc now returns int, but with the cast 
         you told the compiler: shut up, even if otherwise it would be 
         so kind to issue another warning (see below).

>The standard doesn't require the compiler to issue a warning of course 
>(never does), but I think, the year being AD2003 and all, that a 
>good-quality compiler should issue a warning whether the (char *) cast 
>is there or not.

You rely upon the fact that an integer is wide enough to hold a pointer
value.  This holds true for some implementations.  It invokes undefined 
behaviour on others and is therefore dangerous and completely 
unportable.  

>/* don't include stdlib.h */
>int main(void)
>{
>   char *x = malloc(100);
>   return 0;
>}

warning: implicit declaration of function `malloc'
warning: initialization makes pointer from integer without a cast
result:  undefined behaviour

>This version is legal C as well,

Not really.  It invokes undefined behaviour,
> so a compiler is free to not issue a 
>warning. So the only thing that is lost when including the (char *) cast 
>is that a compiler that would balk at program #2 might not balk at 
>program #1. 

Additionally you lost the chance of having well defined behaviour and 
portability.  Congratulations  :^]

>I think that's a bad-quality compiler, and I think the 
>advantage of code that is both legal C and legal C++ outweighs the fact 
>that some bad compiler would fail to see the problem in program #1.

So in your opinion a decent compiler should automagically know that the 
return type of malloc is void *, without being told by a prototype.
I'm not aware of what implementations you have used so far, but I bet 
all of them are bad-quality compilers according to your definition. 
 
>> If you feel the need to insert spurious casts to make your C code pass a
>> C++ compiler without complaints, well, just do so, but IMHO this doesn't
>> make it good coding style.
>
>I'm trying to argue it's not a black-and-white issue.

Well, style isn't, hiding errors IMO is.

>> It is probably feasible to make e.g. Pascal 
>> programs pass C compilers, but you end up with something that is neither
>> well written Pascal nor well written C.
>
>Making a caricature of my position surely doesn't help much :-)

Caricatures have the advantage of exposing certain aspects by hyperbole.
In one sense they are /defined/ that way.  :o)  Here's another one:
A perfectely valid Spanish sentence can also be a perfectly valid 
Portugese sentence, but with a different meaning.  The fact that both 
are somewhat close related languages doens't make them compatible.  
Moral: To order breakfeast using the wrong language can be dangerous.

>>>For me, compiling a piece of code with as many compilers as I can get my 
>>>hands on (with maximum warning levels) has proven to be a great way of 
>>>catching problems; different compilers give different warnings.
>> 
>> I second that, as long as all these are compilers for the language the 
>> code is written in.
>
>If, with minor hassle, it also passed C++, I think that's worth it, 
>given that C++ is (rightly, I think) stricter in some things than C. 
>Such as casting void pointers (one can disagree on that) and handling of 
>enums (see below).

One has to weigh freedom against restriction. ;-)  
If one prefers C++ over C for certain reasons, why not write C++ in the 
first place, instead of breeding a chimera that's neither idiomatic C 
nor idiomatic C++.

>>>Having one's C program compilable by a C++-compiler also helps, since 
>>>this can sometimes flag potential problems in the C code that are not 
>>>noticed by a C compiler.
>
>> Can you please eloborate on this?
>
>Example:
>
>#include <stdio.h>
>#include <assert.h>
>#include <stdlib.h>
>
>enum EType {
>   a,b,c
>};
>
>void f(enum EType x)
>{
>   switch(x)
>     {
>     case a: printf("a\n"); break;
>     case b: printf("b\n"); break;
>     case c: printf("c\n"); break;
>     default: printf("yikes!\n"); exit(1); break;
>     }
>}
>
>int main(void)
>{
>   f(b);
>   f(1); /* uncasted call */
>   return 0;
>}
>
>This is a perfectly legal C program as far as I can tell, and it's 
>illegal in C++ due to the attempt to implicitly casting 1 to EType.
>
>I think C++ is right to flag this as erroneous, and require a cast.

Hm, "right" depends of ones POV in this case.  The C standard does not
require a diagnostic, so it is wrong? I don't think so.  However, this
leaves us with the last issue:

>> AFAIK now it is possible to write code that compiles fine, but has 
>> different semantics when compiled as C or C++ respectively.
>
>Sure it is possible. I am, however, advocating writing code that 
>complies with the intersection of C and C++, and works as intended. You 
>are coming perilously close to putting up a strawman here.

Am I?  Then please tell me where the common subset of C and C++ is 
defined, so I have something to make my code comply to, just in case I 
want to code the same way you do; is it different for C89 compared to 
C99?  Please give a reference.  Now who was how close to putting up a 
strawman?  ;-P 

Regards, and have a nice weekend.
-- 
Irrwahn 
(irrwahn33@freenet.de)
0
irrwahn33 (608)
10/18/2003 5:56:56 PM
xarax wrote:

> Actually, casting the result of malloc() is *good*
> programming practice, because it verifies that you
> are assigning the result to the pointer-type that
> you expect of the target variable.
> 
> 
> fubar = (Gronk *) malloc(whatever_size_you_want);
> 
> 
> This verifies that "fubar" is declared as a
> pointer type to whatever Gronk is.

It allows the compiler to suppress a possibly vital diagnostic. In any 
event, if fubar isn't a Gronk *, then you're bound to find out fairly soon, 
because lots of other stuff isn't going to compile.

What do you think of this code?

#include <stdio.h>

int main(void)
{
  int i;
  double d = (double)3.14;
  i = (int)6;
  (int)printf("%d %f\n", (int)i, (double)d);
  return (int)0;
}

-- 
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
0
dontmail (1886)
10/18/2003 6:03:47 PM
Jirka Klaue wrote:

> Sidney Cadot wrote:
> ...
> 
>> /* don't include stdlib.h */
>> int main(void)
>> {
>>   char *x = malloc(100);
>>   return 0;
>> }
>>
>> This version is legal C as well, so a compiler is free to not issue a 
>> warning.
> 
> It is not legal C. C99 requires a valid prototype and C89 does not
> allow the assignment of int to char *. A diagnostic is *required*.

I stand corrected.

Could anybody point me to the last C89 draft standard that is publicly 
available on the web? I have "n869.pdf" sitting on my HD for C99 which 
is pretty useful and I would also like a similar document for C89.

If only to prevent silly mistakes like this.

Best regards,

   Sidney Cadot

0
sidney (345)
10/18/2003 6:36:09 PM
CBFalconer wrote:

 > [[ casting malloc() results ]]

>>Why is it considered "bad practice"? I know it is frowned upon
>>sometimes, but I fail to see the rationale for that.
>>
>>One advantage of casting malloc() results is that, like you say,
>>one has a fighting chance of getting a clean (error/warning-less)
>>compile using C++ in addition to getting a clean compile in C.

> It can hide errors that the compiler could otherwise pick up. It
> prevents controlling the type of that object in only one place,
> and having all other code slaved to that.

Could you provide examples? I'm sure there are, but it's a lot easier to 
discuss this over an example for me.

> Casts are fundamentally evil things, and very often serve only to
> conceal errors.

'fundamentally evil things' ... that's a bit harsh isn't it?

It would make an interesting exercise to write low-level C code (e.g., 
kernels or device drivers), without casts. Are you suggesting this is 
practical?

> I have yet to see a C++ compiler that does not have a C mode, and
> there is no problem linking C++ code with C code when the headers
> are properly designed.

Sure, but I want to write C code, but sometimes compile the program with 
a C++ compiler to use the extra checks as required by a C++ compiler, 
for flagging potential problems - is that so strange?

Best regards,

   Sidney Cadot

0
sidney (345)
10/18/2003 6:50:53 PM
Irrwahn Grausewitz wrote:

>>>   Implicit conversions to/from pointer-to-void from/to any other 
>>>   pointer-to-<type> are explicitly permitted in C.
>>
>>I think that is a mistake, and I am not going to drop casts that are not 
>>needed just because the standard allows me to. 
> 
> If you think that C99 6.3.2.3 is a mistake, you should submit a DR or a 
> proposal to the standards comittee.  ;-)

Perhaps I should do that! And hopefully I could convince them to retract 
support for those butt-ugly // comments as well :-)

>>I feel my code looks prettier with malloc() casts.

> We couldn't disagree more on this aspect, but it's a style question and 
> therefore IMHO not /that/ important.

Yes.

>>>2. Casting malloc's return value may hide the (admittedly simple to fix)
>>>   error of not providing a proper prototype for malloc.  
>>
>>If this is the case, I seriously doubt the quality of the compiler:
>>
>>/* don't include stdlib.h */
>>int main(void)
>>{
>>  char *x = (char *)malloc(100);
>>  return 0;
>>}
> 
> 
> warning: implicit declaration of function `malloc'
> result:  undefined behaviour; malloc now returns int, but with the cast 
>          you told the compiler: shut up, even if otherwise it would be 
>          so kind to issue another warning (see below).

Undefined behavior: for sure, but we're discussing compile-time behavior 
now.

My point is that a decent modern compiler will warn on the implicit 
declaration of malloc() anyway, with an appropriate warning level.

>>The standard doesn't require the compiler to issue a warning of course 
>>(never does), but I think, the year being AD2003 and all, that a 
>>good-quality compiler should issue a warning whether the (char *) cast 
>>is there or not.
> 
> You rely upon the fact that an integer is wide enough to hold a pointer
> value.  This holds true for some implementations.  It invokes undefined 
> behaviour on others and is therefore dangerous and completely 
> unportable.  

Exactly. For clearness: I'm not advocating leaving out the "#include 
<stdlib.h>" here; we're discussing the compile-time consequences of 
forgetting this, when casting or not casting the result of a malloc().

>>/* don't include stdlib.h */
>>int main(void)
>>{
>>  char *x = malloc(100);
>>  return 0;
>>}
> 
> 
> warning: implicit declaration of function `malloc'
> warning: initialization makes pointer from integer without a cast
> result:  undefined behaviour
> 
> 
>>This version is legal C as well,
> 
> 
> Not really.

So it was brought to my attention. I'm talking C89 here (in C99 you will 
get an error anyway for lack of a prototype); what I meant to say is 
that this is compilable under C89, possible without a warning. What I 
didn't realize is that this will emit a required diagnostic 
(pointer-to-int conversion).

 >>It invokes undefined behaviour, so a compiler is free to not issue a
>>warning. So the only thing that is lost when including the (char *) cast 
>>is that a compiler that would balk at program #2 might not balk at 
>>program #1. 
> 
> Additionally you lost the chance of having well defined behaviour and 
> portability.  Congratulations  :^]

Again, I'm not advocating leaving out #include <stdlib.h> ; we're just 
comparing compile-time behavior for different malloc() handling.

>>I think that's a bad-quality compiler, and I think the 
>>advantage of code that is both legal C and legal C++ outweighs the fact 
>>that some bad compiler would fail to see the problem in program #1.
> 
> So in your opinion a decent compiler should automagically know that the 
> return type of malloc is void *, without being told by a prototype.

No, that's not what I said. My opinion is this: A decent C89 compiler 
should be able to warn on non-prototyped functions being used, even 
though C89 allows it.

> I'm not aware of what implementations you have used so far, but I bet 
> all of them are bad-quality compilers according to your definition. 

.... You misunderstood my definition. All compilers I've used are able to 
warn on non-prototyped function usage.

> [snipped a small bit...]

>>>It is probably feasible to make e.g. Pascal 
>>>programs pass C compilers, but you end up with something that is neither
>>>well written Pascal nor well written C.
>>
>>Making a caricature of my position surely doesn't help much :-)
> 
> Caricatures have the advantage of exposing certain aspects by hyperbole.
> In one sense they are /defined/ that way.  :o)  

Chapter and verse? :-)

 > Here's another one:
> A perfectely valid Spanish sentence can also be a perfectly valid 
> Portugese sentence, but with a different meaning.  The fact that both 
> are somewhat close related languages doens't make them compatible.  

....Now suppose you have a machine that understands Spanish, and a 
machine that understands Portugese. Both machines warn on incorrect 
syntax and grammer in their respectively understood languages. Let's 
also assume (to make the metaphor a bit more realistic) that Portugese 
descends from Spanish, adding a few grammatic constructs, and that most 
Spanish sentences (except from contrived examples) are also correct 
Portugese (though not the other way round). Finally, let's assume 
Portugese is a lot stricter concerning grammatical constructs; some 
sentences that are legal Spanish but often lead to problems are 
incorrect in Portugese.

Now we have a valid metaphor. I'm advocating that, if you try to write 
problem-free Spanish, using both machines instead of just the Spanish 
one can be of help.

> If one prefers C++ over C for certain reasons, why not write C++ in the 
> first place, instead of breeding a chimera that's neither idiomatic C 
> nor idiomatic C++.

I would kindly refer you to my reply to Cody's questions of 5 october. I 
prefer C for many reasons, but I also recognise that C++ aims to fix 
some problems in C. I'm aiming for the 'best of both worlds' approach.

>>>>Having one's C program compilable by a C++-compiler also helps, since 
>>>>this can sometimes flag potential problems in the C code that are not 
>>>>noticed by a C compiler.
>>
>>>Can you please eloborate on this?
>>
>>Example:
>>
>>#include <stdio.h>
>>#include <assert.h>
>>#include <stdlib.h>
>>
>>enum EType {
>>  a,b,c
>>};
>>
>>void f(enum EType x)
>>{
>>  switch(x)
>>    {
>>    case a: printf("a\n"); break;
>>    case b: printf("b\n"); break;
>>    case c: printf("c\n"); break;
>>    default: printf("yikes!\n"); exit(1); break;
>>    }
>>}
>>
>>int main(void)
>>{
>>  f(b);
>>  f(1); /* uncasted call */
>>  return 0;
>>}
>>
>>This is a perfectly legal C program as far as I can tell, and it's 
>>illegal in C++ due to the attempt to implicitly casting 1 to EType.
>>
>>I think C++ is right to flag this as erroneous, and require a cast.
> 
> Hm, "right" depends of ones POV in this case.  The C standard does not
> require a diagnostic, so it is wrong? I don't think so.

It's not wrong from the C standard's point-of-view, but then I feel the 
C standard is wrong in this respect. The rationale for allowing implicit 
int-to-enum conversion at the time was undoubtedly the desire to not 
break existing code, but as far as I am concerned the time has come to 
leave this behind for new code.

>>>AFAIK now it is possible to write code that compiles fine, but has 
>>>different semantics when compiled as C or C++ respectively.
>>
>>Sure it is possible. I am, however, advocating writing code that 
>>complies with the intersection of C and C++, and works as intended. You 
>>are coming perilously close to putting up a strawman here.
> 
> 
> Am I?  Then please tell me where the common subset of C and C++ is 
> defined, so I have something to make my code comply to, just in case I 
> want to code the same way you do; is it different for C89 compared to 
> C99?  Please give a reference.

What's so strange about the concept of the intersection of two related 
languages for which standards exists? Now I'm quite willing to explain 
what an intersection is and to provide pointers to the relevant 
standards, but you will first have to explain to me what's so hard to 
understand :-)

 >  Now who was how close to putting up a strawman?  ;-P

I think you were (I'm trying hard to avoid it), but I am happy to see 
that we can resolve this without erecting, much less burning, any straw 
men.

> Regards, and have a nice weekend.

You too. I mean, what could be more fun than arguing coding style on 
Saturday evening!

   Sidney Cadot

0
sidney (345)
10/18/2003 7:43:00 PM
"Arthur J. O'Dwyer" <ajo@nospam.andrew.cmu.edu> wrote in message
news:Pine.LNX.4.58-035.0310181313360.11449@unix42.andrew.cmu.edu...

> > Actually, casting the result of malloc() is *good*
> > programming practice, because it verifies that you
> > are assigning the result to the pointer-type that
> > you expect of the target variable.
>
> That's just silly.

I don't mind your having your own style, but I do bridle at your
cavalier dismissal of a different one. You're just being parochial
and short sighted (if you enjoy name calling).

>                   You, as the programmer, already *know* the type
> of the target object, correct?

Not for long. Over time, there can be drift between the type of the
object you're trying to allocate and the type of the pointer object
where you want to store the address of the allocation. Once you get
in the habit of maintaining code that's decades old, you learn
where best to take out insurance. (Hint: insurance against a failure
to include <stdlib.h> is pretty short term, by comparison.)

>                                  And besides, well-written (i.e.,
> idiomatic for c.l.c) malloc calls don't require *any* type information,
> correct *or* incorrect -- it lets the compiler handle all the type
> information by itself.

I agree you don't have to write the cast -- we did that intentionally,
for backward compatibility, when we added void * to Standard C. I
disagree that omitting the cast automatically makes for well written
code. That's just one idiom, not always the best one in all
circumstances.

>                        Which of the following is most likely to
> do the right thing, given that the type of 'p' might be hard to
> remember?
>
>     extern Gronk *p;
>
>        p = (Gronk *) malloc(sizeof (Gronk));
>        p = (Gronk *) malloc(sizeof *p);
>        p = malloc(sizeof (Gronk));
>        p = malloc(sizeof *p);
>
>
> (Hint: the last one.)

None of the above. I strongly prefer:

        p = (Gronk *) malloc(N * sizeof (Gronk));

even when N is an explicit 1. (Though I do eliminate the sizeof
when the type is demonstrably a char type.)

> > fubar = (Gronk *) malloc(whatever_size_you_want);
>
> Where 'whatever_size_you_want' is an integral multiple of
> sizeof *fubar, sure.

Sure? How can you be sure when reviewing the code after some
other maintainer has fiddled with the declaration of Gronk?
How much searching will it take you to become sure again? And
what if you decide to just trust that the size is properly
constrained?

>                     But in that case, why bother with the
> cast?

To spend less time hunting bugs during maintenance?

> > This verifies that "fubar" is declared as a
> > pointer type to whatever Gronk is. If the
> > type of "fubar" is not (Gronk *), then the
> > compiler will complain about the pointer conversion.
> > The explicit cast clearly documents your intention
> > and allows the compiler to verify it.
>
> True, but IMO not nearly as strong an argument as the "clarity,
> brevity, and <stdlib.h> warning" arguments given by proponents
> of the idiomatic (non-cast) style.

Fine, that's just YO. Doesn't make everybody else silly.

> > OTOH, without the explicit cast, the compiler
> > will happily assign the (void*) result to fubar and
> > you won't know that you did something wrong. (Perhaps
> > you are assigning the result to the wrong variable?)
>
> Do you commonly write code in which two pointers to different
> types are in scope at the same time?

Yep, all the time.

>                                     Unless you write compilers
> for a living (which IMVLE often have pointers to symbol tables and
> other things co-existing), I can't think of any context in which
>
>     Foo *my_foo;
>     Bar *my_bar;
>
>        my_bar = malloc(sizeof *my_foo);
>
> could ever happen as a legitimate typo/error.  And even if it
> *did* happen, it's a fairly easy bug to find, especially now that
> the code is made less cluttered by the removal of all those
> spurious casts.  Or did you have some other context in mind?

Glad you think so. I'm a firm believer in natural selection.

> > Finding burps like this at compile time is far more preferable
> > than tracking down runtime errors.
> >
> > 2 cents worth. Your mileage may vary.
>
> MMDIV, as they say.  You write a program with malloc casting that
> you think will lose clarity or robustness by their removal, and I will
> personally re-write the malloc-casting code to become clearer without
> loss of robustness.

Feel free. FWIW, I used your style for over 20 years, including a decade
after I added void * to my compiler. Then one day, about ten years ago,
I sat down and added casts to every blessed malloc call in my living code
base. And I've never been sorry. A more curious person might wonder why.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com


0
pjp (713)
10/18/2003 7:56:35 PM
"Irrwahn Grausewitz" <irrwahn33@freenet.de> wrote in message
news:v1r2pvkarftoo4bfbug2ioumi03lrl61s9@4ax.com...

> >> 1. You don't need the cast in C.  If you have to cast (e.g. to shut up
> >>    a compiler warning) you most probably try to do something dangerous.
> >
> >There are circumstances where it is really needed of course, mostly in
> >low-level programming, and reading binary data formats.
>
> The special cases are the reason why I said "most probably" and not
> "certainly".  However, low-level code is unlikely to be pure portable
> ISO-C anyway.

Gee, I just counted a couple of hundred casts in our C code, which runs
on a dozen or more platforms. I'd estimate that only a few per cent of
them could safely be removed, including the malloc ones. I agree that
casts can be dangerous, so I only write them when I think they serve
a good purpose. In the cases I just counted, almost all are needed to
*ensure* portability. Go figure.

> >Casting is bad
> >if you just do it to shut down a compiler warning (I've assisted with
> >programming practicals at university, for novices this seems to be the
> >#1 reason to use casts), so you really have to understand what you're doing.
>
> We both agree on this.

I'd like to agree, but we also add casts to our code to silence compiler
warnings that are silly. (Why do some compilers complain about -x, where
x is unsigned, but say nothing about 0-x?) Our customers do *not* want
warning messages from our code, no matter how much we assure them that
we know what we're doing.

> >>    Implicit conversions to/from pointer-to-void from/to any other
> >>    pointer-to-<type> are explicitly permitted in C.
> >
> >I think that is a mistake, and I am not going to drop casts that are not
> >needed just because the standard allows me to.
>
> If you think that C99 6.3.2.3 is a mistake, you should submit a DR or a
> proposal to the standards comittee.  ;-)

You may not like it, but it *was* intentional.

> .....
>
> One has to weigh freedom against restriction. ;-)
> If one prefers C++ over C for certain reasons, why not write C++ in the
> first place, instead of breeding a chimera that's neither idiomatic C
> nor idiomatic C++.

Because it's idiomatic common subset, and superior for both purposes?

> .....
>
> >> AFAIK now it is possible to write code that compiles fine, but has
> >> different semantics when compiled as C or C++ respectively.
> >
> >Sure it is possible. I am, however, advocating writing code that
> >complies with the intersection of C and C++, and works as intended. You
> >are coming perilously close to putting up a strawman here.
>
> Am I?  Then please tell me where the common subset of C and C++ is
> defined, so I have something to make my code comply to, just in case I
> want to code the same way you do; is it different for C89 compared to
> C99?  Please give a reference.  Now who was how close to putting up a
> strawman?  ;-P

You are. You don't want to code in the common subset, don't. If you want
to learn how to write code that works the same way when compiled as C89,
C99, and C++, it ain't that hard. I feel no obligation to help educate
you, however.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com


0
pjp (713)
10/18/2003 8:13:58 PM
Sidney Cadot wrote:
> CBFalconer wrote:
> 
>  > [[ casting malloc() results ]]
> 
> >> Why is it considered "bad practice"? I know it is frowned upon
> >> sometimes, but I fail to see the rationale for that.
> >>
> >> One advantage of casting malloc() results is that, like you say,
> >> one has a fighting chance of getting a clean (error/warning-less)
> >> compile using C++ in addition to getting a clean compile in C.
> 
> > It can hide errors that the compiler could otherwise pick up. It
> > prevents controlling the type of that object in only one place,
> > and having all other code slaved to that.
> 
> Could you provide examples? I'm sure there are, but it's a lot easier to
> discuss this over an example for me.

typedef struct foo {
   ....
   } foo, *foop;
.....
foop barp;
.....
barp = malloc(count * sizeof *barp)

(which you can handle slighly differently if you don't approve of
typedefing structures.) At any rate, I can control what a foo (and
a foop) is in just one place, without needing to alter any other
code.  I can also hide that definition in one module and export
only the foop type by slight changes in the declaration method. 
Again, the rest of the code does not change.

> 
> > Casts are fundamentally evil things, and very often serve only to
> > conceal errors.
> 
> 'fundamentally evil things' ... that's a bit harsh isn't it?
> 
> It would make an interesting exercise to write low-level C code (e.g.,
> kernels or device drivers), without casts. Are you suggesting this is
> practical?

Certainly there are places where casts are needed.  But they
should never be used without a clear understanding of their
purpose.  "shutting up compiler complaints" is not a valid
reason.  Code written without casts is much more likely to be
bugfree.

> 
> > I have yet to see a C++ compiler that does not have a C mode, and
> > there is no problem linking C++ code with C code when the headers
> > are properly designed.
> 
> Sure, but I want to write C code, but sometimes compile the program with
> a C++ compiler to use the extra checks as required by a C++ compiler,
> for flagging potential problems - is that so strange?

That is what lint, pclint, splint (nee lclint) are for.  splint is
also free.  They are all much more picky than some nebulous C++
compiler, which is written for a different standard.

Please do not strip attributions for quoted material.  I think you
stripped yourself in this case, but am not sure.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

0
cbfalconer (19194)
10/18/2003 8:15:26 PM
On Sat, 18 Oct 2003 09:27:07 +0000 (UTC), thp@cs.ucr.edu wrote:
>C and C++ have a relatively large semantic intersection, i.e., set of
>programs to which C and C++ attach identical behavior.

The one does not follow from the other.

>  It's my
>impession that the intersecton includes the majority of actual C
>programs.

#define true	(1/(sizeof 'a' - 1))


-- 
#include <standard.disclaimer>
 _
Kevin D Quitt  USA 91387-4454         96.37% of all statistics are made up
  Per the FCA, this address may not be added to any commercial mail list
0
10/18/2003 8:57:56 PM
CBFalconer wrote:

> Sidney Cadot wrote:
> 
>>CBFalconer wrote:
>>
>> > [[ casting malloc() results ]]
>>
>>
>>>>Why is it considered "bad practice"? I know it is frowned upon
>>>>sometimes, but I fail to see the rationale for that.
>>>>
>>>>One advantage of casting malloc() results is that, like you say,
>>>>one has a fighting chance of getting a clean (error/warning-less)
>>>>compile using C++ in addition to getting a clean compile in C.
>>
>>>It can hide errors that the compiler could otherwise pick up. It
>>>prevents controlling the type of that object in only one place,
>>>and having all other code slaved to that.
>>
>>Could you provide examples? I'm sure there are, but it's a lot easier to
>>discuss this over an example for me.
> 
> 
> typedef struct foo {
>    ....
>    } foo, *foop;
> ....
> foop barp;
> ....
> barp = malloc(count * sizeof *barp)
> 
> (which you can handle slighly differently if you don't approve of
> typedefing structures.) At any rate, I can control what a foo (and
> a foop) is in just one place, without needing to alter any other
> code.  I can also hide that definition in one module and export
> only the foop type by slight changes in the declaration method. 
> Again, the rest of the code does not change.

How does all this keep you from writing this:

{
   foop barp;
   barp = (foop)malloc(count * sizeof *barp);
}

Only a name change of foop would be a slight hassle I think? I don't 
quite see what changing the definition of the foo struct has to do with 
casting the malloc result.

>>>Casts are fundamentally evil things, and very often serve only to
>>>conceal errors.
>>
>>'fundamentally evil things' ... that's a bit harsh isn't it?
>>
>>It would make an interesting exercise to write low-level C code (e.g.,
>>kernels or device drivers), without casts. Are you suggesting this is
>>practical?
> 
> 
> Certainly there are places where casts are needed.  But they
> should never be used without a clear understanding of their
> purpose.  "shutting up compiler complaints" is not a valid
> reason.

I agree insofar as that a compiler warning is an indication (symptom) of 
an actual or potential problem, and that you should take care to solve 
the problem instead of just curing the symptom.

As to whether "shutting up compiler complaints" is not a valid reason, 
ever, I would hesitate to make this a dogma.

 > Code written without casts is much more likely to be bugfree.

Sure, but that's also in large part because the type of code that really 
*needs* casts tends to solve complicated problems.

>>>I have yet to see a C++ compiler that does not have a C mode, and
>>>there is no problem linking C++ code with C code when the headers
>>>are properly designed.
>>
>>Sure, but I want to write C code, but sometimes compile the program with
>>a C++ compiler to use the extra checks as required by a C++ compiler,
>>for flagging potential problems - is that so strange?
> 
> That is what lint, pclint, splint (nee lclint) are for.  splint is
> also free.  They are all much more picky than some nebulous C++
> compiler, which is written for a different standard.

What's so nebulous about a C++ compiler? These pick up some of my 
mistakes that a C compiler misses, it works for me. I'm sure the *lints 
are nice tools as well. Have heard some good and bad things about them, 
must try for myself one of these days.

As long as they have a flag for not complaining about malloc result 
casts ... ;-)

> Please do not strip attributions for quoted material.  I think you
> stripped yourself in this case, but am not sure.

Sorry about that.

Best regards,

  Sidney Cadot

0
sidney (345)
10/18/2003 9:04:51 PM
Kevin D. Quitt wrote:

> On Sat, 18 Oct 2003 09:27:07 +0000 (UTC), thp@cs.ucr.edu wrote:
> 
>>  It's my
>>impession that the intersecton includes the majority of actual C
>>programs.
> 
> #define true  (1/(sizeof 'a' - 1))

Um, this resolves to 1/0 in C++, and either 1/0 or 0 in C. None of these 
values is typically associated with the concept of truth in either C or 
C++. :-)

-- 
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
0
dontmail (1886)
10/18/2003 9:06:37 PM
Kevin D. Quitt <KQuitt.MUNG_@IEEInc.MUNG.com> writes:
> On Sat, 18 Oct 2003 09:27:07 +0000 (UTC), thp@cs.ucr.edu wrote:
> >C and C++ have a relatively large semantic intersection, i.e., set of
> >programs to which C and C++ attach identical behavior.
> 
> The one does not follow from the other.

What doesn't follow from what?  I think Kevin is defining the term
"semantic intersection".

> >  It's my
> >impession that the intersecton includes the majority of actual C
> >programs.
> 
> #define true	(1/(sizeof 'a' - 1))

I'm reasonably sure that the majority of actual C programs do not
contain that macro definition.

I'm also reasonably sure that the majority of actual C programs do not
apply the sizeof operator to a character constant.

I haven't tried compiling a large body of C programs with a C++
compiler, but I'd guess that one of the most common sources of
incompatibility is calls to malloc() with no cast (legal and strongly
recommended in C, illegal in C++).  Use of C++ keywords as identifiers
is probably less common, though it's certainly an issue.

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
0
kst (247)
10/18/2003 9:36:47 PM
On Sat, 18 Oct 2003 13:18:17 +0200, in comp.lang.c , Sidney Cadot
<sidney@jigsaw.nl> wrote:

>Christian Bau wrote:
>
>> [snip]
>
>> However, the majority of actual C programs can be changed with little 
>> effort into source code that has identical behavior as C and C++ 
>> programs. The most annoying difference is having to cast the result of 
>> malloc in C++, which is considered bad practice in C and necessary in 
>> C++.
>
>Why is it considered "bad practice"? I know it is frowned upon 
>sometimes, but I fail to see the rationale for that.

The function of a cast is to silence a compiler warning. Thats not a
good idea, generally. Its easy to get carried away with them.

>One advantage of casting malloc() results is that, like you say, one has 
>a fighting chance of getting a clean (error/warning-less) compile using 
>C++ in addition to getting a clean compile in C.

Clean in the sense of "doesn't warn about errors", yes. And this is
good because? 

>For me, compiling a piece of code with as many compilers as I can get my 
>hands on (with maximum warning levels) has proven to be a great way of 
>catching problems; different compilers give different warnings.

Indeed.

>Having one's C program compilable by a C++-compiler also helps, since 
>this can sometimes flag potential problems in the C code that are not 
>noticed by a C compiler.

Thats a QOI issue. Get a better C compiler. 


-- 
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
0
markmcintyre (4555)
10/18/2003 10:12:08 PM
On Sat, 18 Oct 2003 17:23:02 +0200, in comp.lang.c , Sidney Cadot
<sidney@jigsaw.nl> wrote:

>and I am not going to drop casts that are not  needed 
>just because the standard allows me to. I feel my code looks 
>prettier with malloc() casts.

what, you think this looks prettier
	foo = (struct myweirdstruct*) malloc( sizeof (myweirdstruct));
than 
	foo = malloc (sizeof *foo);
???????

>> 2. Casting malloc's return value may hide the (admittedly simple to fix)
>>    error of not providing a proper prototype for malloc.  
>
>If this is the case, I seriously doubt the quality of the compiler:

Many compilers only *warn* about implicit function declarations on
their default warning level. My "many" I mean "pretty much all the
popular ones"

>The standard doesn't require the compiler to issue a warning of course 
>(never does), but I think, the year being AD2003 and all, that a 
>good-quality compiler should issue a warning whether the (char *) cast 
>is there or not.

A warning is typically not a compilation halting operation. Thus
during an automated build, this error might go unnoticed. 

>>>Having one's C program compilable by a C++-compiler also helps, since 
>>>this can sometimes flag potential problems in the C code that are not 
>>>noticed by a C compiler.

<snip enum example claiming ti support this>

>This is a perfectly legal C program as far as I can tell, and it's 
>illegal in C++ due to the attempt to implicitly casting 1 to EType.

but in C, this is not an error. 

>I think C++ is right to flag this as erroneous, and require a cast.

not in C, its not. Remember that enums are not a new type in C,
they're ints. So you are inserting another useless cast, obfuscating
your code slightly for no benefit.


-- 
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
0
markmcintyre (4555)
10/18/2003 10:12:11 PM
On Sat, 18 Oct 2003 21:06:37 +0000 (UTC), in comp.lang.c , Richard
Heathfield <dontmail@address.co.uk.invalid> wrote:

>Kevin D. Quitt wrote:
>
>> On Sat, 18 Oct 2003 09:27:07 +0000 (UTC), thp@cs.ucr.edu wrote:
>> 
>>>  It's my
>>>impession that the intersecton includes the majority of actual C
>>>programs.
>> 
>> #define true  (1/(sizeof 'a' - 1))
>
>Um, this resolves to 1/0 in C++, and either 1/0 or 0 in C. None of these 
>values is typically associated with the concept of truth in either C or 
>C++. :-)

Consider the value of "true" in juxtaposition with the previous
poster's statement. 

-- 
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
0
markmcintyre (4555)
10/18/2003 10:18:24 PM
Mark McIntyre wrote:

 >>[[casting malloc result]]
>>Why is it considered "bad practice"? I know it is frowned upon 
>>sometimes, but I fail to see the rationale for that.
> 
> 
> The function of a cast is to silence a compiler warning. Thats not a
> good idea, generally. Its easy to get carried away with them.

That's a very negative way of putting it. As far as I am concerned, a 
pointer cast is a way of expressing the fact that the compiler-inferred 
type of the object pointed to by a pointer differs from the type that I, 
the programmer, know to be the real type pointed at.

Sometimes the compiler cannot infer the type properly and needs a bit of 
help. I would argue that the malloc() is just such a case.

>>One advantage of casting malloc() results is that, like you say, one has 
>>a fighting chance of getting a clean (error/warning-less) compile using 
>>C++ in addition to getting a clean compile in C.
> 
> Clean in the sense of "doesn't warn about errors", yes. And this is
> good because? 

I don't quite know what 'doesn't warn about errors' could mean, but 
anyway. This is good because I can get my program compiled by the C++ 
compiler and get to an executable that I can run. This is an interesting
exercise, because any behaviorial mismatch between the program as 
produced by the C compiler and by the C++ compiler could point to 
something I have overlooked in the C code.

>>Having one's C program compilable by a C++-compiler also helps, since 
>>this can sometimes flag potential problems in the C code that are not 
>>noticed by a C compiler.
> 
> Thats a QOI issue. Get a better C compiler. 

What C compiler would you recommend, if I want a warning on an integer 
being passed for an enum parameter (as in my example)? Or would you say 
that I am wrong in wanting this? Problems don't disappear by qualifying 
them as QOI.

Best regards,

   Sidney Cadot

0
sidney (345)
10/18/2003 10:43:44 PM
Mark McIntyre wrote:

>>[...] I feel my code looks prettier with malloc() casts.
> 
> what, you think this looks prettier
> 	foo = (struct myweirdstruct*) malloc( sizeof (myweirdstruct));
> than 
> 	foo = malloc (sizeof *foo);
> ???????
> 

Well yes, although I feel

   foo = (struct myweirdstruct *)malloc(sizeof(struct myweirdstruct));

looks prettier still.

>>>2. Casting malloc's return value may hide the (admittedly simple to fix)
>>>   error of not providing a proper prototype for malloc.  
>>
>>If this is the case, I seriously doubt the quality of the compiler:
> 
> 
> Many compilers only *warn* about implicit function declarations on
> their default warning level. My "many" I mean "pretty much all the
> popular ones"

Pretty much all the popular ones also have an option to turn warnings 
into errors, don't they?

>>The standard doesn't require the compiler to issue a warning of course 
>>(never does), but I think, the year being AD2003 and all, that a 
>>good-quality compiler should issue a warning whether the (char *) cast 
>>is there or not.
> 
> 
> A warning is typically not a compilation halting operation. Thus
> during an automated build, this error might go unnoticed. 

I either use -Werror with gcc or colormake, a few times a week.

>>>>Having one's C program compilable by a C++-compiler also helps, since 
>>>>this can sometimes flag potential problems in the C code that are not 
>>>>noticed by a C compiler.
> 
> 
> <snip enum example claiming ti support this>

I think 'claiming to support' is a bit dismissive? I think my example is 
excellent, actually! :-)

>>This is a perfectly legal C program as far as I can tell, and it's 
>>illegal in C++ due to the attempt to implicitly casting 1 to EType.

> but in C, this is not an error. 

That's my point. I think it should be an error. If I write a line like 
f(1) where the parameter ought to be an enum I want to know. I have to 
resort to C++ for that and the price-to-pay is casting malloc results.

>>I think C++ is right to flag this as erroneous, and require a cast.

> not in C, its not. Remember that enums are not a new type in C,
> they're ints. So you are inserting another useless cast, obfuscating
> your code slightly for no benefit.

The benefit, I hesitate to repeat, is the ability to compile my C 
program with a C++ compiler as well.

Best regards,

   Sidney Cadot

0
sidney (345)
10/18/2003 10:52:12 PM
Mark McIntyre wrote:

> The function of a cast is to silence a compiler warning.

Not so. The function of a cast is to convert "the value of the expression to 
the named type." (Of course, it's the programmer's job to ensure that the 
conversion is meaningful.)

-- 
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
0
dontmail (1886)
10/19/2003 3:47:38 AM
Fergus Henderson <fjh@cs.mu.oz.au> wrote:

>Jerry Feldman <gaf-noSPAM@blu.org> writes:
>
>>Keith Thompson <kst@cts.com> wrote:
>>
>>> C++ has never been a strict superset of any version of C.  C++ has
>>> several keywords that are not reserved in C; that alone makes prevents
>>> it from being a superset.
>>
>>I agree that "C++ has never been a strict superset of any version of C",
>>but I disagree with your logic. A superset can define new keywords (and
>>comment operators).
>
>A strict superset can't, if those keywords have names which are not
>already reserved for use by the implementation, because adding new
>keywords will invalidate existing C programs that happen to use those
>keywords as identifiers.
>
>Adding new comment operators can also change the meaning of existing code.
>Consider the following program:
>
>	int main() {
>		printf(1//**/2
>		  ? "fail\n" : "pass\n");
>		return 0;
>	}
>
>On a conforming C89 implementation, this will print "pass",
>but on a C++ or C99 implementation, it will print "fail".
<snip>

Congratulations, you just "proved" that C99 isn't a superset[1] of C89. 
 ;-P

[1] According to your definition of "superset".

Regards
-- 
Irrwahn 
(irrwahn33@freenet.de)
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
irrwahn33 (608)
10/19/2003 5:09:35 AM
On 13 Oct 2003 18:49:35 GMT in comp.std.c, thp@cs.ucr.edu wrote:

>In comp.std.c Douglas A. Gwyn <DAGwyn@null.net> wrote:
>+ thp@cs.ucr.edu wrote:
>+> Compiling C programs with a C++ compiler has the benefit that C++
>+> compilers are required to perform intermodule type checking.  But I'm
>+> told that this intermodule type checking is a curse when one tries to
>+> use precompiled libraries that have been compiled on different C++
>+> compilers, since that checking is usually based on name-mangling and
>+> there is no name-mangling standard.  (Perhaps others have more
>+> experience with that issue.)
>+ 
>+ On essentially any platform there is a unique standard API
>+ for C linkage.  And it is easy to get that linkage from C++
>+ by using "extern C".  Therefore, libraries written in C are
>+ readily used from both C and C++ applications.  Libraries
>+ that rely on C++-specific features (e.g. classes) are not
>+ readily used from C applications.
>
>Is it feasible to interpose a proxy library whose headers are
>conforming C code that's compiled with a C++ compiler and that calls
>functions from the C++ library?

What conclusions could be drawn from the "extern C" linkage? 

Thanks. Take care, Brian Inglis 	Calgary, Alberta, Canada
-- 
Brian.Inglis@CSi.com 	(Brian dot Inglis at SystematicSw dot ab dot ca)
    fake address		use address above to reply
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
10/19/2003 5:13:31 AM
On 12 Oct 2003 22:55:32 GMT in comp.std.c, seebs@plethora.net
(Seebs) wrote:

>In article <clcm-20031008-0017@plethora.net>,  <thp@cs.ucr.edu> wrote:
>>C is pretty much, but not quite, a sublanguage of C++.  C programmers
>>who don't use the non-C++ features of C are programming in C++ whether
>>they claim to or not.
>
>I thought about this a bit, and I have concluded that I disagree.
....
>In reality, to say you are "programming in C++" means not just that your
>code happens to be syntactically C++, but that you have adopted the philosophy
>and design of that language.  Often, people whose code passes through a C++
>compiler are really writing FORTRAN IV; I've seen such code.

How upsetting for you! ;^> Often, people whose code passes
through a C compiler are really writing Pascal; I've seen such
code and textbooks! How upsetting for me! 

Thanks. Take care, Brian Inglis 	Calgary, Alberta, Canada
-- 
Brian.Inglis@CSi.com 	(Brian dot Inglis at SystematicSw dot ab dot ca)
    fake address		use address above to reply
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
10/19/2003 5:13:36 AM
On 12 Oct 2003 22:49:01 GMT, kuyper@wizard.net (James Kuyper) wrote:


>"cody" <dont.spam.me.deutronium@gmx.de> wrote in message news:<clcm-20031008-0005@plethora.net>...
>...
>> is "const float PI=3.14" possible in plain C?
>
>Of course. Its a very bad idea, since in most cases you need a lot
>more digits, but it is possible.

My favorite is 

const volatile unsigned int foo = 42;


-- 
#include <standard.disclaimer>
 _
Kevin D Quitt  USA 91387-4454         96.37% of all statistics are made up
  Per the FCA, this address may not be added to any commercial mail list
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net
0
10/19/2003 5:15:28 AM
On Sun, 19 Oct 2003, Irrwahn Grausewitz wrote:
>
> Fergus Henderson <fjh@cs.mu.oz.au> wrote:
> >Jerry Feldman <gaf-noSPAM@blu.org> writes:
> >>Keith Thompson <kst@cts.com> wrote:
> >>
> >>> C++ has never been a strict superset of any version of C.  C++ has
> >>> several keywords that are not reserved in C; that alone makes prevents
> >>> it from being a superset.

> Congratulations, you just "proved" that C99 isn't a superset[1] of C89.

Do you dispute it?

> [1] According to your definition of "superset".

Do you dispute it?

Really, the definition of "superset" is a quite well-accepted
logical notion.  You can't really debate it.  The set of valid
C89 programs is *not* a subset of the set of valid C99 programs,
nor vice versa -- the two sets merely intersect.

-Arthur
0
ajo (1603)
10/19/2003 5:39:01 AM
On Sat, 18 Oct 2003 19:56:35 +0000, P.J. Plauger wrote:

>>                        Which of the following is most likely to
>> do the right thing, given that the type of 'p' might be hard to
>> remember?
>>
>>     extern Gronk *p;
>>
>>        p = (Gronk *) malloc(sizeof (Gronk));
>>        p = (Gronk *) malloc(sizeof *p);
>>        p = malloc(sizeof (Gronk));
>>        p = malloc(sizeof *p);
>>
>>
>> (Hint: the last one.)
> 
> None of the above. I strongly prefer:
> 
>         p = (Gronk *) malloc(N * sizeof (Gronk));
> 
> even when N is an explicit 1. (Though I do eliminate the sizeof
> when the type is demonstrably a char type.)

 Why don't you use calloc() ... do you like checking for integer
overflows, by hand?
 And if I was going to cast all the time (I'm strongly in favour of
allowing C to do it), I would write a macro. Like...

#define new1(T)    ((T *)malloc(1 * sizeof(T)))
/* much check overflow before calling */
#define newn(n, T) ((T *)malloc((n) * sizeof(T))) 

> Feel free. FWIW, I used your style for over 20 years, including a decade
> after I added void * to my compiler. Then one day, about ten years ago,
> I sat down and added casts to every blessed malloc call in my living code
> base. And I've never been sorry. A more curious person might wonder why.

 I've tried it (wanted to get some inline functions to compile under both
languages), but it's just looked too ugly to live IMO. malloc() I might be
able to live with, but it also meant I had to change code like...

Foo *foo(Bar *bar)
{
  if (!bar->foo)
    return (NULL);
  ...
}

....because C++ doesn't compile with the normal C definition of NULL. Which
affected much more code, IIRC. Then the fact that if you had anything you
passed through a (void *) then C++ made you sprinkle casts over
everything.

 And really, if I only wanted the code for C++ I wouldn't write it like I
was doing for a C/C++ hybrid _anyway_.

-- 
James Antill -- james@and.org
Need an efficient and powerful string library for C?
http://www.and.org/vstr/

0
10/19/2003 5:53:56 AM
On Sun, 19 Oct 2003 00:43:44 +0200, in comp.lang.c , Sidney Cadot
<sidney@jigsaw.nl> wrote:

>Mark McIntyre wrote:
>
> >>[[casting malloc result]]
>>>Why is it considered "bad practice"? I know it is frowned upon 
>>>sometimes, but I fail to see the rationale for that.
>> 
>> 
>> The function of a cast is to silence a compiler warning. Thats not a
>> good idea, generally. Its easy to get carried away with them.
>
>That's a very negative way of putting it. 

*Shrug*

>As far as I am concerned, a 
>pointer cast is a way of expressing the fact that the compiler-inferred 
>type of the object pointed to by a pointer differs from the type that I, 
>the programmer, know to be the real type pointed at.

Sure. When you're using implementation defined behaviour, the compiler
can't correctly convert automatically, so it needs a hint. Thats fine.

>Sometimes the compiler cannot infer the type properly and needs a bit of 
>help. I would argue that the malloc() is just such a case.

??? with malloc() the compiler can always infer the correct type.

>> Clean in the sense of "doesn't warn about errors", yes. And this is
>> good because? 
>
>I don't quite know what 'doesn't warn about errors' could mean, 

You've been told several times. 

>but 
>anyway. This is good because I can get my program compiled by the C++ 
>compiler and get to an executable that I can run. 

Ah, good in the sense of "make it compile on a non-C compiler". This
is obviously some strange new definition of good I was not previously
aware of ! 

>This is an interesting
>exercise, because any behaviorial mismatch between the program as 
>produced by the C compiler and by the C++ compiler could point to 
>something I have overlooked in the C code.

Possible but unlikely - its more likely that the C++ compiler will
pick up on C++ errors which are correct C, and fool you into
"correcting" them badly. BTW do you also try to compile with a fortran
and pascal compiler? To be sure? 

>What C compiler would you recommend, if I want a warning on an integer 
>being passed for an enum parameter (as in my example)? Or would you say  that I am wrong in wanting this? 

since  "The expression that defines the value of an enumeration
constant shall be an integer constant expression that has a value
representable as an int." [6.7.2.2(2)] I don't see that it makes no
sense to expect any C compiler to complain about this. C is not C++. 

>Problems don't disappear by qualifying  them as QOI.

But its still not a C problem is it? 

-- 
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
0
markmcintyre (4555)
10/19/2003 12:55:02 PM
On Sun, 19 Oct 2003 03:47:38 +0000 (UTC), in comp.lang.c , Richard
Heathfield <dontmail@address.co.uk.invalid> wrote:

>Mark McIntyre wrote:
>
>> The function of a cast is to silence a compiler warning.
>
>Not so. The function of a cast is to convert "the value of the expression to 
>the named type." 

True in abstract, sadly my version is as likely to be the case in
practice.... hence the whole 'don't cast malloc' point. 

>(Of course, it's the programmer's job to ensure that the 
>conversion is meaningful.)

quite. 
-- 
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
0
markmcintyre (4555)
10/19/2003 12:57:34 PM
Mark McIntyre wrote:

>>As far as I am concerned, a 
>>pointer cast is a way of expressing the fact that the compiler-inferred 
>>type of the object pointed to by a pointer differs from the type that I, 
>>the programmer, know to be the real type pointed at.
> 
> 
> Sure. When you're using implementation defined behaviour, the compiler
> can't correctly convert automatically, so it needs a hint. Thats fine.
> 
>>Sometimes the compiler cannot infer the type properly and needs a bit of 
>>help. I would argue that the malloc() is just such a case.
> 
> ??? with malloc() the compiler can always infer the correct type.

If I have the expression...

   malloc(1000*sizeof(double))

....with the intent of using its value as a 1000-element array of doubles 
later on, it should have type (double *), not type (void *). Since 
malloc() doesn't know this, I will help the compiler a bit to change the 
returned value to (double *) ASAP.

Just because you would usually write something like

   double *x = malloc(1000*sizeof(double))

.... which makes the problem go away soon enough, doesn't mean that the 
type of the malloc expression alone should be allowed to be (void *) 
longer than necessary.

> Ah, good in the sense of "make it compile on a non-C compiler". This
> is obviously some strange new definition of good I was not previously
> aware of ! 

Apparently.

>>This is an interesting
>>exercise, because any behaviorial mismatch between the program as 
>>produced by the C compiler and by the C++ compiler could point to 
>>something I have overlooked in the C code.

> Possible but unlikely - its more likely that the C++ compiler will
> pick up on C++ errors which are correct C, and fool you into
> "correcting" them badly.

Not in my experience.

> BTW do you also try to compile with a fortran and pascal compiler? To be sure? 

Is it really needed to aim for ridicule?

But to answer your question: No, since this doesn't help to reduce 
mistakes in my C code I don't. C++ however can help in that respect.

>>What C compiler would you recommend, if I want a warning on an integer 
>>being passed for an enum parameter (as in my example)? Or would you say
 >>that I am wrong in wanting this?
> 
> since  "The expression that defines the value of an enumeration
> constant shall be an integer constant expression that has a value
> representable as an int." [6.7.2.2(2)] I don't see that it makes no
> sense to expect any C compiler to complain about this. C is not C++. 

True, but being a practical person I will use any tool at my disposal to 
discover and correct potential problems in my code.

Just out of curiousity: do you consider it good style to pass an integer 
literal as an argument to a function expecting an enum?

If no: suspect I have a codebase where I'm replacing an integer argument 
to a function with an enum, because it more accurately reflects the 
purpose of that parameter. Now wouldn't it be great if the compiler 
assisted me in tracing down the remnants of the old-style function 
invocation?

>>Problems don't disappear by qualifying  them as QOI.
> But its still not a C problem is it? 

It's not really a C problem, no -- much rather a problem with C.

Best regards,

   Sidney

0
sidney (345)
10/19/2003 1:53:52 PM
Christian Bau wrote:
> 
> In article <bmr11b$7jf$1@glue.ucr.edu>, thp@cs.ucr.edu wrote:
> 
> > C and C++ have a relatively large semantic intersection, i.e., set of
> > programs to which C and C++ attach identical behavior.  It's my
> > impession that the intersecton includes the majority of actual C
> > programs.
> 
> I think the majority of actual C programs will not compile as C++
> programs at all; if the programmer never heard of C++ then it is just
> too easy to have "new", "class" or "template" as an identifier.

I doubt that this problem, while quite real, affects "a majority" of
actual C programs. I think the number of C programs that wouldn't
compile because they still use unprototyped function declarations
(mainly in legacy code, one hopes) is a much larger. Does anyone care to
provide actual numbers? I have no idea where to find them.
0
kuyper (156)
10/19/2003 5:53:54 PM
Sidney Cadot <sidney@jigsaw.nl> wrote in message news:<bms16o$e5e$1@news.tudelft.nl>...
....
> Could anybody point me to the last C89 draft standard that is publicly 
> available on the web? I have "n869.pdf" sitting on my HD for C99 which 
> is pretty useful and I would also like a similar document for C89.
> 
> If only to prevent silly mistakes like this.

A lot of changes were made between n869 and the final standard. You'd
be much better off using the actual C99 standard; it only costs $18.

I'm fairly sure that C89 is not available legally on the web; but I
could be mistaken. One reason I don't have a copy of the C89 standard
is that a legal copy was never cheap enough to be worthwhile until
just recently; and at this point I'm no longer interested.
0
kuyper5 (433)
10/19/2003 6:39:51 PM
Richard Heathfield <dontmail@address.co.uk.invalid> wrote in message news:<bmt1gp$4k1$1@titan.btinternet.com>...
> Mark McIntyre wrote:
> 
> > The function of a cast is to silence a compiler warning.
> 
> Not so. The function of a cast is to convert "the value of the expression to 
> the named type." (Of course, it's the programmer's job to ensure that the 
> conversion is meaningful.)

I think he was referring specifically to the case of casts that are
inserted despite the fact that they don't change the actual meaning of
the code. That is, casts which mandate precisely the same conversion
that would have happened automatically even if the cast weren't there.
0
kuyper5 (433)
10/19/2003 7:30:23 PM
Sidney Cadot wrote:
....
> Could anybody point me to the last C89 draft standard that is publicly 
> available on the web?

http://www.tkn.tu-berlin.de/~jklaue/ansic

Jirka

0
jklaue2 (127)
10/19/2003 7:38:48 PM
Sidney Cadot <sidney@jigsaw.nl> wrote in message news:<bmu51e$7u6$1@news.tudelft.nl>...
> Mark McIntyre wrote:
....
> ...with the intent of using its value as a 1000-element array of doubles 
> later on, it should have type (double *), not type (void *). Since 
> malloc() doesn't know this, I will help the compiler a bit to change the 
> returned value to (double *) ASAP.
> 
> Just because you would usually write something like
> 
>    double *x = malloc(1000*sizeof(double))
> 
> ... which makes the problem go away soon enough, doesn't mean that the 
> type of the malloc expression alone should be allowed to be (void *) 
> longer than necessary.

In C, you're not helping the compiler in any way. Inserting the cast
wouldn't make it become a double* any earlier than it would without
the cast. Either way, it still gets converted to 'double*' after the
call to malloc() and before the assignment to 'x', and there's
absolutely nothing else happening between those two events. Unless
your code actually needs to work with C++, this is pointless.

The only thing you're doing, is turning off the error or warning
messages that would occur is you had a missing declaration of 'malloc'
(C only), or a declaration of malloc() in scope with a return type
that can be converted to the destination type, but shouldn't be. In C,
this would have to be a function or function pointer with internal
linkage. It can be done with namespaces or function overloading in
C++.

There's a number of reasons why 'new' is the superior approach to this
problem in C++.

> > BTW do you also try to compile with a fortran and pascal compiler? To be sure? 
> 
> Is it really needed to aim for ridicule?
> 
> But to answer your question: No, since this doesn't help to reduce 
> mistakes in my C code I don't. C++ however can help in that respect.

Not if you've got a decent C compiler. Most C++ compilers have a mode
where they compile according to C rules. Truly legitimate warnings
that are not specific to C++ should be the same in both modes.

The warnings that a C++ compiler will give you that a good C compiler
won't give you are mainly warnings about things that aren't really a
problem in C. And that's equally true if you replace "C++" with
"Fortran" or "Pascal".
0
kuyper5 (433)
10/19/2003 7:53:36 PM
Richard Heathfield <dontmail@address.co.uk.invalid> wrote in message news:<bmsa0s$qto$2@hercules.btinternet.com>...
> Kevin D. Quitt wrote:
> 
> > On Sat, 18 Oct 2003 09:27:07 +0000 (UTC), thp@cs.ucr.edu wrote:
> > 
> >>  It's my
> >>impession that the intersecton includes the majority of actual C
> >>programs.
> > 
> > #define true  (1/(sizeof 'a' - 1))
> 
> Um, this resolves to 1/0 in C++, and either 1/0 or 0 in C. None of these 
> values is typically associated with the concept of truth in either C or 
> C++. :-)

In C it resolves identically with (1/(sizeof(int)-1)). That could be
0, or 1, or 1/0, depending upon sizeof(int); For that reason, it
doesn't belong in code intended to be portable. However, it is a
correct (if not particularly well-motivated) definition for 'true'
when sizeof(int)==2.
0
kuyper5 (433)
10/19/2003 7:53:57 PM
In article <3F92CFB2.70C9E0C7@saicmodis.com>, James Kuyper
<kuyper@saicmodis.com> writes
>Christian Bau wrote:
>> 
>> In article <bmr11b$7jf$1@glue.ucr.edu>, thp@cs.ucr.edu wrote:
>> 
>> > C and C++ have a relatively large semantic intersection, i.e., set of
>> > programs to which C and C++ attach identical behavior.  It's my
>> > impession that the intersecton includes the majority of actual C
>> > programs.
>> 
>> I think the majority of actual C programs will not compile as C++
>> programs at all; if the programmer never heard of C++ then it is just
>> too easy to have "new", "class" or "template" as an identifier.
>
>I doubt that this problem, while quite real, affects "a majority" of
>actual C programs. I think the number of C programs that wouldn't
>compile because they still use unprototyped function declarations
>(mainly in legacy code, one hopes) is a much larger. Does anyone care to
>provide actual numbers? I have no idea where to find them.

I would say that as the majority of C programs are going to be on
embedded platforms, most of which use C with architecture specific
extensions you are unlikely to get them to compile in C++ compilers. 

Many of the architectures don't have C++ compilers.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
0
chris32 (3361)
10/19/2003 8:24:25 PM
James Kuyper wrote:

> Christian Bau wrote:
>> 
>> In article <bmr11b$7jf$1@glue.ucr.edu>, thp@cs.ucr.edu wrote:
>> 
>> > C and C++ have a relatively large semantic intersection, i.e., set of
>> > programs to which C and C++ attach identical behavior.  It's my
>> > impession that the intersecton includes the majority of actual C
>> > programs.
>> 
>> I think the majority of actual C programs will not compile as C++
>> programs at all; if the programmer never heard of C++ then it is just
>> too easy to have "new", "class" or "template" as an identifier.
> 
> I doubt that this problem, while quite real, affects "a majority" of
> actual C programs. I think the number of C programs that wouldn't
> compile because they still use unprototyped function declarations
> (mainly in legacy code, one hopes) is a much larger. Does anyone care to
> provide actual numbers? I have no idea where to find them.

Well, one place I can look is in my current development directory. I chose 
the first fifty C modules I could find[1].


Below, "Yes" means "C source compiled cleanly under a C++ compiler in 
conforming mode", and "No" mea... well! :-)

Yes : 13
No  : 37

I was pleasantly surprised that so many "passed" the test, but not at all 
surprised that so many "failed". Some of the failures were for rather 
esoteric reasons, e.g. to do with constness, but most were to do with void 
*, and there was the occasional keyword issue as well.


[1] Hey, I don't have all day, okay? :-)

-- 
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
0
dontmail (1886)
10/19/2003 8:27:47 PM
James Kuyper wrote:

> Richard Heathfield <dontmail@address.co.uk.invalid> wrote in message
> news:<bmsa0s$qto$2@hercules.btinternet.com>...
>> Kevin D. Quitt wrote:
>> > 
>> > #define true  (1/(sizeof 'a' - 1))
>> 
>> Um, this resolves to 1/0 in C++, and either 1/0 or 0 in C. None of these
>> values is typically associated with the concept of truth in either C or
>> C++. :-)
> 
> In C it resolves identically with (1/(sizeof(int)-1)). That could be
> 0, or 1, or 1/0, depending upon sizeof(int);

I did indeed miss the 1 possibility (where sizeof(int) is 2). Sorry about 
that.

> For that reason, it
> doesn't belong in code intended to be portable. However, it is a
> correct (if not particularly well-motivated) definition for 'true'
> when sizeof(int)==2.

Yes. Oops.


-- 
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
0
dontmail (1886)
10/19/2003 8:47:32 PM
James Kuyper wrote:

>>...with the intent of using its value as a 1000-element array of doubles 
>>later on, it should have type (double *), not type (void *). Since 
>>malloc() doesn't know this, I will help the compiler a bit to change the 
>>returned value to (double *) ASAP.
>>
>>Just because you would usually write something like
>>
>>   double *x = malloc(1000*sizeof(double))
>>
>>... which makes the problem go away soon enough, doesn't mean that the 
>>type of the malloc expression alone should be allowed to be (void *) 
>>longer than necessary.
> 
> 
> In C, you're not helping the compiler in any way.

But surely, I am. It can now detect assignment to the wrong type of 
pointer, for example:

int *x = malloc(1000*sizeof(double)) /* would go unnoticed */
int *y = (double*)malloc(1000*sizeof(double)) /* would be noticed */

> Inserting the cast
> wouldn't make it become a double* any earlier than it would without
> the cast.

Yes it would. See above.

 > Either way, it still gets converted to 'double*' after the
> call to malloc() and before the assignment to 'x', and there's
> absolutely nothing else happening between those two events. Unless
> your code actually needs to work with C++, this is pointless.

This whole discussion is based on my assertion that it is sometimes 
useful to be able to compile a C program with a C++ compiler.

> The only thing you're doing, is turning off the error or warning
> messages that would occur is you had a missing declaration of 'malloc'
> (C only),

Any decent compiler nowadays has warnings for missing prototypes.

> or a declaration of malloc() in scope with a return type
> that can be converted to the destination type, but shouldn't be. In C,
> this would have to be a function or function pointer with internal
> linkage. It can be done with namespaces or function overloading in
> C++.
> 
> There's a number of reasons why 'new' is the superior approach to this
> problem in C++.

True, though I am disgusted by the 'delete [] array' syntax :-)

>>>BTW do you also try to compile with a fortran and pascal compiler? To be sure? 
>>
>>Is it really needed to aim for ridicule?
>>
>>But to answer your question: No, since this doesn't help to reduce 
>>mistakes in my C code I don't. C++ however can help in that respect.
> 
> Not if you've got a decent C compiler. Most C++ compilers have a mode
> where they compile according to C rules. Truly legitimate warnings
> that are not specific to C++ should be the same in both modes.

I'm trying to argue that C++ is rightly more picky about some things 
that are (unfortunately) legal C. See my enum example in a previous post.

> The warnings that a C++ compiler will give you that a good C compiler
> won't give you are mainly warnings about things that aren't really a
> problem in C.

I think implicit int->enum conversions are a problem, notwithstanding it 
is allowed in C.

> And that's equally true if you replace "C++" with "Fortran" or "Pascal".

Yeah yeah ... :-)

Best regards,

   Sidney

0
sidney (345)
10/19/2003 11:13:38 PM
In comp.std.c Richard Heathfield <dontmail@address.co.uk.invalid> wrote:
+ James Kuyper wrote:
+ 
+> Christian Bau wrote:
+>> 
+>> In article <bmr11b$7jf$1@glue.ucr.edu>, thp@cs.ucr.edu wrote:
+>> 
+>> > C and C++ have a relatively large semantic intersection, i.e., set of
+>> > programs to which C and C++ attach identical behavior.  It's my
+>> > impession that the intersecton includes the majority of actual C
+>> > programs.
+>> 
+>> I think the majority of actual C programs will not compile as C++
+>> programs at all; if the programmer never heard of C++ then it is just
+>> too easy to have "new", "class" or "template" as an identifier.
+> 
+> I doubt that this problem, while quite real, affects "a majority" of
+> actual C programs. I think the number of C programs that wouldn't
+> compile because they still use unprototyped function declarations
+> (mainly in legacy code, one hopes) is a much larger. Does anyone care to
+> provide actual numbers? I have no idea where to find them.
+ 
+ Well, one place I can look is in my current development directory. I chose 
+ the first fifty C modules I could find[1].
+ 
+ 
+ Below, "Yes" means "C source compiled cleanly under a C++ compiler in 
+ conforming mode", and "No" mea... well! :-)
+ 
+ Yes : 13
+ No  : 37
+ 
+ I was pleasantly surprised that so many "passed" the test, but not at all 
+ surprised that so many "failed". Some of the failures were for rather 
+ esoteric reasons, e.g. to do with constness, but most were to do with void 
+ *, and there was the occasional keyword issue as well.

Thanks.  I presume that nearly all of the void* issues had to do with
assigning the return value form malloc() to something of a non-void
pointer type.

Tom Payne
0
thp
10/20/2003 12:37:44 AM
On Mon, 20 Oct 2003, Sidney Cadot wrote:
>
> James Kuyper wrote:
> [Sidney Cadot wrote:]
> >>Just because you would usually write something like
> >>
> >>   double *x = malloc(1000*sizeof(double))
> >>
> >>... which makes the problem go away soon enough, doesn't mean that the
> >>type of the malloc expression alone should be allowed to be (void *)
> >>longer than necessary.
> >
> > In C, you're not helping the compiler in any way.
>
> But surely, I am.

Nope, you're not.  In fact, you're *hurting* the compiler, by making
it lex nine more characters than it would have to in a program written
by, say, Mark. :-)

> It can now detect assignment to the wrong type of
> pointer, for example:
>
> int *x = malloc(1000*sizeof(double)) /* would go unnoticed */

No competent programmer would ever write a line such as the above.
(I can say this because you've already assured me that *you* would
never write the above, and neither would I, so I'm safe.)  The
idiomatic c.l.c way of malloc'ing a 1000-element array is:

  int *x = malloc(1000 * sizeof *x);

No cast, no error (not even if sizeof(double) != sizeof(int)).
Plus, you get a warning if 'malloc' is improperly prototyped to
return anything other than (int*) or (void*).  Plus, everything
to the right of the = sign can be left alone if the type of 'x'
ever changes -- which can make a big difference in medium-sized
projects.

[OT: I personally think C++'s 'new' syntax made a step backwards in
requiring the type of 'x' to be explicitly specified by the
programmer in  int *x = new int[1000];  That might be the fault
of C++'s "inexplicable" lack of 'typeof', though.]


> int *y = (double*)malloc(1000*sizeof(double)) /* would be noticed */

Sure, it would.  But you've got three type-names on that line:
'int', 'double', and 'double'.  How would you make sure that you
got the middle one right?  I mean,

> int *y = (int*)malloc(1000*sizeof(double)) /* would be noticed */

is legal C that wouldn't necessarily be caught by either a C or a
C++ compiler.  And it looks very similar to your preferred style.
What's the tip-off that the above line is completely wrong?  How
many man-hours do you think it would take to find the bug?


> > Inserting the cast
> > wouldn't make it become a double* any earlier than it would without
> > the cast.
>
> Yes it would. See above.

No, it wouldn't.  See the Standard.


>  > Either way, it still gets converted to 'double*' after the
> > call to malloc() and before the assignment to 'x', and there's
> > absolutely nothing else happening between those two events. Unless
> > your code actually needs to work with C++, this is pointless.
>
> This whole discussion is based on my assertion that it is sometimes
> useful to be able to compile a C program with a C++ compiler.

And that assertion has been rejected by most of the people involved
in this discussion.  If you want to create an executable from a file
of C source code, use a C compiler!  If you want to link C and C++
code together, use a C compiler on the C part, a C++ compiler on the
C++ part, and extern "C" in the headers.


> > There's a number of reasons why 'new' is the superior approach to this
> > problem in C++.
>
> True, though I am disgusted by the 'delete [] array' syntax :-)

So are we all.  Still, new/delete *is* the idiomatic C++ style, and
should be used in C++ code.  Anyone who tries to write C in C++ is
IMO just as silly as those who write Fortran in C.  The languages
operate under completely different paradigms.


> I'm trying to argue that C++ is rightly more picky about some things
> that are (unfortunately) legal C. See my enum example in a previous post.

Couldn't you just avoid the use of those "unfortunate" constructs in
your own code?  After all, your average C++ compiler doesn't warn about:

    Use of 'goto'
    Improperly parenthesized arithmetic expressions
    Use of = for ==, or vice versa
    Invasion of implementation namespace
    Possible integer overflows
    Failure to fflush(stdout)
    Memory leaks
    Incorrect pointer usage
    Possible buffer overflows

> > The warnings that a C++ compiler will give you that a good C compiler
> > won't give you are mainly warnings about things that aren't really a
> > problem in C.
>
> I think implicit int->enum conversions are a problem, notwithstanding it
> is allowed in C.

Obviously, hardly anybody here does.  Do you have any other
examples of things that are allowed in C, but not in C++, of
which you believe the C++ way is better?  (Everyone knows the
laundry list of C/C++ differences, and everyone has their own
pet peeves about C features, but I have never to my knowledge
seen anyone claim that the C/C++ intersection language actually
*fixes* any of C's problems.)

-Arthur
0
ajo (1603)
10/20/2003 1:12:56 AM
James Kuyper wrote:

> Christian Bau wrote:
> 
>>In article <bmr11b$7jf$1@glue.ucr.edu>, thp@cs.ucr.edu wrote:
>>
>>
>>>C and C++ have a relatively large semantic intersection, i.e., set of
>>>programs to which C and C++ attach identical behavior.  It's my
>>>impession that the intersecton includes the majority of actual C
>>>programs.
>>
>>I think the majority of actual C programs will not compile as C++
>>programs at all; if the programmer never heard of C++ then it is just
>>too easy to have "new", "class" or "template" as an identifier.
> 
> 
> I doubt that this problem, while quite real, affects "a majority" of
> actual C programs. I think the number of C programs that wouldn't
> compile because they still use unprototyped function declarations
> (mainly in legacy code, one hopes) is a much larger. Does anyone care to
> provide actual numbers? I have no idea where to find them.

well, the code I work on has one structure with a member class.  It 
also has a depressing lack of prototypes in the function definitions, 
even though all the functions (well, most of them) have prototype 
declarations (as well as non-prototype declarations - despite the fact 
that we don't have any non-ANSI compilers to support).  I've tried to 
get some of this stuff fixed up, but the corpus is too large and there 
are too many uninterested parties in charge of it to actually clean it 
up.  I fantasize about getting it clean enough to compile under a C++ 
compiler - not because we'd necessarily want to release such a 
version, but simply because so much of the code would have been 
improved in order to get to the point where that was possible. 
Depressingly, it has been hard work to get people to the point where 
'gcc -Wall -Wmissing-prototypes -Wstrict-prototypes' compiles 
reasonably cleanly - we are not there yet.  The volume of code? 
Multiple millions of lines in total.

-- 
Jonathan Leffler                   #include <disclaimer.h>
Email: jleffler@earthlink.net, jleffler@us.ibm.com
Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/

0
jleffler (73)
10/20/2003 5:27:07 AM
On Mon, 20 Oct 2003 01:13:38 +0200, Sidney Cadot wrote:

> But surely, I am. It can now detect assignment to the wrong type of 
> pointer, for example:
> 
> int *x = malloc(1000*sizeof(double)) /* would go unnoticed */
> int *y = (double*)malloc(1000*sizeof(double)) /* would be noticed */

 And to combat your idot proofing the world makes a better idiot...

int *x = (int *)malloc(10 * sizeof(short));
int *y = (int *)malloc(10);
int *z = (int *)malloc(0 * sizeof(int));

....I could _maybe_ understand the desire for something like g_new(), where
you do...

#define foo_new(T, n) ((T *)calloc((n), sizeof(T)))

int *x = foo_new(int, 10);

....but I fail to see how going from typing something once to typing it
twice improves anything.

-- 
James Antill -- james@and.org
Need an efficient and powerful string library for C?
http://www.and.org/vstr/

0
10/20/2003 5:50:58 AM
In comp.std.c Jonathan Leffler <jleffler@earthlink.net> wrote:
+ James Kuyper wrote:
+ 
+> Christian Bau wrote:
+> 
+>>In article <bmr11b$7jf$1@glue.ucr.edu>, thp@cs.ucr.edu wrote:
+>>
+>>
+>>>C and C++ have a relatively large semantic intersection, i.e., set of
+>>>programs to which C and C++ attach identical behavior.  It's my
+>>>impession that the intersecton includes the majority of actual C
+>>>programs.
+>>
+>>I think the majority of actual C programs will not compile as C++
+>>programs at all; if the programmer never heard of C++ then it is just
+>>too easy to have "new", "class" or "template" as an identifier.
+> 
+> 
+> I doubt that this problem, while quite real, affects "a majority" of
+> actual C programs. I think the number of C programs that wouldn't
+> compile because they still use unprototyped function declarations
+> (mainly in legacy code, one hopes) is a much larger. Does anyone care to
+> provide actual numbers? I have no idea where to find them.
+ 
+ well, the code I work on has one structure with a member class.  It 
+ also has a depressing lack of prototypes in the function definitions, 
+ even though all the functions (well, most of them) have prototype 
+ declarations (as well as non-prototype declarations - despite the fact 
+ that we don't have any non-ANSI compilers to support).  I've tried to 
+ get some of this stuff fixed up, but the corpus is too large and there 
+ are too many uninterested parties in charge of it to actually clean it 
+ up.  I fantasize about getting it clean enough to compile under a C++ 
+ compiler - not because we'd necessarily want to release such a 
+ version, but simply because so much of the code would have been 
+ improved in order to get to the point where that was possible. 
+ Depressingly, it has been hard work to get people to the point where 
+ 'gcc -Wall -Wmissing-prototypes -Wstrict-prototypes' compiles 
+ reasonably cleanly - we are not there yet.  The volume of code? 
+ Multiple millions of lines in total.

In principle, it shouldn't be that difficult to for a syntax-savvy
preprocessor to cast problematic void* assignments, e.g., return
values from malloc.  Similarly it shouldn't be difficult to deal with
C-program identifiers that collide with C++ keywords by decorating
them with some suitable prefix or suffix.

In principle a short script could do such things.  

In principle, principle and practice are one; in practice, they're
not.

Tom Payne
0
thp (42)
10/20/2003 5:59:21 AM
Sidney Cadot <sidney@jigsaw.nl> wrote in message news:<bmv5r0$kvv$1@news.tudelft.nl>...
> James Kuyper wrote:
....
> > In C, you're not helping the compiler in any way.
> 
> But surely, I am. It can now detect assignment to the wrong type of 
> pointer, for example:
> 
> int *x = malloc(1000*sizeof(double)) /* would go unnoticed */
> int *y = (double*)malloc(1000*sizeof(double)) /* would be noticed */

Is C/C++ your normal programming language? Even moderately experienced
C/C++ programmers quickly become compulsive about putting in ';' where
needed. Just wondering, that's not intended as an attack.

Back to the actual issues, here's another case:

  int *y = (int*)malloc(1000*sizeof(double)); // would be unnoticed

The type checking that you get from

  T *p = (T*)malloc(expression);

is not very useful, because it's extremely rare to change one of the
'T's without changing the other one, and when it does happen the
correction is usually that you need to change the second one to match
the first. That correction produces exactly the same effect that you
would get automatically if you removed the cast.

On the other hand, the cast disables the validity check that you would
otherwise  get if the declaration of malloc() is either missing or
specifies an incompatible return type, and that's a much more
important validity check.

> > Inserting the cast
> > wouldn't make it become a double* any earlier than it would without
> > the cast.
> 
> Yes it would. See above.

I've seen above, and I don't see anything relevant. There's not a
single event that happens between the time that it would be converted
to void with the cast, and the time it would be converted to double*
without the cast. Therefore, in what sense is it "earlier"?

>  > Either way, it still gets converted to 'double*' after the
> > call to malloc() and before the assignment to 'x', and there's
> > absolutely nothing else happening between those two events. Unless
> > your code actually needs to work with C++, this is pointless.
> 
> This whole discussion is based on my assertion that it is sometimes 
> useful to be able to compile a C program with a C++ compiler.

You misunderstand me. You want to compile a C program using a C++
compiler, solely for the purpose of the dubious benefit of better
error handling. If that does in fact produce better error handling,
that indicates that you have a low quality C compiler. Your proper
response should be to get another one.

I was talking about someone who actually needs to compile with C++
because they need their code to work in a C++ context, not just for
the error checking. In that situation, your approach would make a lot
more sense.

....
> > Not if you've got a decent C compiler. Most C++ compilers have a mode
> > where they compile according to C rules. Truly legitimate warnings
> > that are not specific to C++ should be the same in both modes.
> 
> I'm trying to argue that C++ is rightly more picky about some things 
> that are (unfortunately) legal C. See my enum example in a previous post.

C++ is rightly more picky about things that C++ needs to be more picky
about; if a C program actually needs to be more picky about them too,
then a decent C compiler will warn about them, despite the fact that
they're legal C.

> > The warnings that a C++ compiler will give you that a good C compiler
> > won't give you are mainly warnings about things that aren't really a
> > problem in C.
> 
> I think implicit int->enum conversions are a problem, notwithstanding it 
> is allowed in C.

Then a good C compiler should have the option of warning you about
them.
0
kuyper5 (433)
10/20/2003 3:53:53 PM
In article <bmsg70$m14$1@news.tudelft.nl>,
Sidney Cadot  <sidney@jigsaw.nl> wrote:
>Mark McIntyre wrote:
>
>>>[...] I feel my code looks prettier with malloc() casts.
>> 
>> what, you think this looks prettier
>> 	foo = (struct myweirdstruct*) malloc( sizeof (myweirdstruct));
>> than 
>> 	foo = malloc (sizeof *foo);
>> ???????
>> 
>
>Well yes, although I feel
>
>   foo = (struct myweirdstruct *)malloc(sizeof(struct myweirdstruct));
>
>looks prettier still.

How 'bout this one?
        foo=(int (*)[17][42])malloc(105 * sizeof(int (*)[17][42]));
(Compare to:
	foo=malloc(105*sizeof *foo);
I like this one much better.)


dave

-- 
Dave Vandervies                          dj3vande@csclub.uwaterloo.ca
Have some pride, you're a physics major! You know deep in your heart
you're better than the rest of the slobs there, you should be able to
knock this course off easily.     --Brian B. Rodenborn in comp.lang.c
0
dj3vande (669)
10/20/2003 9:06:43 PM
"P.J. Plauger" wrote:

> FWIW, I used your style for over 20 years, including a decade
> after I added void * to my compiler. Then one day, about ten years
> ago, I sat down and added casts to every blessed malloc call in my
> living code base. And I've never been sorry. A more curious person
> might wonder why.

Some of us are just too tickled pink to hear someone with your
"weight" weigh in in favor of casting malloc() to wonder why....

(-:

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|
0
Chris7 (2513)
10/20/2003 9:11:11 PM
thp@cs.ucr.edu wrote:

> In comp.std.c Richard Heathfield <dontmail@address.co.uk.invalid> wrote:
> +
> + Below, "Yes" means "C source compiled cleanly under a C++ compiler in
> + conforming mode", and "No" mea... well! :-)
> +
> + Yes : 13
> + No  : 37
> +
> + I was pleasantly surprised that so many "passed" the test, but not at
> + all surprised that so many "failed". Some of the failures were for
> + rather esoteric reasons, e.g. to do with constness, but most were to do
> + with void *, and there was the occasional keyword issue as well.
> 
> Thanks.  I presume that nearly all of the void* issues had to do with
> assigning the return value form malloc() to something of a non-void
> pointer type.

Yes. Well, not just malloc. Also bsearch, and one or two other home-rolled 
void * wotsits.

-- 
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
0
Richard
10/20/2003 9:50:34 PM
James Kuyper wrote:

>>>In C, you're not helping the compiler in any way.
>>
>>But surely, I am. It can now detect assignment to the wrong type of 
>>pointer, for example:
>>
>>int *x = malloc(1000*sizeof(double)) /* would go unnoticed */
>>int *y = (double*)malloc(1000*sizeof(double)) /* would be noticed */

> Is C/C++ your normal programming language? Even moderately experienced
> C/C++ programmers quickly become compulsive about putting in ';' where
> needed. Just wondering, that's not intended as an attack.

Yes, C is my normal programming language. Either it was a typo or I've 
had too much exposure to Python lately :-)

> Back to the actual issues, here's another case:
> 
>   int *y = (int*)malloc(1000*sizeof(double)); // would be unnoticed
> 
> The type checking that you get from
> 
>   T *p = (T*)malloc(expression);
> 
> is not very useful, because it's extremely rare to change one of the
> 'T's without changing the other one, and when it does happen the
> correction is usually that you need to change the second one to match
> the first. That correction produces exactly the same effect that you
> would get automatically if you removed the cast.

I agree that this won't help a lot in practice. Nevertheless, as I 
stated earlier, I think the basic idea of casting a pointer coming from 
malloc() to it's intended type ASAP is sound, in principle.

Surely I realize there are some disadvantages, but I think they are 
rather minor. The two disadvantages I heard so far that make sense in my 
opinion are:

- taking away the inability to detect a missing #include <stdlib.h>
- the burden of changing all casts for malloc()s in case a type name
   changes.

Against this I would put two advantages (as perceived by me, in any case):

- taking away a major obstacle in getting your code compilable both as
   C and C++ (the latter might help to avoid problems)
- the idea that malloc returns a void * because it cannot know the
   intended use (type) of the block just allocated; a cast brings
   the pointer under the regime of C type-checking.

I can see why this leads to a lot of debate; most people seem to think 
the disadvantages outweigh the advantages. I don't have a problem with 
that, but on the other hand, the mantra 'thou shalt not cast malloc() 
results', as laid out in the C FAQ for example, isn't as clear-cut to me 
as to many others here.


> On the other hand, the cast disables the validity check that you would
> otherwise  get if the declaration of malloc() is either missing or
> specifies an incompatible return type, and that's a much more
> important validity check.

malloc() should return void*, otherwise you have a broken C library 
anyway ... the case of a missing prototype is covered by warnings of any 
decent compiler. I don't see this validity check as something I miss.

>>>Inserting the cast
>>>wouldn't make it become a double* any earlier than it would without
>>>the cast.
>>
>>Yes it would. See above.

> I've seen above, and I don't see anything relevant. There's not a
> single event that happens between the time that it would be converted
> to void with the cast, and the time it would be converted to double*
> without the cast. Therefore, in what sense is it "earlier"?

In the compile-time sense. Surely at runtime not a clock-cycle is wasted 
on the cast (I should probably say: on most architectures), but while 
the compiler is churning away, it does something with this cast, namely 
change the type of the expression returned from malloc(). I should have 
stated this more clearly.

>>>call to malloc() and before the assignment to 'x', and there's
>>>absolutely nothing else happening between those two events. Unless
>>>your code actually needs to work with C++, this is pointless.

This entire discussion is about compile time, I think that is where this 
confusion comes from.

>>This whole discussion is based on my assertion that it is sometimes 
>>useful to be able to compile a C program with a C++ compiler.
> 
> You misunderstand me. You want to compile a C program using a C++
> compiler, solely for the purpose of the dubious benefit of better
> error handling. If that does in fact produce better error handling,
> that indicates that you have a low quality C compiler. Your proper
> response should be to get another one.

Earlier, when challenged, I produced an example (having nothing to do 
with mallocs(), but with enums) where a C++ compiler yields more 
desirable behavior (as I see it) than any C compiler could. I could have 
a go at finding more examples. A better C compiler will not help be 
there (but perhaps a good lint would).

> I was talking about someone who actually needs to compile with C++
> because they need their code to work in a C++ context, not just for
> the error checking. In that situation, your approach would make a lot
> more sense.

Sure, it would make even more sense ;-)

>>>Not if you've got a decent C compiler. Most C++ compilers have a mode
>>>where they compile according to C rules. Truly legitimate warnings
>>>that are not specific to C++ should be the same in both modes.
>>
>>I'm trying to argue that C++ is rightly more picky about some things 
>>that are (unfortunately) legal C. See my enum example in a previous post.
> 
> C++ is rightly more picky about things that C++ needs to be more picky
> about; if a C program actually needs to be more picky about them too,
> then a decent C compiler will warn about them, despite the fact that
> they're legal C.

I can't get gcc to warn about my enum-to-int example, I would however 
classify it as a decent compiler. I would be interested to know if there 
is a C compiler out there that does this.

>>I think implicit int->enum conversions are a problem, notwithstanding it 
>>is allowed in C.

> Then a good C compiler should have the option of warning you about
> them.

Do you know such a compiler? Not that's I'm going to switch from gcc, 
but I would be happily surprised if the "more decent" compiler is an 
existing rather than a hypothetical one.

Best regards,

   Sidney



0
sidney (345)
10/20/2003 11:37:22 PM
Arthur J. O'Dwyer wrote:

>>It can now detect assignment to the wrong type of
>>pointer, for example:
>>
>>int *x = malloc(1000*sizeof(double)) /* would go unnoticed */
> 
> No competent programmer would ever write a line such as the above.
> (I can say this because you've already assured me that *you* would
> never write the above, and neither would I, so I'm safe.

That's not much of an argument is it? We all make mistakes. I know I do. 
For example, I forgot the semicolon in an otherwise perfectly good 
example of why not casting malloc()s can be bad :-)

 > The idiomatic c.l.c way of malloc'ing a 1000-element array is:
> 
>   int *x = malloc(1000 * sizeof *x);

That's a circular statement: "common opinion of c.l.c. is right because 
it is the common opinion of c.l.c".

> No cast, no error (not even if sizeof(double) != sizeof(int)).
> Plus, you get a warning if 'malloc' is improperly prototyped to
> return anything other than (int*) or (void*).  Plus, everything
> to the right of the = sign can be left alone if the type of 'x'
> ever changes -- which can make a big difference in medium-sized
> projects.

I see the disadvantages of my approach.

> [OT: I personally think C++'s 'new' syntax made a step backwards in
> requiring the type of 'x' to be explicitly specified by the
> programmer in  int *x = new int[1000];  That might be the fault
> of C++'s "inexplicable" lack of 'typeof', though.]

Sometimes you may want to alloc without directly assigning to a 
variable. malloc()'s result is just an expression, as is the result of 
'new int[100]' in C++.

>>int *y = (double*)malloc(1000*sizeof(double)) /* would be noticed */
> 
> 
> Sure, it would.  But you've got three type-names on that line:
> 'int', 'double', and 'double'.  How would you make sure that you
> got the middle one right?  I mean,

>>int *y = (int*)malloc(1000*sizeof(double)) /* would be noticed */
> is legal C that wouldn't necessarily be caught by either a C or a
> C++ compiler.
 > And it looks very similar to your preferred style.
> What's the tip-off that the above line is completely wrong?  How
> many man-hours do you think it would take to find the bug?

I think I wouldn't even notice it, assuming sizeof(double)>=sizeof(int) 
;-) But this is a good point.

>>>Inserting the cast
>>>wouldn't make it become a double* any earlier than it would without
>>>the cast.
>>
>>Yes it would. See above.
> 
> No, it wouldn't.  See the Standard.

To be clar, I'm talking compile-time here. Could you point me to the 
right section of the standard that supports your assertion?

>>This whole discussion is based on my assertion that it is sometimes
>>useful to be able to compile a C program with a C++ compiler.
> 
> And that assertion has been rejected by most of the people involved
> in this discussion.  If you want to create an executable from a file
> of C source code, use a C compiler!  If you want to link C and C++
> code together, use a C compiler on the C part, a C++ compiler on the
> C++ part, and extern "C" in the headers.

Yes, it's been rejected by most, rather out-of-hand I would say. I still 
think my enum-to-int example is fair game, and I guess I could up with 
some more if I did my best.

>>>There's a number of reasons why 'new' is the superior approach to this
>>>problem in C++.
>>
>>True, though I am disgusted by the 'delete [] array' syntax :-)
>
> So are we all.  Still, new/delete *is* the idiomatic C++ style, and
> should be used in C++ code.  Anyone who tries to write C in C++ is
> IMO just as silly as those who write Fortran in C.  The languages
> operate under completely different paradigms.

Who defines the idiomatic C style? I still feel the not-casting-malloc 
issue is up for discussion, though, yes, I heard a few arguments against it.

>>I'm trying to argue that C++ is rightly more picky about some things
>>that are (unfortunately) legal C. See my enum example in a previous post.
> 
> Couldn't you just avoid the use of those "unfortunate" constructs in
> your own code?  After all, your average C++ compiler doesn't warn about:

My point is that I *would* like to avoid them, and have a program to 
assist me with that. And yes, I would not hesitate to use a Pascal 
compiler if it would help, but alas, it doesn't.

I've given an example of a large codebase where an 'int' parameter is 
changed to an 'enum' to more properly reflect its meaning. Now my C 
compiler gives me no way to check if I tidied up all calls. In cases 
like this, it is not always possible to avoid the unfortunate constructs.

>     Use of 'goto'
>     Improperly parenthesized arithmetic expressions
>     Use of = for ==, or vice versa
>     Invasion of implementation namespace
>     Possible integer overflows
>     Failure to fflush(stdout)
>     Memory leaks
>     Incorrect pointer usage
>     Possible buffer overflows

Ah, the first actual strawman argument to rear it's head.

I'm not arguing C++-compiling one's C code is the cure for everyting. 
I'm arguing it can assist with some things.

>>I think implicit int->enum conversions are a problem, notwithstanding it
>>is allowed in C.
> 
> Obviously, hardly anybody here does.

I was challenged to come up with an example where C++-compiling can 
help, I provide one, and then I'm challenged on the fact that people 
don't care about this. It's still an example.

> Do you have any other
> examples of things that are allowed in C, but not in C++, of
> which you believe the C++ way is better?  (Everyone knows the
> laundry list of C/C++ differences, and everyone has their own
> pet peeves about C features, but I have never to my knowledge
> seen anyone claim that the C/C++ intersection language actually
> *fixes* any of C's problems.)

There's a first time for everything :-)

I will try to think of another example. It's an interesting exercise.
Best regards,

   Sidney

0
sidney (345)
10/21/2003 12:03:46 AM
James Antill wrote:

> On Mon, 20 Oct 2003 01:13:38 +0200, Sidney Cadot wrote:
> 
> 
>>But surely, I am. It can now detect assignment to the wrong type of 
>>pointer, for example:
>>
>>int *x = malloc(1000*sizeof(double)) /* would go unnoticed */
>>int *y = (double*)malloc(1000*sizeof(double)) /* would be noticed */
>
>  And to combat your idot proofing the world makes a better idiot...

I'm sorry, that doesn't parse.

> int *x = (int *)malloc(10 * sizeof(short));
> int *y = (int *)malloc(10);
> int *z = (int *)malloc(0 * sizeof(int));

Three lines with C mistakes. We can agree on that much.

> ...I could _maybe_ understand the desire for something like g_new(), where
> you do...
> 
> #define foo_new(T, n) ((T *)calloc((n), sizeof(T)))
> 
> int *x = foo_new(int, 10);
> 
> ...but I fail to see how going from typing something once to typing it
> twice improves anything.

So noted.

Best regards,

   Sidney

0
sidney (345)
10/21/2003 12:07:30 AM
On Tue, 21 Oct 2003, Sidney Cadot wrote:
>
> Arthur J. O'Dwyer wrote:
> >
> >>int *x = malloc(1000*sizeof(double)) /* would go unnoticed */
> >
> > No competent programmer would ever write a line such as the above.
> > (I can say this because you've already assured me that *you* would
> > never write the above, and neither would I, so I'm safe.
>
> That's not much of an argument is it?

Well, the "rationalization" for the "no competent programmer" line
*was* tongue-in-cheek -- however, it is true that no competent
programmer would make a mistake as blatant as the above.  Anyone
who types that many characters to perform such a simple operation
should look at that line and say, "Hmm... this is more verbose than
needed.  Oh! and it's also wrong.  I'll fix it now."

> > The idiomatic c.l.c way of malloc'ing a 1000-element array is:
> >
> >   int *x = malloc(1000 * sizeof *x);
>
> That's a circular statement: "common opinion of c.l.c. is right because
> it is the common opinion of c.l.c".

Common opinion of c.l.c is idiomatic for c.l.c by the definition
of the word "idiomatic." That it happens to be Right is incidental. :)

The c.l.c idiom is also the least verbose and most error-proof
idiom allowed by the language.  (Brevity and correctness tend to
go hand-in-hand in C, because of the close relationship between
lines of code and bytes of executable.  Verbose code promotes
tangledness, if you see what I mean.)


> > [OT: I personally think C++'s 'new' syntax made a step backwards in
> > requiring the type of 'x' to be explicitly specified by the
> > programmer in  int *x = new int[1000];  That might be the fault
> > of C++'s "inexplicable" lack of 'typeof', though.]
>
> Sometimes you may want to alloc without directly assigning to a
> variable. malloc()'s result is just an expression, as is the result
> of 'new int[100]' in C++.

Yes (although trying to do strcpy(malloc(10),"hello")) in C *will*
bite you in the rear one of these days).  However, ISTR that during
the development of C++, there were people pushing for something like

    int *x = new (typeof *x)[100];

which would have been much easier on the programmer than the current
state of affairs.  But that's way OT.


> >>int *y = (double*)malloc(1000*sizeof(double)) /* would be noticed */
> >
> > Sure, it would.  But you've got three type-names on that line:
> > 'int', 'double', and 'double'.  How would you make sure that you
> > got the middle one right?  I mean,
> >
> >>int *y = (int*)malloc(1000*sizeof(double)) /* would be noticed */
> >
> > is legal C that wouldn't necessarily be caught by either a C or a
> > C++ compiler.
> > And it looks very similar to your preferred style.
> > What's the tip-off that the above line is completely wrong?  How
> > many man-hours do you think it would take to find the bug?
>
> I think I wouldn't even notice it, assuming sizeof(double)>=sizeof(int)
> ;-) But this is a good point.

Yup. :)  Would you notice it if the type-names were reversed, so
you actually *did* trash the heap on some systems, but not others?
Would you notice it if 1000 were 100000, thus running the risk of
a large memory "hole"?

> >>>Inserting the cast
> >>>wouldn't make it become a double* any earlier than it would without
> >>>the cast.
>
> To be [clear], I'm talking compile-time here. Could you point me to
> the right section of the standard that supports your assertion?

N869 section 6.5.16.1#2, which describes the order of operations
during the assignment:

    malloc() is called, and then returns a (void *).
    That (void *) is converted to (double *) and assigned to x.

With the cast, we get:

    malloc() is called, and then returns a (void *).
    That (void *) is converted to (double *) [and then...]
    That (double *) is assigned to x.

Same exact thing.  No change in executable; no change in value;
no change in type.  Just extra verbiage.


> >>This whole discussion is based on my assertion that it is sometimes
> >>useful to be able to compile a C program with a C++ compiler.
> >
> > And that assertion has been rejected by most of the people involved
> > in this discussion.  If you want to create an executable from a file
> > of C source code, use a C compiler!  If you want to link C and C++
> > code together, use a C compiler on the C part, a C++ compiler on the
> > C++ part, and extern "C" in the headers.
>
> Yes, it's been rejected by most, rather out-of-hand I would say. I still
> think my enum-to-int example is fair game, and I guess I could up with
> some more if I did my best.

The enum-to-int thing is interesting, I'll admit.  Of course, I've
never had any problems with enums myself; and anyway, I think the
*real* problem you have there is an abstraction issue -- you want
to change all your "magic numbers" to mnemonic names, right?  Well,
that issue isn't limited to enums -- it applies to #defined names
just as much.  Maybe your "house style" uses more enums than #defines,
but I think that's the exception rather than the rule.


> Who defines the idiomatic C style?

For a long time, Kernighan and Ritchie.  These days, probably the
One True Brace Style and the popular users thereof; the C standards,
of course (N869 doesn't cast malloc, e.g.); and, on Usenet, the
regulars of comp.lang.c. :)  Perhaps the popular tutorial books,
also.


> >>I'm trying to argue that C++ is rightly more picky about some things
> >>that are (unfortunately) legal C. See my enum example in a previous post.
> >
> > Couldn't you just avoid the use of those "unfortunate" constructs in
> > your own code?  After all, your average C++ compiler doesn't warn about:

> Ah, the first actual strawman argument to rear [its] head.

Yes. :-)

> I'm not arguing C++-compiling one's C code is the cure for everything.
> I'm arguing it can assist with some things.

But you've only definitively shown that it can help with the (very
rare in most circles) case of

    enum Value { VALUE_FOO = 2 };

    my_function_taking_enum(2);
/* needs to be */
    my_function_taking_enum(VALUE_FOO);

That's something that I think most C programmers would solve with

    grep 'enum' externs.h
    grep 'my_function_taking_enum' *.c
    grep 'my_other_function_taking_enum' *.c
    ...
the one or two times in their lifetimes that the problem arose.
Certainly faster than trying to make their C code lint under C++,
*just* to catch this one potential bug.

-Arthur

0
ajo (1603)
10/21/2003 12:45:20 AM
Sidney Cadot wrote:
> Arthur J. O'Dwyer wrote:
> 
.... snip ...
> 
> I'm not arguing C++-compiling one's C code is the cure for
> everyting. I'm arguing it can assist with some things.
> 
> >> I think implicit int->enum conversions are a problem,
> >> notwithstanding it is allowed in C.
> >
> > Obviously, hardly anybody here does.
> 
> I was challenged to come up with an example where C++-compiling
> can help, I provide one, and then I'm challenged on the fact
> that people don't care about this. It's still an example.

I, and apparently almost everyone else, thinks your malloc casts
are ridiculous.  The only possible reason for them is to compile
with C++, which all consider a spurious reason.

However, the enum <-> int case is different.  It is the only way,
apart from struct, to truly create a new data type in C.  As long
as those assignments go unflagged, it does very little good (but
is not useless).  I think you (and I) would be happy if gcc could
be told to emit a warning for such usages.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!


0
cbfalconer (19194)
10/21/2003 5:02:15 AM
CBFalconer wrote:

> I, and apparently almost everyone else, thinks your malloc casts
> are ridiculous.

True.

> The only possible reason for them is to compile
> with C++, which all consider a spurious reason.

Not true (ah, if only you had said "almost all"!). P J Plauger's mileage 
varies. I'm still not sure why, though, because (AFAIAA) he has not 
expounded the reason for his reason. That is, he has weighed in on the side 
of malloc casting, and has pointed out that this is so that he can gain an 
advantage by programming in the common subset of C and C++, but I'm not 
entirely sure what that advantage is.

Since Mr Plauger is a highly respected figure (and rightly so, IMHO), I am 
not prepared to dismiss his opinion lightly, but I am curious to know the 
reasons for that opinion. Until then at least, I will of course continue to 
recommend that casting malloc is spurious and counter-productive.

<snip>

-- 
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
0
dontmail (1886)
10/21/2003 5:53:36 AM
CBFalconer wrote:

> I and, apparently, almost everyone else, thinks that
> your malloc casts are ridiculous.

I don't think that they are ridiculous.

> The only possible reason for them is to compile with C++
> which all consider a spurious reason.

I don't think that it is a spurious reason.
C++ is, after all, the future of C.

> However, the enum <-> int case is different.
> It is the only way, apart from struct,
> to truly create a new data type in C.

Evidently, Brian W. Kernighan and Dennis M. Ritchie
disagree with you,
"The C Programming Language: Second Edition",
Appendix A: Reference Manual,
Section 4: Meaning of Identifiers,
Subsection 3: Derived Types, page 196.

> As long as those assignments go unflagged,
> it does very little good (but is not useless).
> I think you (and I) would be happy
> if gcc could be told to emit a warning for such usages.

0
10/21/2003 5:21:52 PM
Richard Heathfield wrote:
> CBFalconer wrote:
> 
> > I, and apparently almost everyone else, thinks your malloc casts
> > are ridiculous.
> 
.... snip ...
> 
> Since Mr Plauger is a highly respected figure (and rightly so,
> IMHO), I am not prepared to dismiss his opinion lightly, but I am
> curious to know the reasons for that opinion. Until then at least,
> I will of course continue to recommend that casting malloc is
> spurious and counter-productive.

Well, my post was primarily about the enum usage problem.  However
I suspect that PJPs usage revolves around supplying source code,
probably shrouded, for installation on many systems with various
qualities of compilers.  There are machines out there with only
K&R1 compilation facilities.  He doesn't want to do any
hand-holding.

Shrouded code is not quite suitable for patching or debugging :-) 
This does not apply to most of us.  Maybe he will confirm or deny.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!


0
cbfalconer (19194)
10/21/2003 6:27:15 PM
E. Robert Tisdale wrote:

> CBFalconer wrote:
> 
>> I and, apparently, almost everyone else, thinks that
>> your malloc casts are ridiculous.
> 
> I don't think that they are ridiculous.

I don't think Chuck cares what you think.

>> The only possible reason for them is to compile with C++
>> which all consider a spurious reason.
> 
> I don't think that it is a spurious reason.

I don't think Chuck cares what you think.

> C++ is, after all, the future of C.

No, C++ is a part of C's history. It's in the past. C is its own future.

<snip>

-- 
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
0
dontmail (1886)
10/21/2003 7:13:34 PM
Dave Vandervies wrote:

>>Well yes, although I feel
>>
>>  foo = (struct myweirdstruct *)malloc(sizeof(struct myweirdstruct));
>>
>>looks prettier still.

> How 'bout this one?
>         foo=(int (*)[17][42])malloc(105 * sizeof(int (*)[17][42]));
> (Compare to:
> 	foo=malloc(105*sizeof *foo);
> I like this one much better.)

I do like the terseness of foo=malloc(105*sizeof *foo), but with a 
"typedef int (*foop)[17][42]" I'd still prefer the cast :-)

Best regards, Sidney

0
sidney (345)
10/21/2003 7:24:17 PM
Arthur J. O'Dwyer wrote:

> On Tue, 21 Oct 2003, Sidney Cadot wrote:
> 
>>Arthur J. O'Dwyer wrote:
>>
>>>>int *x = malloc(1000*sizeof(double)) /* would go unnoticed */
>>>
>>>No competent programmer would ever write a line such as the above.
>>>(I can say this because you've already assured me that *you* would
>>>never write the above, and neither would I, so I'm safe.
>>
>>That's not much of an argument is it?
>
> Well, the "rationalization" for the "no competent programmer" line
> *was* tongue-in-cheek --

I'm sorry, I was a bit annoyed at the time I replied.

> however, it is true that no competent programmer would make a
 > mistake as blatant as the above.

That's quite a statement! Like chess grandmasters overlooking a 
mate-in-one, every expert makes silly mistakes from time to time I think.

> Anyone
> who types that many characters to perform such a simple operation
> should look at that line and say, "Hmm... this is more verbose than
> needed.  Oh! and it's also wrong.  I'll fix it now."

Let me guess.... That's _also_ tongue-in-cheek, right? :-)

> [...]
> The c.l.c idiom is also the least verbose and most error-proof
> idiom allowed by the language.

The second is as true as can be, the second, well, I needn't repeat 
earlier statement.

 > (Brevity and correctness tend to
> go hand-in-hand in C, because of the close relationship between
> lines of code and bytes of executable.  Verbose code promotes
> tangledness, if you see what I mean.)

Casting doesn't add to the executable size of course, so I'd say this is 
not applicable.

>>Sometimes you may want to alloc without directly assigning to a
>>variable. malloc()'s result is just an expression, as is the result
>>of 'new int[100]' in C++.
> Yes (although trying to do strcpy(malloc(10),"hello")) in C *will*
> bite you in the rear one of these days).

Sure, this is not very practical. But it goes to illustrate the point 
that leaving the cast to the assignment is presuming too much. Sad thing 
(for my argumentation anyway) is that you do assign the malloc() result 
in 99% of cases, and even in your strcpy example there will be an 
implicit cast to the type of the format argument. Darn :-)

>>>>int *y = (int*)malloc(1000*sizeof(double)) /* would be noticed */
> [snip] 
> 
> Yup. :)  Would you notice it if the type-names were reversed, so
> you actually *did* trash the heap on some systems, but not others?
> Would you notice it if 1000 were 100000, thus running the risk of
> a large memory "hole"?

This can be a mess. I think this is valid objection number three to 
malloc result casting, and for me at least the most convincing one.

>>To be [clear], I'm talking compile-time here. Could you point me to
>>the right section of the standard that supports your assertion?
> 
> N869 section 6.5.16.1#2, which describes the order of operations
> during the assignment:
> 
>     malloc() is called, and then returns a (void *).
>     That (void *) is converted to (double *) and assigned to x.
> 
> With the cast, we get:
> 
>     malloc() is called, and then returns a (void *).
>     That (void *) is converted to (double *) [and then...]
>     That (double *) is assigned to x.
> 
> Same exact thing.  No change in executable; no change in value;
> no change in type.  Just extra verbiage.

I was thinking in terms of how a compiler would handle this: with 
casted-malloc, it first changes the type of the void* to double*, after 
which it will go and handle double*-to-double* assignment. with 
uncasted-malloc, it will recognise void*-to-double* assigment and then 
either directly or indirectly (via an inserted cast) generate the same 
code, which is a slightly different execution path for the compiler to take.

However, the standard of course does not specify how a compiler should 
do what it must do, so you are, in fact, absolutely right.

>>Yes, it's been rejected by most, rather out-of-hand I would say. I still
>>think my enum-to-int example is fair game, and I guess I could up with
>>some more if I did my best.

> The enum-to-int thing is interesting, I'll admit.  Of course, I've
> never had any problems with enums myself; and anyway, I think the
> *real* problem you have there is an abstraction issue -- you want
> to change all your "magic numbers" to mnemonic names, right?  Well,
> that issue isn't limited to enums -- it applies to #defined names
> just as much.  Maybe your "house style" uses more enums than #defines,
> but I think that's the exception rather than the rule.

We do that, yes. But my view on enums as something distinct from ints 
stems more from early exposure to Pascal.

 > [...]

> But you've only definitively shown that it can help with the (very
> rare in most circles) case of
> 
>     enum Value { VALUE_FOO = 2 };
> 
>     my_function_taking_enum(2);
> /* needs to be */
>     my_function_taking_enum(VALUE_FOO);

That's true, I've only given one example, and I must admit it took me a 
while to think of it (it's been quite some time ago since I last did C++ 
in any seriousness). I still believe there are more examples. I'm 
thinking about that.

> That's something that I think most C programmers would solve with
> 
>     grep 'enum' externs.h
>     grep 'my_function_taking_enum' *.c
>     grep 'my_other_function_taking_enum' *.c
>     ...
> the one or two times in their lifetimes that the problem arose.
> Certainly faster than trying to make their C code lint under C++,
> *just* to catch this one potential bug.

....And I thought _I_ was practical kind of guy! :-)

Best regards,

   Sidney

0
sidney (345)
10/21/2003 8:04:58 PM
CBFalconer wrote:

> I, and apparently almost everyone else, thinks your malloc casts
> are ridiculous.  The only possible reason for them is to compile
> with C++, which all consider a spurious reason.

So I've noticed. I tried hard to make my case but I have not conviced 
anyone. Perhaps it's time to just let it slide.

> However, the enum <-> int case is different.  It is the only way,
> apart from struct, to truly create a new data type in C.  As long
> as those assignments go unflagged, it does very little good (but
> is not useless).  I think you (and I) would be happy if gcc could
> be told to emit a warning for such usages.

I think we would, yes.

Best regards,
   Sidney


0
sidney (345)
10/21/2003 8:08:41 PM
Richard Heathfield <dontmail@address.co.uk.invalid> wrote in message news:<bmus42$b6d$1@sparta.btinternet.com>...
> James Kuyper wrote:
> 
> > Christian Bau wrote:
....
> >> I think the majority of actual C programs will not compile as C++
> >> programs at all; if the programmer never heard of C++ then it is just
> >> too easy to have "new", "class" or "template" as an identifier.
> > 
> > I doubt that this problem, while quite real, affects "a majority" of
> > actual C programs. I think the number of C programs that wouldn't
> > compile because they still use unprototyped function declarations
> > (mainly in legacy code, one hopes) is a much larger. Does anyone care to
> > provide actual numbers? I have no idea where to find them.
> 
> Well, one place I can look is in my current development directory. I chose 
> the first fifty C modules I could find[1].
> 
> 
>