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
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.
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
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...
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
John Dallman
(cody) wrote:
> no this is no trollposting and please don't get it wrong but iam very
> curious why people still use C instead of other languages especially
> C++.
There are many reasons; here are some that I've encountered:
A very large percentage of the world's programming is maintenance and
upgrading of existing code, rather than writing new stuff. And trying to
change a large program written in C into C++ is not simple: in fact, it
tends to involve a complete redesign. When you have a codebase that's
taken several hundred man-years to write, and your current manpower
resources are just about keeping up with the maintenance and upgrades, a
re-design - which will inevitably introduce loads of new problems - is not
a welcome prospect, especially when the actual benefits are less than
clear.
There are bunches of tasks for which C++ is not well suited. They include:
* Serious low-level programming, where it gets in the way too much, and
wants too much control.
* Simple proof-of-concept tasks that consist of hooking some OS features
together. I do this a lot on Windows. The more obscure OS calls don't
have C++ interfaces, and writing wrappers for them is more complicated
than just using them on their own terms.
It can be much worse than C for incomprehensibility. Easily. It just
requires someone who's got carried away with his own cleverness. Nesting a
few levels of templates and a factory or two can easily get C++ code
beyond any normal C level of incomprehensibility, with the difference that
the people who've written it feel proud of their own insight into the
language, and feel that they're writing positively good code. In spite of
the fact that it won't compile on the next version of the compiler, and
they can't understand it themselves six months later.
And some people just don't like C++. This can happen to almost anything,
and isn't useful in evaluating it - unless almost everyone dislikes it.
---
John Dallman j...@cix.co.uk
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
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
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.
--
cody
[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
Chris Hills
>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
[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
cody
> > pointers in structs..) instead of using C++.
>
> This is laughable. It is C++ that is best known for faking OO features!
> If you're looking for an OO extension to C that is actually well done,
> one that is additionally a proper superset of C, you should be looking
> at Objective-C. But that's still in the C family. If you don't want C,
> don't use C; don't use C++ and pretend you're not using C, though.
so why is objective C used my nobody? except you maybe :)
--
cody
[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
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?
--
cody
[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
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
> 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
Arthur J. O'Dwyer
On Wed, 8 Oct 2003, cody wrote:
>
> > > pieces of the application where speed really matters you can still use
> > > "normal" functions or even static methods which is basically the same.
> >
> > Suck it and see.
>
> ?
A colloquialism roughly equivalent to "why don't you try it and find
out, instead of whining to me about it?"
> > int main(void)
> > {
> > const int new = 6; /* I rest my case */
> > return 0;
> > }
>
> i though in standard C, there isn't such a thing like "const" you can only
> use macros to fake them.
Well, you're wrong. Your response here, and your response to ERT,
demonstrate that you apparently have a large gap in your C knowledge
spanning roughly the years 1988-1998. (While "ancient" K&R C didn't
have 'const', it has been standard C since 1989, and C99 didn't
change much in this respect.)
> > > each struct
> > > and enum have to be prefixed with "struct" and "enum".
> >
> > Poor baby.
Translated from Brit-sarcasm again, for the hard-of-humour:
Poor baby. Whine about it, why don't you? Most people
here are probably inclined to say that specifying 'struct'
and 'enum' is a *good* thing, since it makes it more obvious
what you're doing. In related news, Brussels sprouts are
good for you.
[Okay, that wasn't so much "translated" as "expounded."]
> void foo(struct MyStruct struct){}
>
> in C you cannot omit the keyword "struct". when it compiles without "struct"
> you probably using a C++ compiler.
False. The above is neither C *nor* C++; it's a syntax error in
both languages. (And you should read up on 'typedef'; it's the C
Gods' answer to the keyword-impaired.)
> > Yes, there is. C is simple,
>
> agreed.
>
> > portable,
>
> agreed.
>
> > and very very fast. Those are important qualities.
>
> not faster than C++. why should it?
"Suck it and see," remember? I could run some size and speed
benchmarks on my C and C++ compilers, and let you know the
quantitative differences, but why should I bother? You're the
one who wants to know! You do it!
(Oh, and re your response to Jack Klein: While IMHO Jack was a
bit harsh, and a bit defensive, his criticism of your style was
dead on. You really *don't* seem to know very much about C,
and haven't demonstrated a terrible amount of knowledge of C++
either (not that that would be on-topic here), yet you want us
to prove to you somehow that C is "still relevant," or something.
Why not read a book or two and do your own research? Ask a C
newsgroup, get a C answer.)
-Arthur
Dave Vandervies
cody <dont.spam.m...@gmx.de> wrote:
[Somebody else, whose name cody snipped, wrote:]
>> There is both a speed and size penalty for using C++ where
>> pain C would do. The penalty isn't as bad as it used to be.
There tends to be a speed and size penalty for using C++ features
that C doesn't support. There would also be a speed and size penalty
(probably larger, but not noticeably so, especially not compared to the
programmer time cost) for writing C code to match the C++ features that
C doesn't have.
Note that this is a rather weaker statement than the one quoted above.
>there should be no difference between the calls of
>
>class A{ public: static void a(){ } }
>
>and
>
>void a(){}
In fact, there should be no difference between the calls of
class A{ public: void a(){} };
and
void a(struct A *){}
(Or, if you really hate typing "struct" that much:
typedef struct A A;
void a(A *){}
). Of course, making the "this" pointer explicit probably has a
programmer time cost for keeping track of various things - if you want
to write C++ code, you're better off writing it in C++ than in C.
>> C has constants. We usually use typedefs rather than struct
>> and enum tags.
>
>is "const float PI=3.14" possible in plain C?
Yes. (Even C90.) It has different semantics than in C++ (and at least
one highly respected comp.lang.c poster[1] considers C's const semantics
broken, and can give good reasons), but if you don't try to confuse
the compiler (or manage to confuse it without trying), something like
"const float Pi=3.14159" will do exactly what you expect.
dave
[1] I'm thinking of Chris Torek, though there are probably others. See
http://groups.google.com/groups?q=const+broken+author:chris+author:torek+group:comp.lang.c
for enlightenment on this subject (or drop the "const+broken+",
and perhaps the "+group:comp.lang.c", for more general enlightenment).
--
Dave Vandervies dj3v...@csclub.uwaterloo.ca
Programmers have a problem. It's a secret we try to keep among ourselves.
We really like this stuff. We do it even when they don't pay us. Don't tell
anybody. --Joe Wright in comp.lang.c
Joona I Palaste
on comp.lang.c:
>> > pieces of the application where speed really matters you can still use
>> > "normal" functions or even static methods which is basically the same.
>>
>> Suck it and see.
> ?
It means "try it and see".
>> int main(void)
>> {
>> const int new = 6; /* I rest my case */
>> return 0;
>> }
> i though in standard C, there isn't such a thing like "const" you can only
> use macros to fake them.
Well you thought wrong. Have you read a textbook about C?
>> > each struct
>> > and enum have to be prefixed with "struct" and "enum".
>>
>> Poor baby.
> void foo(struct MyStruct struct){}
> in C you cannot omit the keyword "struct". when it compiles without "struct"
> you probably using a C++ compiler.
You probably didn't understand the reply. What's so horrible about
having to type "struct" or "enum"? Are you having difficulties typing
such long words?
>> and [C is] very very fast. Those are important qualities.
> not faster than C++. why should it?
Um, languages aren't fast or slow. Implementations of them are.
--
/-- Joona Palaste (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! ------------/
"Remember: There are only three kinds of people - those who can count and those
who can't."
- Vampyra
Noah Roberts
>>>i don't get it why people program in C and faking OOP features(function
>>>pointers in structs..) instead of using C++.
>>
>>This is laughable. It is C++ that is best known for faking OO features!
>>If you're looking for an OO extension to C that is actually well done,
>>one that is additionally a proper superset of C, you should be looking
>>at Objective-C. But that's still in the C family. If you don't want C,
>>don't use C; don't use C++ and pretend you're not using C, though.
>
>
>
> so why is objective C used my nobody? except you maybe :)
Mostly because nobody uses it. Many have never even heard of it, fewer
yet have seen it, and fewer than that have ever written code in it.
C/C++ are the industry norms and Objective-C just hasn't had its day in
the sun yet.
Actually there are several issues with Objective-C:
* No standard.
There is absolutely no standard that compilers must adhere to, and
there are several variations of language abilities. For instance, one
language feature on some compilers called a "Category" allows you to
attach methods to a class that already exist, this can be done through a
loadable library. Many compilers don't implement Categories and among
those that do there is dispute as to how they work.
* Poor adoption - unless you use MacOS X.
There is only one OS where Objective-C is use frequently. Everywhere
else it is an anomoly.
* Lack of good libraries to use except on a few systems.
If you use MacOS then of course ObjC is perfect for your use. In
other environments on the other hand you have either wrappers to C
libraries or attempts at making Unix look and act like Next or MacOS
(which is of course unix trying to look like NeXT). The NeXT API is
beutiful, a work of art, but implementations should alter it when it
runs afoul of system norms; no implementation currently does.
Objective-C is a very elegant language and as far as OO languages go it
is the best I have ever used, but I can only compare to C++ and Java.
The learning curve is very small compared to C++ especially if you
already know C; this is a side effect of the language's simplicity.
I used to have a whole list of links for the language at an old site. I
devoted much time to advocating its use. But I rarely use it anymore,
all the more the pity. If there was a nice API, like the NeXT set of
classes, that behaved like a normal Unix library (in that I can write
applications that expect to be on a unix filesystem instead of their own
".app" directory) I would probably do much of my work in that language.
It is *much* easier to use than the alternatives.
NR
Andy Sinclair
>void foo(struct MyStruct struct){}
>
>in C you cannot omit the keyword "struct". when it compiles without "struct"
>you probably using a C++ compiler.
typedef struct
{
int a;
int b;
} foo;
void bar(foo data)
{
James Kuyper
>
> > C supports the const keyword now.
>
> since when? C99?
I've been using it in C90 code for at least a decade now. I don't have a
copy of the C90 standard, so I can't be sure, but I suspect it was
introduced in C90.
> > > each struct and enum must be prefixed with "struct" and "enum".
> >
> > typedef struct X {
> > // public data members
> > } X;
> >
> > in C is the same as
> >
> > struct X {
> > // public data members
> > };
> >
> > in C++.
>
> and in function declarations? is void foo(X x){} allowed?
Yes, of course. it's a typedef, like any other.
In another message, you asked:
> > Obviously your knowledge of C is minimal.
>
> what makes you believe that?
Well, being unaware of 'const' and 'typedef struct' doesn't exactly make
you seem like an expert.
James Kuyper
...
> is "const float PI=3.14" possible in plain C?
Of course. Its a very bad idea, since in most cases you need a lot
more digits, but it is possible.
James Kuyper
> > {
> > const int new = 6; /* I rest my case */
> > return 0;
> > }
>
> i though in standard C, there isn't such a thing like "const" you can only
> use macros to fake them.
In C++, a const-qualified integer variable can be used in places where
an integer constant expression is required; that's not true in C.
However, both languages allow const-qualification.
> > > each struct
> > > and enum have to be prefixed with "struct" and "enum".
> >
> > Poor baby.
>
> void foo(struct MyStruct struct){}
C isn't as clumsy as you think. The second 'struct' is not only not
necessary, but actually a syntax error.
> in C you cannot omit the keyword "struct". when it compiles without "struct"
> you probably using a C++ compiler.
Or typedefs.
Thad Smith
>
> no this is no trollposting and please don't get it wrong but iam very
>
> of the application where speed really matters you can still use "normal"
> functions or even static methods which is basically the same.
I am an embedded systems programmer. There are many small target
platforms that do not have a C++ compiler. I am not a C++ programmer,
but understand that supporting the ability to handle exceptions forces
an overhead that isn't easily removed, even if exceptions aren't used.
> in C there arent the simplest things present like constants, each struct and
> enum have to be prefixed with "struct" and "enum". iam sure there is much
> more.
C does have constants -- 5 is an example. Of course, the macro
processor can be used to assign a symbolic name to a constant, as well.
Having to type "struct" or "enum" is not a big burden and is usually
eliminated by the use of typedef.
> i don't get it why people program in C and faking OOP features(function
> pointers in structs..) instead of using C++. are they simply masochists or
> is there a logical reason?
C has wider portability. The functionality resulting from C code, in
general, is more obvious because of the lack of overloaded functions,
operators, constructors, and destructors. This more obvious
functionality makes debugging easier.
C++, of course, does have its advantages, especially for large
projects. For smaller projects I think C yields a simpler, more
understandable solution. For very small embedded projects, assembly
code is better. At the point that I need more support for large complex
systems, I will look closely at Java.
Thad
Chris Hills
>In comp.std.c cody <NO.SPAM.d...@gmx.net> wrote:
>
>C is pretty much, but not quite, a sublanguage of C++.
C++ is based on C90 However C++ is no longer a super set of C. They are
different languages.
> C programmers
>who don't use the non-C++ features of C are programming in C++ whether
>they claim to or not. They are restricting themselves to an older,
>more established, more easily learned, and more easily implemented
>subset of C++. But they are writing in C++ --- non-idiomatic C++, but
>C++ nevertheless.
This is not true. The are using C. C++ Inherits from C NOT the other
way round.
Chris
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ ch...@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Richard Heathfield
cody wrote:
>> > pieces of the application where speed really matters you can still use
>> > "normal" functions or even static methods which is basically the same.
>>
>> Suck it and see.
>
> ?
The only way to /know/ what the performance of your program will be like is
to try it out. Even then, your results will not be generally applicable.
>
>> int main(void)
>> {
>> const int new = 6; /* I rest my case */
>> return 0;
>> }
>
> i though in standard C, there isn't such a thing like "const" you can only
> use macros to fake them.
That is an indication that you should spend less time insulting experts and
more time reading what they write, if you wish to be taken seriously in the
C programming community.
> void foo(struct MyStruct struct){}
>
> in C you cannot omit the keyword "struct". when it compiles without
> "struct" you probably using a C++ compiler.
Your example code will not compile in either language.
Here is an extract from a C header file of my own devising. As you can see,
it uses a type named TCP. As you can't see, the word "struct" is completely
missing, despite the fact that TCP /is/ indeed a name I have chosen for a
struct type.
/*! Transmission Control Protocol connection abstractions */
/*! Connect to a TCP server */
TCP *TCPConnect(const char *server, unsigned short port, FILE *fplog);
/*! Set the logging level */
int TCPSetLogLevel(TCP *connection, unsigned long LogLevel);
/*! Disconnect from the server (invalidates the connection) */
int TCPDisconnect(TCP *connection);
/*! Send a TCP packet */
int TCPSend(TCP *connection, const void *p, size_t len);
/*! Receive a TCP packet */
int TCPReceive(TCP *connection, void *p, size_t len);
Can you say "typedef"?
--
Richard Heathfield : 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
> since when? C99?
No, since the first C standard in 1989.
> and in function declarations? is void foo(X x){} allowed?
[where X is a typedef for a structure]
Of course it's allowed.
For somebody who feels free to criticize C,
you sure don't seem to know much about it.
Douglas A. Gwyn
> Compiling C programs with a C++ compiler has the benefit that C++
> compilers are required to perform intermodule type checking. But I'm
> told that this intermodule type checking is a curse when one tries to
> use precompiled libraries that have been compiled on different C++
> compilers, since that checking is usually based on name-mangling and
> there is no name-mangling standard. (Perhaps others have more
> experience with that issue.)
On essentially any platform there is a unique standard API
for C linkage. And it is easy to get that linkage from C++
by using "extern C". Therefore, libraries written in C are
readily used from both C and C++ applications. Libraries
that rely on C++-specific features (e.g. classes) are not
readily used from C applications.
Serve La
>
> in C you cannot omit the keyword "struct". when it compiles without
"struct"
> you probably using a C++ compiler.
unless:
typedef struct X { int x; } X;
void foo(X x) {}
foo((X){1});
A. Sinan Unur
@plethora.net:
>
> is "const float PI=3.14" possible in plain C?
>
You just confirmed Jack Klein's assesment of your knowledge of C.
--
A. Sinan Unur
as...@c-o-r-n-e-l-l.edu
Remove dashes for address
Spam bait: mailto:u...@ftc.gov
Andreas
that some programmers take advantage of. This is handy when coding
microprocessors, which are mostly done in C, since assembler quickly
gets out of hand. Also when core are to be translated in to HDL
language to be realized in hardware, most often C (and SystemC) is
used.
A wild guess is that every minute of the day, there is more micro
processor code running than PC code running. (?)
If this benefit is not used, I don't think that there are any big
advantages with C except that it might be easier to learn.
Best regards,
Andreas Lundgren
Jerry Feldman
"cody" <dont.spam.m...@gmx.de> wrote:
> i though in standard C, there isn't such a thing like "const" you can
> only use macros to fake them.
Maybe you should read the standard.
The const keyword is certainly defined, but it has a different meaning
than in C++.
const int foo = 4;
In C, foo is a variable and will be treated as such.
int *pf = (int *)&foo;
*pf = x;
By using casts, you can defeat the const.
In C++, foo would be treated as a true compile-time constant, and would
not actually be placed in memory.
--
Jerry Feldman <gaf-nospam-at-blu.org>
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
Jerry Feldman
"cody" <dont.spam.m...@gmx.de> wrote:
> > There is both a speed and size penalty for using C++ where
> > pain C would do. The penalty isn't as bad as it used to be.
>
> there should be no difference between the calls of
>
> class A{ public: static void a(){ } }
>
> and
>
> void a(){}
>
> > C has constants. We usually use typedefs rather than struct
> > and enum tags.
>
> is "const float PI=3.14" possible in plain C?
Define "plain C". This is possible in standard C, but not in K&R C.
--
Jerry Feldman <gaf-nospam-at-blu.org>
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
Francis Glassborow
>>
>> > each struct
>> > and enum have to be prefixed with "struct" and "enum".
>>
>
>void foo(struct MyStruct struct){}
>
>in C you cannot omit the keyword "struct". when it compiles without "struct"
>you probably using a C++ compiler.
Of course you can, but in C you have to explicitly create a typename
with typedef.
--
Francis Glassborow ACCU
If you are not using up-to-date virus protection you should not be reading
this. Viruses do not just hurt the infected but the whole community.
Francis Glassborow
<dar...@NOMORESPAMcs.utoronto.ca.com> writes
>1) Not all environments have a good C++ compiler.
And for some targets writing a C++ compiler is simply not commercially
viable. For example, exactly why would I want a C++ cross compiler for
an 8051 type embedded processor? I already need an extended C compiler
(to handle such things as bit variables) so I am not going to pay for a
tool that has a lot of unnecessary (for my needs) fat.
Seebs
>C is pretty much, but not quite, a sublanguage of C++. C programmers
>who don't use the non-C++ features of C are programming in C++ whether
>they claim to or not.
I thought about this a bit, and I have concluded that I disagree.
>Compiling C programs with a C++ compiler has the benefit that C++
>compilers are required to perform intermodule type checking. But I'm
>told that this intermodule type checking is a curse when one tries to
>use precompiled libraries that have been compiled on different C++
>compilers, since that checking is usually based on name-mangling and
>there is no name-mangling standard. (Perhaps others have more
>experience with that issue.)
It also breaks certain very useful idioms of standard C, such as automatic
(void *) conversions.
Anyway, there is a great deal more to a language than "this compiler will
accept it". Your argument works just as well for Objective C; so far as
I can tell, any valid C program is a valid Objective C program. It works
even better for "C With Classes", even though that's a dead language, than
it does for C++.
In reality, to say you are "programming in C++" means not just that your
code happens to be syntactically C++, but that you have adopted the philosophy
and design of that language. Often, people whose code passes through a C++
compiler are really writing FORTRAN IV; I've seen such code.
Stylistically, I use C instead of C++ because I am better able to express
what I mean in C, and in particular, because I have then some small hope of
being able to read the code later. If you exclude all of the features of
C++ which have tended to produce awful and unreadable code, you might as
well just write in plain old C, and avoid the "enhancements" all together.
If I want an OO bag on the side of C, I prefer Objective C; it makes the
magic features explicit, rather than implicit. If I want an OO language with
C-like syntax, I'll use Java. So far, I've found no tasks for which C++
seemed to be a good fit, except for maintaining existing code that was written
in C++.
-s
--
Copyright 2003, all wrongs reversed. Peter Seebach / se...@plethora.net
http://www.seebs.net/log/ - YA blog. http://www.seebs.net/ - homepage.
C/Unix wizard, pro-commerce radical, spam fighter. Boycott Spamazon!
Consulting, computers, web hosting, and shell access: http://www.plethora.net/
t...@cs.ucr.edu
+ t...@cs.ucr.edu wrote:
+> Compiling C programs with a C++ compiler has the benefit that C++
+> compilers are required to perform intermodule type checking. But I'm
+> told that this intermodule type checking is a curse when one tries to
+> use precompiled libraries that have been compiled on different C++
+> compilers, since that checking is usually based on name-mangling and
+> there is no name-mangling standard. (Perhaps others have more
+> experience with that issue.)
+
+ On essentially any platform there is a unique standard API
+ for C linkage. And it is easy to get that linkage from C++
+ by using "extern C". Therefore, libraries written in C are
+ readily used from both C and C++ applications. Libraries
+ that rely on C++-specific features (e.g. classes) are not
+ readily used from C applications.
Is it feasible to interpose a proxy library whose headers are
conforming C code that's compiled with a C++ compiler and that calls
functions from the C++ library?
Tom Payne
t...@cs.ucr.edu
+ In article <clcm-2003...@plethora.net>, t...@cs.ucr.edu writes
+>In comp.std.c cody <NO.SPAM.d...@gmx.net> wrote:
+>
+>C is pretty much, but not quite, a sublanguage of C++.
+
+ C++ is based on C90 However C++ is no longer a super set of C. They are
+ different languages.
+
+>C programmers who don't use the non-C++ features of C are
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+> programming in C++ whether
+>they claim to or not. They are restricting themselves to an older,
+>more established, more easily learned, and more easily implemented
+>subset of C++. But they are writing in C++ --- non-idiomatic C++, but
+>C++ nevertheless.
+
+ This is not true.
We are speaking of "C programmers to don't use the non-C++ features of
C", i.e., they use only those features of C that are C++ compatible.
+ The are using C.
That's why I referred to them as "C programmers".
+ C++ Inherits from C NOT the other way round.
I'm told that C has actually imported a few C++ features, but that's
beside the point.
Tom Payne
cody
use
> > > > "normal" functions or even static methods which is basically the
same.
> > >
> > > Suck it and see.
> >
> > ?
>
> A colloquialism roughly equivalent to "why don't you try it and find
> out, instead of whining to me about it?"
I said that some people said that C would be faster and I don't believe
that.
So why should i test it? I don't blieve it, as i said. But for the case that
people
where right, i asked that if somebody would know a case where C is faster
than C++, should tell me.
> > i though in standard C, there isn't such a thing like "const" you can
only
> > use macros to fake them.
>
> Well, you're wrong. Your response here, and your response to ERT,
> demonstrate that you apparently have a large gap in your C knowledge
> spanning roughly the years 1988-1998. (While "ancient" K&R C didn't
> have 'const', it has been standard C since 1989, and C99 didn't
> change much in this respect.)
Well, i'read books about C++ but this is long ago, and as we all know, books
are not
very up-to-date anyway and the knowlegde of some authors is alarming. how
many C++ books keep you telling to include <iostream.h> instead of
<iostream> or void main() instead of int main()?
> > void foo(struct MyStruct struct){}
> >
> > in C you cannot omit the keyword "struct". when it compiles without
"struct"
> > you probably using a C++ compiler.
>
> False. The above is neither C *nor* C++; it's a syntax error in
> both languages.
sorry, my mistake. it should read
void foo(struct MyStruct myStruct){}
or something similar :)
> (And you should read up on 'typedef'; it's the C
> Gods' answer to the keyword-impaired.)
you mean a typedef let you omit the keyword? thanks, i didn't know that.
> > not faster than C++. why should it?
>
> "Suck it and see," remember? I could run some size and speed
> benchmarks on my C and C++ compilers, and let you know the
> quantitative differences, but why should I bother? You're the
> one who wants to know! You do it!
as i said, why should it? i asked just in case somebody could tell me a case
where
this assumption could be true, but i think it is an illogigal assumption.
> (Oh, and re your response to Jack Klein: While IMHO Jack was a
> bit harsh, and a bit defensive, his criticism of your style was
> dead on.
sorry i don't know the term "dead on". what does it mean?
> You really *don't* seem to know very much about C,
you're right. before i asked my question here, i wasn't aware that there are
so many
differences between C and C++. i always though of C as simply a subset of
C++
which is, as i learned here, not true.
> and haven't demonstrated a terrible amount of knowledge of C++
i don't consider myself as a expert in C++ but i think i have reasonable
knowlegde of
it. the last year i programmed only Java and C# so my C++ knowledge might be
a bit
rusty.
> either (not that that would be on-topic here), yet you want us
> to prove to you somehow that C is "still relevant," or something.
this already was proven to me by other posters.
--
cody
[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
t...@cs.ucr.edu
[...]
+ In reality, to say you are "programming in C++" means not just that your
+ code happens to be syntactically C++, but that you have adopted the philosophy
+ and design of that language. Often, people whose code passes through a C++
+ compiler are really writing FORTRAN IV; I've seen such code.
Hence, the distinction between idiomatic and non-idiomatic C++.
Tom Payne
cody
news:clcm-2003...@plethora.net...
> cody wrote:
> >void foo(struct MyStruct struct){}
> >
> >in C you cannot omit the keyword "struct". when it compiles without
"struct"
> >you probably using a C++ compiler.
>
>
> typedef struct
> {
> int a;
> int b;
> } foo;
>
> void bar(foo data)
> {
> }
Thank you! I always said it, a snippet of code can tell more than hundreds
words!
--
cody
[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
Chris Hills
<DAG...@null.net> writes
>>>C supports the const keyword now.
>cody wrote:
>> since when? C99?
>
>No, since the first C standard in 1989.
That was just a local standard :-)
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ ch...@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Chris Hills
<d99...@efd.lth.se> writes
>C is much more alike the final machine code, and that is a benefit
>that some programmers take advantage of. This is handy when coding
>microprocessors, which are mostly done in C, since assembler quickly
>gets out of hand. Also when core are to be translated in to HDL
>language to be realized in hardware, most often C (and SystemC) is
>used.
>
>A wild guess is that every minute of the day, there is more micro
>processor code running than PC code running. (?)
According to figures I have seen from several silicon vendors (they vary
slightly but they average out at about 1 in 3 processors on (and above)
the planet is an 8051....
PC x86 processors make up less than 10% of the total the other 88% are
embedded systems... (the 2% are MACs and mainframes.)
I am sure the figures have changed in detail but it gives a fair
picture.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ ch...@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
cody
> conforming C code that's compiled with a C++ compiler and that calls
> functions from the C++ library?
when you have a C++ Library you can only call C-Style-Functions from that
Library. You cannot export Classes/Methods from that Library.
--
cody
[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
Keith Thompson
> In article <clcm-2003...@plethora.net>, t...@cs.ucr.edu writes
> >In comp.std.c cody <NO.SPAM.d...@gmx.net> wrote:
> >
> >C is pretty much, but not quite, a sublanguage of C++.
>
> C++ is based on C90 However C++ is no longer a super set of C. They are
> different languages.
C++ has never been a strict superset of any version of C. C++ has
several keywords that are not reserved in C; that alone makes prevents
it from being a superset.
--
Keith Thompson (The_Other_Keith) k...@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
Jerry Feldman
Chris Hills <ch...@phaedsys.org> wrote:
> C++ is based on C90 However C++ is no longer a super set of C. They
> are different languages.
<snip>
> This is not true. The are using C. C++ Inherits from C NOT the other
> way round.
I think that members of both the standards committee tried to keep the
standards as coordinated as possible. C++ dropped a lot of the C legacy
(K&R) stuff.
But also C99 added the // comment which is illegal in C90.
--
Jerry Feldman <gaf-nospam-at-blu.org>
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
Francis Glassborow
<ch...@phaedsys.org> writes
>>A wild guess is that every minute of the day, there is more micro
>>processor code running than PC code running. (?)
>
>According to figures I have seen from several silicon vendors (they vary
>slightly but they average out at about 1 in 3 processors on (and above)
>the planet is an 8051....
>
>PC x86 processors make up less than 10% of the total the other 88% are
>embedded systems... (the 2% are MACs and mainframes.)
>
>I am sure the figures have changed in detail but it gives a fair
>picture.
No one who understands the degree to which embedded systems pervade our
technological societies would argue that the processors in general
purpose computers represent anything but a a very small part of the
population of processors in use. However the step from that to the
volume of code running at any given time is far more debatable. 8051
based equipment tends to be running very small amounts of code
relatively slowly, quite apart from anything else high clock speeds are
very power hungry so running an 8051 at 2GHz would be inappropriate.
General purpose computer tend to run very large volumes of, often flaky,
code very fast. Of course there is embedded code running on very fast
processors (e.g. the latest high end graphics cards that are so power
hungry that they need to take power directly from the power unit and not
from the motherboard.) OTOH embedded processor code tends to be compact
and carefully honed code which is relatively error free. I would hazard
a guess that the hours of development time per code instruction is an
order of magnitude (or possibly 2 or even 3 orders) higher than that for
even for operating systems for PCs.
There is also the issue as to whether the code running on the graphics
card, sound card etc. counts as PC code or embedded processor code.
--
Francis Glassborow ACCU
If you are not using up-to-date virus protection you should not be reading
this. Viruses do not just hurt the infected but the whole community.
Sven Semmler
> sorry i don't know the term "dead on". what does it mean?
http://dict.leo.org/?search=dead+on
/Sven ;)
--
Remove the "-usenet" part of the mail address to mail me. The Gibe/Swen
worm forced me to shutdown my usenet email address for a limited time.
Jerry Feldman
Keith Thompson <k...@cts.com> wrote:
> Chris Hills <ch...@phaedsys.org> writes:
> > In article <clcm-2003...@plethora.net>, t...@cs.ucr.edu writes
> > >In comp.std.c cody <NO.SPAM.d...@gmx.net> wrote:
> > >
> > >C is pretty much, but not quite, a sublanguage of C++.
> >
> > C++ is based on C90 However C++ is no longer a super set of C. They
> > are different languages.
>
> C++ has never been a strict superset of any version of C. C++ has
> several keywords that are not reserved in C; that alone makes prevents
> it from being a superset.
I agree that "C++ has never been a strict superset of any version of C",
but I disagree with your logic. A superset can define new keywords (and
comment operators). However there are many constructs in standard C that
are illegal in C++. One example that comes to mine is:
In C:
void foo(void);
In C++ this will cause a syntax error because C++ requires fully
prototyped functions. So, the C++ equivalent is:
void foo();
Since in C++, an empty parameter list means just that, where in C, it
may indicate a legacy function declaration.
Additionally, C++ disallows most of the older legacy (K&R) code that the
C standard had to allow.
So, to be a superset, C++ must be able to compile any legal C program,
and clearly C++ was not intended to do so.
--
Jerry Feldman <gaf-nospam-at-blu.org>
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
Chris Hills
<fra...@robinton.demon.co.uk> writes
>volume of code running at any given time is far more debatable. 8051
>based equipment tends to be running very small amounts of code
>relatively slowly, quite apart from anything else high clock speeds are
>very power hungry so running an 8051 at 2GHz would be inappropriate.
Francis, AFAIK you have absolutely no knowledge of the 8051 other than
what I have told you in various ACCU and BSI meetings.... and that has
been very superficial. It would be best if you did not use it as an
example.
Being power hungry is not the reason why an 8051 does not (normally) run
at 2Ghz.... Many 8051's work in areas where power is not a factor. They
run code from 2Kbytes to 16Mega bytes.
There are also many 32 and 64 bit embedded systems running that have
megabytes of code.... virtually any car radio or engine management
system. I did have the figures for the line of code in a car radio. It
was in the 100's of thousand lines! It surprised me. Engine management
systems have the odd megabyte of code.
Then there is the telephone & internet system... based on MIPs and PPC.
One SDH switch I worked on had a PPS and 12 486 parts as slaves running
gigabytes of code....
Every aircraft is running a million or two lines of code as soon as the
inverters go on.....
Actually most things run far more code than you would imagine. From a
washing machine upwards.
>General purpose computer tend to run very large volumes of, often flaky,
>code very fast. Of course there is embedded code running on very fast
>processors
Some of it faster than the average PC.
>(e.g. the latest high end graphics cards that are so power
>hungry that they need to take power directly from the power unit and not
>from the motherboard.)
Actually some of the more powerful embedded processors like the Power PC
don't have a power )or the associated heat) problem. Just listen to an
iMac running for hours with no fan....
>OTOH embedded processor code tends to be compact
>and carefully honed code which is relatively error free. I would hazard
>a guess that the hours of development time per code instruction is an
>order of magnitude (or possibly 2 or even 3 orders) higher than that for
>even for operating systems for PCs.
No so from my experience. though it is true that the average PC
programmer will be pulling in a large overhead of library code for the
GUi and other libraries.
>There is also the issue as to whether the code running on the graphics
>card, sound card etc. counts as PC code or embedded processor code.
Good point..... very debatable. You get to choose do you want to be
Bill Gates or Plato for this one? :-)
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ ch...@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
James Kuyper
,,,
> you mean a typedef let you omit the keyword? thanks, i didn't know that.
Of course. Without typedefs, normal type specifiers have to contain at
least one keyword (such as 'int'), and usually contain many of them
(such as 'const' and 'volatile'). Typedefs allow you to replace the
entire type specifier with a single typedef name.
...
> > (Oh, and re your response to Jack Klein: While IMHO Jack was a
> > bit harsh, and a bit defensive, his criticism of your style was
> > dead on.
>
> sorry i don't know the term "dead on". what does it mean?
It means "exactly correct". The relevant image for this phrase is
someone shooting at a target; when they hit the target, their shooting
is said to be "dead on".
Fergus Henderson
>Keith Thompson <k...@cts.com> wrote:
>
>> C++ has never been a strict superset of any version of C. C++ has
>> several keywords that are not reserved in C; that alone makes prevents
>> it from being a superset.
>
>I agree that "C++ has never been a strict superset of any version of C",
>but I disagree with your logic. A superset can define new keywords (and
>comment operators).
A strict superset can't, if those keywords have names which are not
already reserved for use by the implementation, because adding new
keywords will invalidate existing C programs that happen to use those
keywords as identifiers.
Adding new comment operators can also change the meaning of existing code.
Consider the following program:
int main() {
printf(1//**/2
? "fail\n" : "pass\n");
return 0;
}
On a conforming C89 implementation, this will print "pass",
but on a C++ or C99 implementation, it will print "fail".
>However there are many constructs in standard C that
>are illegal in C++. One example that comes to mine is:
>In C:
>void foo(void);
>In C++ this will cause a syntax error because C++ requires fully
>prototyped functions.
That's not correct either. C++ allows "void foo(void);".
--
Fergus Henderson <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.
Francis Glassborow
>what I have told you in various ACCU and BSI meetings.... and that has
>been very superficial. It would be best if you did not use it as an
>example.
It would also be nice if you avoided assuming that you are my only
source of information.
However one factor often missed is that these days we often use
micro-processors to do things that are note remotely related to a
traditional view of their uses. The growth of digital sound and vision
systems is largely driven by the ability to bring computing power to
tasks that thirty years ago would have been considered as completely
outside the domain of computing.
One interesting point is that in times gone by much effort was put into
developing analogue computing technology in order to improve data
throughput where some loss of quality was acceptable. These days we
develop digital systems with the same motive:-)
I suspect that LSI has changed the world in ways that neither of us
could have imagined in our youth and that most people do not have the
slightest grasp of the extent to which modern technology relies on
computing technology.
--
Francis Glassborow ACCU
If you are not using up-to-date virus protection you should not be reading
this. Viruses do not just hurt the infected but the whole community.
cody
news:clcm-2003...@plethora.net...
> cody wrote:
>
> > sorry i don't know the term "dead on". what does it mean?
>
> http://dict.leo.org/?search=dead+on
>
> /Sven ;)
thankx
--
cody
[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
Keith Derriick
>
> Being power hungry is not the reason why an 8051 does not (normally) run
> at 2Ghz.... Many 8051's work in areas where power is not a factor. They
> run code from 2Kbytes to 16Mega bytes.
>
Yes, the usual reasons for slower clock speeds are (in my business):
- Slower rated chips are cheaper
- You don't usually need that speed
- Heat dissipation becomes a problem at high speeds
> There are also many 32 and 64 bit embedded systems running that have
> megabytes of code.... virtually any car radio or engine management
> system. I did have the figures for the line of code in a car radio. It
> was in the 100's of thousand lines! It surprised me. Engine management
> systems have the odd megabyte of code.
and when things are programmed in assembler, an 8K processor can still
hold 6-8 KLOC!.
Keith Derrick (ACCU member)
PS Don't bother sending mail to my posting address, it's a spam trap.
Irrwahn Grausewitz
>Jerry Feldman <gaf-n...@blu.org> writes:
>
>>Keith Thompson <k...@cts.com> wrote:
>>
>>> C++ has never been a strict superset of any version of C. C++ has
>>> several keywords that are not reserved in C; that alone makes prevents
>>> it from being a superset.
>>
>>I agree that "C++ has never been a strict superset of any version of C",
>>but I disagree with your logic. A superset can define new keywords (and
>>comment operators).
>
>A strict superset can't, if those keywords have names which are not
>already reserved for use by the implementation, because adding new
>keywords will invalidate existing C programs that happen to use those
>keywords as identifiers.
>
>Adding new comment operators can also change the meaning of existing code.
>Consider the following program:
>
> int main() {
> printf(1//**/2
> ? "fail\n" : "pass\n");
> return 0;
> }
>
>On a conforming C89 implementation, this will print "pass",
>but on a C++ or C99 implementation, it will print "fail".
<snip>
Congratulations, you just "proved" that C99 isn't a superset[1] of C89.
;-P
[1] According to your definition of "superset".
Regards
--
Irrwahn
(irrw...@freenet.de)
Brian Inglis
What conclusions could be drawn from the "extern C" linkage?
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
--
Brian....@CSi.com (Brian dot Inglis at SystematicSw dot ab dot ca)
fake address use address above to reply
Brian Inglis
(Seebs) wrote:
>In article <clcm-2003...@plethora.net>, <t...@cs.ucr.edu> wrote:
>>C is pretty much, but not quite, a sublanguage of C++. C programmers
>>who don't use the non-C++ features of C are programming in C++ whether
>>they claim to or not.
>
>I thought about this a bit, and I have concluded that I disagree.
...
>In reality, to say you are "programming in C++" means not just that your
>code happens to be syntactically C++, but that you have adopted the philosophy
>and design of that language. Often, people whose code passes through a C++
>compiler are really writing FORTRAN IV; I've seen such code.
How upsetting for you! ;^> Often, people whose code passes
through a C compiler are really writing Pascal; I've seen such
code and textbooks! How upsetting for me!
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
--
Brian....@CSi.com (Brian dot Inglis at SystematicSw dot ab dot ca)
fake address use address above to reply
Kevin D. Quitt
>"cody" <dont.spam.m...@gmx.de> wrote in message news:<clcm-2003...@plethora.net>...
>...
>> is "const float PI=3.14" possible in plain C?
>
>Of course. Its a very bad idea, since in most cases you need a lot
>more digits, but it is possible.
My favorite is
const volatile unsigned int foo = 42;
--
#include <standard.disclaimer>
_
Kevin D Quitt USA 91387-4454 96.37% of all statistics are made up
Per the FCA, this address may not be added to any commercial mail list
Douglas A. Gwyn
> i though in standard C, there isn't such a thing like "const" you can only
> use macros to fake them.
Wrong.
Francis Glassborow
>> i though in standard C, there isn't such a thing like "const" you can only
>> use macros to fake them.
>
>Wrong.
Of course he is confused. In C const qualification is a runtime feature
not a compile time one so:
int const c = 10;
int array[c];
is invalid in C, though valid C++. There are excellent reasons for this
difference between C and C++ and is just one example of why C and C++
are different languages that happen to share much syntax and semantics.
It is worth noting that those responsible for the languages are fully
aware of both the differences and the need to remain aligned where it
makes sense to do so. During the last two weeks of October WG14 (C) and
WG21 (C++) both voted to work on providing decimal floating point types.
What makes this ground breaking is that they also agreed that the real
work would be done under a single editor via an obscure (and little used
ISO mechanism) called a rapateur (so obscure that I am not even sure of
the spelling) group which will be jointly and severally created by the
convenors of WG14 & WG21.
It is also worth noting that WG14 wants to work on a TR to incorporate a
library of special maths functions that is part of a WG21 library TR.
WG21 is actively working to ensure that this can be done in an entirely
compatible way.
The often expressed view that somehow C & C++ are competitors has never
actually been true but these recent actions demonstrate a degree of
mutual co-operation that is probably unique among Standards Committees
and comes as a result of another innovation made several years ago which
was to extend the liaison between WG14 and WG21 from the conventional
single person reporting to a group of almost a dozen individuals and
companies who participate in both WGs.
In turn that innovation was the result of an earlier decision that WG14
and WG21 would meet at the same location in successive weeks. This
sometimes greatly stresses the finances and organisational requirements
of those hosting meetings as well as placing extra pressure on attendees
who wish to attend both meetings as it means they are away from normal
work for a fortnight at a time. Ordinary users of either C or C++
should appreciate the degree to which those who do the work on the
relevant standards are going the extra mile (kilometre) to work
together.
--
Francis Glassborow ACCU
If you are not using up-to-date virus protection you should not be reading
this. Viruses do not just hurt the infected but the whole community.
Thad Smith
> During the last two weeks of October WG14 (C) and
> WG21 (C++) both voted to work on providing decimal floating point types.
Where did the impetus for this originate? I would think something like
concurrency support would be more meaningful to most C and C++
programmers than decimal floating point. I would think that C++
programmers could handle this with decimal libraries and overloading
without affecting the core language. Why is the C committee considering
this?
Thad
Francis Glassborow
<th...@ionsky.com> writes
>Francis Glassborow wrote:
>
>> During the last two weeks of October WG14 (C) and WG21 (C++) both
>>voted to work on providing decimal floating point types.
>
>Where did the impetus for this originate?
IBM
> I would think something like concurrency support would be more
>meaningful to most C and C++ programmers than decimal floating point. I
>would think that C++ programmers could handle this with decimal
>libraries and overloading without affecting the core language. Why is
>the C committee considering this?
You would be very surprised, but for many commercial applications the
cost of emulating decimal floating point arithmetic is very high
(factors of hundreds compared with floating point arithmetic done in a
base directly supported by hardware. Typical billing programs
(constrained by tax legislation to high degrees of precision) can be
improved by overall factors in excess of three if direct hardware
support is provided for decimal floating point.
The exact way that C and C++ might utilise future decimal FPUs is open
for discussion but we are quite certain that if these languages are to
remain competitive (in overall performance) for commercial applications
we need to tackle the issue in a timely fashion.
We are also certain that the two languages should tackle their support
in a way that ensures compatibility of code even though C is likely to
provide new fundamental types and C++ is likely to work with library
types. We do not want the problems (small though they are if code is
written carefully) that surfaced through the independent support of
complex types in C and C++.
In addition it is a matter of choosing a single item to work on though
concurrency is far more demanding and hard to get right.
--
Francis Glassborow ACCU
If you are not using up-to-date virus protection you should not be reading
this. Viruses do not just hurt the infected but the whole community.
Douglas A. Gwyn
> Francis Glassborow wrote:
>> During the last two weeks of October WG14 (C) and WG21 (C++) both
>> voted to work on providing decimal floating point types.
> Where did the impetus for this originate? I would think something like
> concurrency support would be more meaningful to most C and C++
> programmers than decimal floating point. I would think that C++
> programmers could handle this with decimal libraries and overloading
> without affecting the core language. Why is the C committee considering
> this?
Download the PowerPoint presentation.
Essentially, decimal floating point is needed for financial
computation, and software simulation is way too slow. IEEE
754R is specifying a hardware standard that is being widely
implemented. (Many even think that decimal f.p. will soon
displace binary f.p. in silicon.) Exactly how the C
standard will accommodate this is still an open question;
we might simply revise the floating-point model to allow
float, double, and long double to use decimal representation,
or we might provide an additional set of decimal floating
types, or we might take a hybrid approach where both binary
and decimal floating types are introduced and make the
existing floating types an implementation-defined synonym
for one or the other set of new types, which supports a
transitional strategy for those few applications that depend
on having binary, not decimal, floating types.
There is nothing preventing the standards committee from
working on concurrency at the same time (no pun intended),
but so far (at least for WG14) nobody has come forward to
champion a work item toward a concrrency TR.
Fred J. Tydeman
>
> Francis Glassborow wrote:
>
> > During the last two weeks of October WG14 (C) and
> > WG21 (C++) both voted to work on providing decimal floating point types.
>
> Where did the impetus for this originate? I would think something like
> concurrency support would be more meaningful to most C and C++
> programmers than decimal floating point. I would think that C++
> programmers could handle this with decimal libraries and overloading
> without affecting the core language. Why is the C committee considering
> this?
Here is the paper that is making the proposal.
http://std.dkuug.dk/JTC1/SC22/WG14/www/docs/n1016.htm
Decimal floating-point is being added to IEEE-754R
Floating-Point standard (the revision of IEEE-754
now in progress).
---
Fred J. Tydeman Tydeman Consulting
tyd...@tybor.com Programming, testing, numerics
+1 (775) 287-5904 Vice-chair of J11 (ANSI "C")
Sample C99+FPCE tests: ftp://jump.net/pub/tybor/
Savers sleep well, investors eat well, spenders work forever.
P.J. Plauger
news:clcm-2003...@plethora.net...
> Francis Glassborow wrote:
>
> > During the last two weeks of October WG14 (C) and
> > WG21 (C++) both voted to work on providing decimal floating point types.
>
> Where did the impetus for this originate? I would think something like
> concurrency support would be more meaningful to most C and C++
> programmers than decimal floating point. I would think that C++
> programmers could handle this with decimal libraries and overloading
> without affecting the core language. Why is the C committee considering
> this?
IBM gave an excellent presentation on the need for decimal arithmetic in
a large proportion of calculations being performed these days. (Most tax
and interest laws specify decimal algorithms, which are hard to emulate
correctly with binary.) They also described the implementation being
developed as part of IEEE 754R, the current revision to the venerable
binary floating-point standard. And they informed us that they will be
producing CPUs with this arithmetic implemented in hardware.
I can tell you that both the C and C++ committees were skeptical at
the outset and pretty thoroughly convinced in the end. They've even
agreed to *cooperate* [sic] to ensure that C and C++ remain compatible
in this area.
Perhaps if you'd been there, you might have voted differently.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
P.S. The effect on the core language is still to be determined. Some of
us hope to keep it pretty minimal.
Marc Espie
Francis Glassborow <fra...@robinton.demon.co.uk> wrote:
>It is worth noting that those responsible for the languages are fully
>aware of both the differences and the need to remain aligned where it
>makes sense to do so. During the last two weeks of October WG14 (C) and
>WG21 (C++) both voted to work on providing decimal floating point types.
>What makes this ground breaking is that they also agreed that the real
>work would be done under a single editor via an obscure (and little used
>ISO mechanism) called a rapateur (so obscure that I am not even sure of
>the spelling) group which will be jointly and severally created by the
>convenors of WG14 & WG21.
Not so obscure. Rapporteur. Possibly not familiar to an english speaker,
as this is originally a french word. Used to denote an advisory person
or group, under somewhat formal circumstances (e.g., for a PhD thesis, in
France, you normally have two or three rapporteurs, whose mission is to
read the manuscript for the thesis and give an informed report to the
jury).
Thad Smith
>
> "Thad Smith" <th...@ionsky.com> wrote in message
> news:clcm-2003...@plethora.net...
>
> > Francis Glassborow wrote:
> >
> > > During the last two weeks of October WG14 (C) and
> > > WG21 (C++) both voted to work on providing decimal floating point types.
> >
> > Where did the impetus for this originate? I would think something like
> > concurrency support would be more meaningful to most C and C++
> > programmers than decimal floating point. I would think that C++
> > programmers could handle this with decimal libraries and overloading
> > without affecting the core language. Why is the C committee considering
> > this?
>
> IBM gave an excellent presentation on the need for decimal arithmetic in
> a large proportion of calculations being performed these days.
> I can tell you that both the C and C++ committees were skeptical at
> the outset and pretty thoroughly convinced in the end. They've even
> agreed to *cooperate* [sic] to ensure that C and C++ remain compatible
> in this area.
Thanks P.J., Francis, and Douglas, and Fred for your helpful and
informed responses. I suspect there are other regular readers here that
were as surprised as I am about the proposal. IF decimal f.p. is going
to be added to both languages, it certainly makes sense to make them
compatible.
My bias is that decimal arithmetic is more the domain of Cobol and
PL/I. Perhaps it is time to add this support to other popular
languages. My first thought was "OK, add it to C++. It should be
relatively easy. Programmers who want decimal f.p. can use C++. C is
more for system routines and embedded applications that don't have much
demand for decimal f.p."
If that viewpoint is out of touch, please clue me in. ;-)
Thad
Fred J. Tydeman
> Decimal floating-point is being added to IEEE-754R
> Floating-Point standard (the revision of IEEE-754
> now in progress).
Here is a set of web pages on why decimal floating-point
is needed:
http://www2.hursley.ibm.com/decimal
Ben Pfaff
> Exactly how the C standard will accommodate this is still an
> open question; we might simply revise the floating-point model
> to allow float, double, and long double to use decimal
> representation, [...]
Doesn't it already? FLT_RADIX is constrained to be greater than
or equal to 2, which doesn't preclude decimal representation
as far as I can tell.
Chris Hills
> IF decimal f.p. is going
>to be added to both languages, it certainly makes sense to make them
>compatible.
Given that it is likely to involve new hardware inside chips a single
standard method is probably essential. Certainly at the lower levels.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ ch...@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Fergus Henderson
>"Douglas A. Gwyn" <DAG...@null.net> writes:
>
>> Exactly how the C standard will accommodate this is still an
>> open question; we might simply revise the floating-point model
>> to allow float, double, and long double to use decimal
>> representation, [...]
>
>Doesn't it already? FLT_RADIX is constrained to be greater than
>or equal to 2, which doesn't preclude decimal representation
>as far as I can tell.
In theory, perhaps; but in practice, no, because backwards compatibility,
binary compatibility, and compatibility with other standards would prevent
implementations from defining `float' and `double' with decimal
representations. The only feasible way of supporting decimal floating
point in C would be for it to be a new type, rather than replacing one
of the existing types.
--
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.
Hans-Bernhard Broeker
[...]
> Not so obscure. Rapporteur. Possibly not familiar to an english
> speaker, as this is originally a french word.
I'd say it's unfamiliar to native English speakers because they have
made their own version of this word so they no longer use the
original. This anglified version is "reporter". Not quite as in
"journalist" but more as in: person assigned to investigate something
and make a report about it to a larger institution.
--
Hans-Bernhard Broeker (bro...@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Francis Glassborow
<b...@cs.stanford.edu> writes
>"Douglas A. Gwyn" <DAG...@null.net> writes:
>
>> Exactly how the C standard will accommodate this is still an
>> open question; we might simply revise the floating-point model
>> to allow float, double, and long double to use decimal
>> representation, [...]
>
>Doesn't it already? FLT_RADIX is constrained to be greater than
>or equal to 2, which doesn't preclude decimal representation
>as far as I can tell.
However the full proposal goes somewhat further than just using ten as
the radix.
--
Francis Glassborow ACCU
If you are not using up-to-date virus protection you should not be reading
this. Viruses do not just hurt the infected but the whole community.
P.J. Plauger
news:clcm-2003...@plethora.net...
> Thanks P.J., Francis, and Douglas, and Fred for your helpful and
> informed responses. I suspect there are other regular readers here that
> were as surprised as I am about the proposal. IF decimal f.p. is going
> to be added to both languages, it certainly makes sense to make them
> compatible.
>
> My bias is that decimal arithmetic is more the domain of Cobol and
> PL/I. Perhaps it is time to add this support to other popular
> languages. My first thought was "OK, add it to C++. It should be
> relatively easy. Programmers who want decimal f.p. can use C++. C is
> more for system routines and embedded applications that don't have much
> demand for decimal f.p."
>
> If that viewpoint is out of touch, please clue me in. ;-)
What's new here is the engineering that has gone into IEEE 754R. We now
have an encoding of decimal floating point with many desirable properties,
not the least of which is the potential for speed and storage economy
comparable to existing binary floating point. And we have IBM's public
commitment to producing hardware that uses this format.
One possibility the C and C++ committees will have to explore is simply
rounding out the consequences of having an implementation where float,
double, and long double are these new decimal formats instead of binary
IEEE 754 and its ilk. That's a *very* lightweight change, from a language
point of view, because the C Standard already permits decimal floating
point. The folks who have to do the heavy lifting are us library
implementors, who have many math functions to convert over. (We'll have
to do that for *any* approach.)
A slightly heavier possibility, which is more what IBM has proposed, is
to introduce decimal floating point alongside whatever the builtin
floating-point types currently provide. Doing that requires either adding
three more builtin floating-point types (certainly in C, possibly also in
C++), or adding some second-class citizens (easier in C++, thanks to
operator overloading).
A still heavier possibility is to stick with just three builtin types,
which are either binary or decimal, and provide for *two* sets of
second-class citizens. One of these would be assuredly binary, the
other assuredly decimal. And one of the two would have the same
representation as the builtin types. That makes sense only if we can
demonstrate a clear need for both forms of arithmetic within one
program.
It's too soon to say what the best solution will be, but at least the
two committees will be in close communication during the exploration
and development.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
P.J. Plauger
news:clcm-2003...@plethora.net...
> "Douglas A. Gwyn" <DAG...@null.net> writes:
>
> > Exactly how the C standard will accommodate this is still an
> > open question; we might simply revise the floating-point model
> > to allow float, double, and long double to use decimal
> > representation, [...]
>
> Doesn't it already? FLT_RADIX is constrained to be greater than
> or equal to 2, which doesn't preclude decimal representation
> as far as I can tell.
Basically, yes. But there are a few extra functions that make sense
for this particular decimal floating-point representation. We should
at least add those. And there's yet another rounding mode to add to
the <fenv.h> machinery. Stuff like that.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Mark Gordon
Thad Smith <thad...@acm.org> wrote:
<snip>
> were as surprised as I am about the proposal. IF decimal f.p. is
> going to be added to both languages, it certainly makes sense to make
> them compatible.
It would definitely help.
> My bias is that decimal arithmetic is more the domain of Cobol and
> PL/I. Perhaps it is time to add this support to other popular
> languages. My first thought was "OK, add it to C++. It should be
> relatively easy. Programmers who want decimal f.p. can use C++. C is
> more for system routines and embedded applications that don't have
> much demand for decimal f.p."
>
> If that viewpoint is out of touch, please clue me in. ;-)
I work on an application written in C which does various forms of
financial computation and earns the company half its revenue. I also
know of a few other applications which are definitely written in C and
do financial calculations. Decimal arithmetic would be a definite plus.
--
Mark Gordon
Paid to be a Geek & a Senior Software Developer
Although my email address says spamtrap, it is real and I read it.
Keith Thompson
[...]
> One possibility the C and C++ committees will have to explore is simply
> rounding out the consequences of having an implementation where float,
> double, and long double are these new decimal formats instead of binary
> IEEE 754 and its ilk. That's a *very* lightweight change, from a language
> point of view, because the C Standard already permits decimal floating
> point. The folks who have to do the heavy lifting are us library
> implementors, who have many math functions to convert over. (We'll have
> to do that for *any* approach.)
Hmm. I'm a bit skeptical that the existing floating-point types can
be made decimal without breaking existing code, especially scientific
code. No, the standard doesn't guarantee that the existing types are
binary, but it's a common assumption.
My concern is that existing code, compiled with a new compiler, could
produce subtly different results.
One obvious solution would be to provide, say, a command-line option
that makes the predefined types binary, but then the semantics of the
program would depend on the source code plus the command-line options.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
(Note new e-mail address)
Douglas A. Gwyn
> My bias is that decimal arithmetic is more the domain of Cobol and
> PL/I. Perhaps it is time to add this support to other popular
> languages. My first thought was "OK, add it to C++. It should be
> relatively easy. Programmers who want decimal f.p. can use C++. C is
> more for system routines and embedded applications that don't have much
> demand for decimal f.p."
That is wrong. Consider ATMs, pay phones, etc. - anywhere
money is involved. It would be nuts to insist that such
embedded systems must use COBOL or PL/I. And anyway, with
the advent of decimal-f.p.-only processor chips, the issue
has to be faced by the (C, C++) language standards.
See the on-line presentation(s).
Dan Pop
>A slightly heavier possibility, which is more what IBM has proposed, is
>to introduce decimal floating point alongside whatever the builtin
>floating-point types currently provide. Doing that requires either adding
>three more builtin floating-point types (certainly in C, possibly also in
>C++),
This is, by far, the cleanest approach. Introduce something like
dfloat, ddouble and long ddouble and <dmath.h> and make them optional
(a macro in the implementation name space will indicate whether the
implementation supports them or not).
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan...@ifh.de
David R Tribble
>> Exactly how the C standard will accommodate this is still an
>> open question; we might simply revise the floating-point model
>> to allow float, double, and long double to use decimal
>> representation, [...]
Ben Pfaff <b...@cs.stanford.edu> wrote
>> Doesn't it already? FLT_RADIX is constrained to be greater than
>> or equal to 2, which doesn't preclude decimal representation
>> as far as I can tell.
P.J. Plauger <p...@dinkumware.com> wrote
> Basically, yes. But there are a few extra functions that make sense
> for this particular decimal floating-point representation. We should
> at least add those. And there's yet another rounding mode to add to
> the <fenv.h> machinery. Stuff like that.
What about decimal integer types working alongside the regular binary
integer types? Granted, not all architectures support them, but for those
that do, there is no standard syntax to get at them. Or is this considered
a subset of decimal floating-point types?
I believe IBM provides a 'decimal' keyword in their OS/390 C compiler for
just this sort of thing.
I attempted to draft a proposal many years ago for adding decimal integer
types to C. But I quickly got bogged down in issues of truncation,
overflow, conversion to binary integer types, minimum values for 'long',
'short', and 'plain' decimal types, invalid representations, normalization,
signed/unsigned representations, etc. It's not a simple subject.
-drt
P.S. Welcome back to CUJ!
Douglas A. Gwyn
> This is, by far, the cleanest approach. Introduce something like
> dfloat, ddouble and long ddouble and <dmath.h> and make them optional
> (a macro in the implementation name space will indicate whether the
> implementation supports them or not).
Unfortunately there are good arguments against that approach.
Ultimately the specification will be the result of negotiating
a consensus on the right balance among the competing factors.
Jonathan Leffler
> Dan Pop wrote:
>> This is, by far, the cleanest approach. Introduce something like
>> dfloat, ddouble and long ddouble and <dmath.h> and make them optional
>> (a macro in the implementation name space will indicate whether the
>> implementation supports them or not).
>
> Unfortunately there are good arguments against that approach.
Are you willing to discuss those arguments here - or provide a URL so
that we can see what they are?
--
Jonathan Leffler #include <disclaimer.h>
Email: jlef...@earthlink.net, jlef...@us.ibm.com
Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/
Keith Thompson
> Dan Pop wrote:
> > This is, by far, the cleanest approach. Introduce something like
> > dfloat, ddouble and long ddouble and <dmath.h> and make them optional
> > (a macro in the implementation name space will indicate whether the
> > implementation supports them or not).
>
> Unfortunately there are good arguments against that approach.
> Ultimately the specification will be the result of negotiating
> a consensus on the right balance among the competing factors.
Decimal floating-point isn't intended to *replace* binary
floating-point, is it?
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
(Note new e-mail address)
Thad Smith
and C++, I began
thinking more generally about the process of standardizing useful
features, I wonder if it is time to put effort into standardizing on two
(or possibly more) distinct levels: the core language, which should be
fairly stable, and add-on packages to suit various applications, such as
financial calculations.
There are many other such application types that would benefit from
extensions and standardization as have been mentioned here: extended
time/calendar calculations, extended scientific calculations, file
system control, external binary formatting, multi-threaded control, GUI
support, etc. Does it make sense to standardize these? I think so.
Does it make sense to attempt to put these all in one language
standard? I doubt it. I think the standard becomes too complex and
cumbersome.
Yes, there are add-on libraries to address these extended needs. Some
of these attempt to define a standard. Many are primarily targeted to
specific platforms and don't port well or are simply ignored when
implementing something for a different platform, vendor, etc.
Does a two-tiered system for standardization make sense? Will it work?
Has it been shown to work or fail in other instances?
Thad
Brian Inglis
<f...@cs.mu.oz.au> wrote:
>Ben Pfaff <b...@cs.stanford.edu> writes:
>
>>"Douglas A. Gwyn" <DAG...@null.net> writes:
>>
>>> Exactly how the C standard will accommodate this is still an
>>> open question; we might simply revise the floating-point model
>>> to allow float, double, and long double to use decimal
>>> representation, [...]
>>
>>Doesn't it already? FLT_RADIX is constrained to be greater than
>>or equal to 2, which doesn't preclude decimal representation
>>as far as I can tell.
>
>In theory, perhaps; but in practice, no, because backwards compatibility,
>binary compatibility, and compatibility with other standards would prevent
>implementations from defining `float' and `double' with decimal
>representations. The only feasible way of supporting decimal floating
>point in C would be for it to be a new type, rather than replacing one
>of the existing types.
Not at all -- IBM M/F 360/370/390 native compilers use FLT_RADIX 16 --
and newer systems also support IEEE FP -- so supporting another FP
option would only be a SMOP.
Has any machine ever supported *hardware* *decimal* *floating point*
arithmetic? Not *fixed* (un-/packed) decimal arithmetic, which
requires the programmer or compiler and library to do the scaling, and
not software decimal floating point.
--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
Brian....@CSi.com (Brian dot Inglis at SystematicSw dot ab dot ca)
fake address use address above to reply