why still use C?
cody
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: cl...@plethora.net
Juergen Heinzl
> 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 : jue...@manannan.org \ send money instead /
Sidney Cadot
> 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
Richard Heathfield
> 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 : bin...@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
Glen Herrmannsfeldt
"Sidney Cadot" <sid...@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
Mike Wahler
<nos...@nospam.invalid> wrote in message
news:200310060910...@mail.zedz.net...
>
> On 6-Oct-2003, "cody" <NO.SPAM.d...@gmx.net> wrote:
>
> > [snip]
>
> Because C is more portable?
No more portable than C++.
-Mike
cody
> 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.
Tim Prince
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
James Kuyper
> 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++).
Darrell Grainger
> 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.pr...@whitehouse.gov
James Kuyper
...
> 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.
CBFalconer
> <nos...@nospam.invalid> wrote in message
> >
>
> 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 (cbfal...@yahoo.com) (cbfal...@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Santa Claus
> 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.
Eric Sosman
>
> 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.
Mike Wahler
"Tim Prince" <timoth...@xxxxsbcglobal.net> wrote in message
news:a9egb.224$_%6.210...@newssvr21.news.prodigy.com...
> Mike Wahler wrote:
>
> >
> > <nos...@nospam.invalid> wrote in message
> > news:200310060910...@mail.zedz.net...
> >>
> >> On 6-Oct-2003, "cody" <NO.SPAM.d...@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
osmium
> 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.
Jack Klein
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
Sandeep
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
Rob
news:clcm-2003...@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++.
Fergus Henderson
>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 <f...@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.
Richard Heathfield
> 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 : bin...@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
Douglas A. Gwyn
> 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.
Sven Semmler
> 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.
Doc O'Leary
"cody" <NO.SPAM.d...@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.
Jeremy Yallop
> 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.
E. Robert Tisdale
> 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.
fermath
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.d...@gmx.net> escribió en el mensaje
news:clcm-2003...@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
Thomas Matthews
> 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
Serve La
news:747gb.415050$2x.1...@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++.
Santa Claus
> 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 :-)
Gabriel Dos Reis
| > 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
E. Robert Tisdale
Mike Wahler
news:3F81CCBC...@jpl.nasa.gov...
> Santa Claus is a troll. Please ignore him.
I always thought he was an elf. :-)
-Mike
Sidney Cadot
>>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
Mark McIntyre
<sid...@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>
Sidney Cadot
>>[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
Sidney Cadot
> [...]
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
Default User
>
> Santa Claus is a troll. Please ignore him.
So's Tisdale. What's your point?
Brian Rodenborn
Todd Stephens
<l%kgb.329$av5...@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
Alan Connor
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
Mike Wahler
news:Olngb.438$av5...@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
Alan Connor
Thanks Mike. Don't know how I missed that. Got it now from the FTP site.
Long...Scary :-)
Thanks to Steve Summit.
Richard Heathfield
> 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
> 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.
Alan Connor
>
>
> 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.
Micah Cowan
> On Tue, 7 Oct 2003 03:24:01 +0000 (UTC), Richard Heathfield <dont...@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
James Antill
> 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 -- ja...@and.org
Need an efficient and powerful string library for C?
http://www.and.org/vstr/
Alan Connor
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.
Alan Connor
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.)
(:-)
Mike Wahler
"Alan Connor" <zzz...@xxx.yyy> wrote in message
"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
Sidney Cadot
> 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
Alan Connor
>> >
>> > 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.
gswork
> 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!
Alan Connor
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
:-)
Mike Wahler
"Alan Connor" <zzz...@xxx.yyy> wrote in message
> On Tue, 07 Oct 2003 06:48:16 GMT, Mike Wahler <mkwa...@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
Mike Wahler
>
> 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
Dan Pop
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...@ifh.de
Alan Connor
I was speaking in practical terms. No one is going to be entering machine
language at the prompt to copy a file.
Mike Wahler
"Alan Connor" <zzz...@xxx.yyy> wrote in message
> On Tue, 07 Oct 2003 10:08:41 GMT, Mike Wahler <mkwa...@mkwahler.net>
wrote:
> >
> >
> > "Alan Connor" <zzz...@xxx.yyy> wrote in message
> > news:Ffvgb.1050$av5...@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
John Bode
> 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.
Alan Connor
You lost me, Mike, and a ways back, I think.
Alan Connor
Well this will work out well then, because I am not into the GUI at all.
Mike Wahler
"Alan Connor" <zzz...@xxx.yyy> wrote in message
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
Mike Wahler
"Alan Connor" <zzz...@xxx.yyy> wrote in message
> On 7 Oct 2003 11:12:39 -0700, John Bode <john...@my-deja.com> wrote:
> >
> >
> > Alan Connor <zzz...@xxx.yyy> wrote in message
news:<Olngb.438$av5...@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
Alan Connor
>
>>
>> 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" <zzz...@xxx.yyy> wrote in message
news:EDEgb.1500$av5...@newsread3.news.pas.earthlink.net...
> On 7 Oct 2003 11:12:39 -0700, John Bode <john...@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. :-)
Todd Stephens
> 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
SKH
> 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.
Mike Wahler
> > 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
Alan Connor
Or at least offer itself as a complete *substitute* for the shell.
Alan Connor
> We're really way off topic now. I've sent you an email.
>
> -Mike
>
>
You are passlisted....NOW :-)
Todd Stephens
<X0Jgb.1772$av5....@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.
Peter Nilsson
>
> 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
Mike Wahler
> On Tue, 07 Oct 2003 23:41:03 GMT, Mike Wahler <mkwa...@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
cody
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: cl...@plethora.net
cody
> > "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.
Chris Hills
<NO.SPAM.d...@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 /\/\/\/\/\
/\/\/ ch...@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
cody
> 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
cody
> 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
> > pointers in structs..) instead of using C++.
>
> 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
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?
Jalapeno
"cody" <NO.SPAM.d...@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.
Jerry Feldman
"cody" <NO.SPAM.d...@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
John Bode
"cody" <NO.SPAM.d...@gmx.net> wrote in message news:<clcm-2003...@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).
gswork
> 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.
t...@cs.ucr.edu
+ 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
Micah Cowan
Possibly... added to the list of people allowed to pass through
his not-a-spammer?-then-confirm-yourself filter...?
-Micah
Micah Cowan
> Alan Connor wrote in article
> <X0Jgb.1772$av5....@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
Dan Pop
>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...@ifh.de
Dan Pop
>> C supports the const keyword now.
>
>since when? C99?
Since C89.
Mike Wahler
news:clcm-2003...@plethora.net...
Attribution restored:
"Jack Klein" <jack...@spamcop.net> wrote in message
news:clcm-2003...@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.d...@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
Mike Wahler
news:m3smm4u...@localhost.localdomain...
> "Mike Wahler" <mkwa...@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
Richard Bos
> "cody" <dont.spam.m...@gmx.de> wrote in message
> news:clcm-2003...@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
cody
> > 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
> 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
>
> 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.
Wolfgang Riedel
>
<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.
>
> 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.
>
> 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"
Wolfgang Riedel
you might find out ...
after being plonked by everybody knowledgeable.
*plonk*
CBFalconer
>
... 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 (cbfal...@yahoo.com) (cbfal...@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
CBFalconer
>
> > >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.
Joona I Palaste
>> >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 (pal...@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