why still use C?

[cody]

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

i 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

[Dan Pop]

In <bn**********@titan.btinternet.com> Richard Heathfield <do******@address.co.uk.invalid> writes:

James Kuyper wrote:

Richard Heathfield <do******@address.co.uk.invalid> wrote in message
news:<bn**********@hercules.btinternet.com>...

James Kuyper wrote:
<snip>
> "Correct code for that implementation" is "correct code", for that
> implementation. The fact that it's not portable doesn't make it
> incorrect.

MMMV. :-)

I don't recognize that one. Sorry.

My Mileage May Vary. (That is, I don't happen to share your opinion on the
matter of whether non-portable code is correct C code.)

Then, you're at odds with the C standard itself:

3 A program that is correct in all other aspects, operating on
correct data, containing unspecified behavior shall be a correct
program and act in accordance with 5.1.2.3.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Dan Pop]

In <bn**********@titan.btinternet.com> Richard Heathfield <do******@address.co.uk.invalid> writes:

Irrwahn Grausewitz wrote:

Richard Heathfield <do******@address.co.uk.invalid> wrote:

Irrwahn Grausewitz wrote:

Joona I Palaste <pa*****@cc.helsinki.fi> wrote:

>Default User <fi********@boeing.com.invalid> scribbled the following:
>> Joona I Palaste wrote:
>>> My Mileage May Vary.
>
>> Do they still say "mileage" in the UK? Shouldn't it be kilometerage?
>
>I've been to the UK, and trust me, they're as Imperial there as the
>folks in the USA. Only difference is, the UK government pretends they're
>a metric country.

Yes, and they measure speed in furlongs per fortnight. :)

This is absolutely false. The UK has no use for such large units.

You got no snails in the UK? :)

We have snails, but not turbosnails.

You mean, British snails can't do 0.166 millimeters per second? ;-)

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Fergus Henderson]

"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> writes:

On Mon, 27 Oct 2003, Fergus Henderson wrote:

** The implementation of this macro looks like it dereferences
** a null pointer, but because that code is inside sizeof(), it will
** not get executed; the compiler will instead just check that it is
** type-correct.
Chapter and verse, please.

C99 6.5.3.4 [#2]:

... If the type of the operand is a variable length array type,
the operand is evaluated; otherwise, THE OPERAND IS NOT EVALUATED ...

#define CHECK_EXPR_TYPE(expr, type) \
((void) sizeof(*(type *)NULL = (expr)))

Note that this code is not very general; it doesn't work for e.g.

CHECK_EXPR_TYPE(foo, int(*)[5]);

So use typedefs.

/*
** CAST_TO_FROM(expr, srctype, desttype):
** The same as EXPR cast to type DESTTYPE,
** except that it checks that the expression has a type which is
** compatible with (assignable to) SRCTYPE, forcing a compile error
** if it does not.
*/
#define CAST_FROM_TO(expr, srctype, desttype) \

Whoops!

Yes, there's a typo in the comment: it should be CAST_FROM_TO in both places.
Of course, this macro doesn't check whether srctype itself
is implicitly convertible to desttype, so you could use it
to "safely" convert 'double' to 'int *' if you wanted. We
can't have everything.

The macro is called CAST_FROM_TO(), not SAFE_CAST() ;-)

--
Fergus Henderson <fj*@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.

[Fergus Henderson]

[Posted to newsgroups comp.lang.c and comp.std.c, and also emailed to
the GCC mailing list <gc*@gcc.gnu.org>.]

ku****@wizard.net (James Kuyper) writes:

Fergus Henderson <fj*@cs.mu.oz.au> wrote in message news:<3f********@news.unimelb.edu.au>...

>"E. Robert Tisdale" wrote:
>> > cat malloc89.c
>> int main(int arc, char* argv[]) {
>> char* p = malloc(10);
>> return 0;
>> }
>>
>> > gcc -Wall -std=c89 -pedantic -O2 -o malloc89 malloc89.c
>> malloc89.c: In function `main':
>> malloc89.c:2: warning: implicit declaration of function `malloc'
>> malloc89.c:2: warning: initialization makes pointer from integer
>> without a cast
>> malloc89.c:2: warning: unused variable `p'
>>
>> The "initialization makes pointer from integer without a cast" warning
>> is cryptic and misleading.

Yes. I don't recall whether I ever originally found such messages
confusing myself, but I have definitely witnessed other people being
confused by them.

.... The compiler should treat implicit int differently than an explicitly
declared int, and should special-case error/warning messages for conversions
from implicit int.
It did:

the warnings started with "implicit declaration of function `malloc'".
In *this particular case*, the warning about implicit function declaration
comes immediately before the cryptic warning about conversion from int,
which helps a bit.

But it doesn't help as much as it could. And it can get much worse than
this case. The two warnings are quite separate warnings, and they can
occur on different lines of code and can be separated by arbitrarily
many other warnings in between. Also, if you don't use `-Wall', then
you only get the cryptic second warning.

E.g.
char *foo() { return (char *) malloc(1); }
void bar() { return 42; }
int *baz() { return malloc(2); }

$ gcc -c a.c
a.c: In function `bar':
a.c:2: warning: `return' with a value, in function returning void
a.c: In function `baz':
a.c:3: warning: return makes pointer from integer without a cast

$ gcc -Wall -c a.c
a.c: In function `foo':
a.c:1: warning: implicit declaration of function `malloc'
a.c: In function `bar':
a.c:2: warning: `return' with a value, in function returning void
a.c: In function `baz':
a.c:3: warning: return makes pointer from integer without a cast

Many C programmers are either not aware that undeclared functions are
implicitly declared to return `int' or just don't make the connection,
and thus find the error message confusing.
That treats implicit int differently from an explicitly
declared int, and constitutes all of the special-casing that's needed
to clarify the warning about the conversion from int.

I don't agree. I think the diagnostics would be clearer if it explicitly
said that the integer mentioned in the second warning was the default
return type of the implicitly declared malloc function.

E.g.
a.c:3: warning: return makes pointer from int return value of
implicitly-declared function `malloc' without a cast

--
Fergus Henderson <fj*@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.

[Dave Hansen]

On Wed, 29 Oct 2003 13:13:08 GMT, Fergus Henderson <fj*@cs.mu.oz.au>
wrote:

[...]

CHECK_EXPR_TYPE(foo, int(*)[5]);

So use typedefs.

<shudder>

Typedefing arrays is _evil_.

Regards,

-=Dave
--
Change is inevitable, progress is not.

[Richard Heathfield]

Dan Pop wrote:

In <bn**********@titan.btinternet.com> Richard Heathfield
<do******@address.co.uk.invalid> writes:

(That is, I don't happen to share your opinion on the
matter of whether non-portable code is correct C code.)

Then, you're at odds with the C standard itself:

Yes, I know. That doesn't change my opinion on this occasion.

--
Richard Heathfield : bi****@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

[Richard Heathfield]

Dan Pop wrote:

In <bn**********@titan.btinternet.com> Richard Heathfield
<do******@address.co.uk.invalid> writes:

We have snails, but not turbosnails.

You mean, British snails can't do 0.166 millimeters per second? ;-)

Not the ones I've seen in the garden (*except* when my sons are "driving"
them around a home-made race-track). :-)
--
Richard Heathfield : bi****@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

[Irrwahn Grausewitz]

Richard Heathfield <do******@address.co.uk.invalid> wrote:

Dan Pop wrote:

You mean, British snails can't do 0.166 millimeters per second? ;-)

Not the ones I've seen in the garden (*except* when my sons are "driving"
them around a home-made race-track). :-)

Err, you don't grow, umm, 'special' plants in your garden, do you? ;-)
--
Irrwahn
(ir*******@freenet.de)

[goose]

Irrwahn Grausewitz <ir*******@freenet.de> wrote in message news:<5h********************************@4ax.com>. ..

Richard Heathfield <do******@address.co.uk.invalid> wrote:

Dan Pop wrote:

You mean, British snails can't do 0.166 millimeters per second? ;-)

Not the ones I've seen in the garden (*except* when my sons are "driving"
them around a home-made race-track). :-)

Err, you don't grow, umm, 'special' plants in your garden, do you? ;-)

must be the /special/ chemical fertilizers ;-)
goose,

[James Kuyper]

Fergus Henderson <fj*@cs.mu.oz.au> wrote in message news:<3f********@news.unimelb.edu.au>...

[Posted to newsgroups comp.lang.c and comp.std.c, and also emailed to
the GCC mailing list <gc*@gcc.gnu.org>.]

ku****@wizard.net (James Kuyper) writes:

Fergus Henderson <fj*@cs.mu.oz.au> wrote in message news:<3f********@news.unimelb.edu.au>... ....

The compiler should treat implicit int differently than an explicitly
declared int, and should special-case error/warning messages for conversions
from implicit int.
It did:

the warnings started with "implicit declaration of function `malloc'".

.... this case. The two warnings are quite separate warnings, and they can
occur on different lines of code and can be separated by arbitrarily
many other warnings in between. ...
I learned this a long time ago, within my first year as a professional
programmer: resolve the first problem reported by your compiler,
before even bothering to look at the ones after it. The first problem
may be causing the later ones, and will often render the later
messages confusing, as it does in this case.
... Also, if you don't use `-Wall', then

.... you get what you asked for: the inadequate warnings that are the
default for that compiler.

[James Kuyper]

id**@hotmail.com (Dave Hansen) wrote in message news:<3f*****************@News.CIS.DFN.DE>...
....

Typedefing arrays is _evil_.

Would you elaborate? I've seldom had the need, but I don't see the evil in it.

[Dave Hansen]

On 30 Oct 2003 08:20:29 -0800, ku****@wizard.net (James Kuyper) wrote:

id**@hotmail.com (Dave Hansen) wrote in message news:<3f*****************@News.CIS.DFN.DE>...
...

Typedefing arrays is _evil_.

Would you elaborate? I've seldom had the need, but I don't see the evil in it.

Mainly because it acts like an array, but doesn't look like one.
Consider the folowing:

--- begin included file ---

C:\Dave>type tda.c
#include <stdio.h>
#include <string.h>

typedef char Evil[10];
typedef struct{Evil data;} Not_So_Evil;

void test(Evil one, Not_So_Evil two)
{
unsigned s1,s2;

s1 = sizeof(Evil);
s2 = sizeof one;

printf("In test, sizeof(Evil) is %u while "
"sizeof one is %u\n", s1, s2);

s1 = sizeof(Not_So_Evil);
s2 = sizeof(two);

printf("sizeof(Not_So_Evil) is %u while sizeof two is %u\n",s1,s2);

strcpy(one,"Clobber!");
strcpy(two.data, "Clobber!");
}

int main(void)
{
Evil one;
Not_So_Evil two;

unsigned s1,s2;

strcpy(one, "Untouched");
strcpy(two.data, "Untouched");

printf("Before test, one is %s, two is %s\n", one, two.data);

s1 = sizeof(Evil);
s2 = sizeof one;

printf("In main, sizeof(Evil) is %u while "
"sizeof one is %u\n", s1, s2);

s1 = sizeof(Not_So_Evil);
s2 = sizeof(two);

printf("sizeof(Not_So_Evil) is %u while sizeof two is %u\n",s1,s2);

test(one,two);

printf("After test, one is %s, two is %s\n", one, two.data);

return 0;
}

C:\Dave>gcc -ansi -pedantic -Wall tda.c

C:\Dave>a
Before test, one is Untouched, two is Untouched
In main, sizeof(Evil) is 10 while sizeof one is 10
sizeof(Not_So_Evil) is 10 while sizeof two is 10
In test, sizeof(Evil) is 10 while sizeof one is 4
sizeof(Not_So_Evil) is 10 while sizeof two is 10
After test, one is Clobber!, two is Untouched

C:\Dave>
--- end included file ---

Regards,

-=Dave
--
Change is inevitable, progress is not.

[Dave Thompson]

On Mon, 27 Oct 2003 18:37:06 +0000 (UTC), Richard Heathfield
<do******@address.co.uk.invalid> wrote:

James Kuyper wrote:

<snip: C to C++ incompatibilities>

14. Any use of an enumeration. Different enumeration types can have
different sizes and representations in C++, which would make virtually
any use of them in a header file context dangerous.

I don't /think/ this is a problem for me, but thanks for the warning.

This is actually *possible* in C, but less likely. The difference is
that C++ allows enum values to exceed int and thus force
implementation like long, while in C it is always legal and usually
most time-efficient, though not (data-)space-efficient, to implement
all enum types like int.

But I see no danger if you use enum types as distinct types rather
than just named integers, which C++ enforces although C does not.

- David.Thompson1 at worldnet.att.net

[Douglas A. Gwyn]

cody wrote:

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

Wrong.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Arthur J. O'Dwyer]

On Thu, 7 Nov 2003, Douglas A. Gwyn wrote:

[a response to a message posted here on Oct 7]

See, this is why I snip c.l.c.moderated from follow-ups
whenever I remember to do it. Cross-posting between
moderated and unmoderated groups is a recipe for
unintelligible conversations, IMHO.
Does anyone more experienced in the ways of Usenet
know a way to keep both the original cross-post list
(including both c.l.c and c.l.c.m) *AND* get one's
message to show up in the unmoderated groups in a
reasonable amount of time? I assume the usual
dominant factor is how long it takes the c.l.c.m
moderator to check his mail, in this case...

-Arthur

[Casper H.S. Dik]

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes:

Can you show us an example of a "system"
on which this happens *not* to work?

Solaris 7+, SPARC, 64 bit code, Sun C compiler.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

[Casper H.S. Dik]

Keith Thompson <ks*@cts.com> writes:

The macros look fine, but the casts are still unnecessary and
potentially dangerous. Why not just #define NEW(type) \
(malloc(sizeof(type)))

The use of macros to "hide" standard constructs is not "fine" by any
definition of "fine" that I can think of.

It makes the code *harder* to understand for other people.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

[pete]

Casper H.S. Dik wrote:

Keith Thompson <ks*@cts.com> writes:

The macros look fine, but the casts are still unnecessary and
potentially dangerous. Why not just

#define NEW(type) \
(malloc(sizeof(type)))

The use of macros to "hide" standard constructs is not "fine" by any
definition of "fine" that I can think of.

It makes the code *harder* to understand for other people.

I agree.
If you know C, you know (malloc(sizeof(type))).
NEW is something that you have to look up and remember,
when you see it in a .c file.
When you see NEW in another .c file,
by the same author, in the same program,
you still have to check what NEW means,
either by seeing if NEW is identically defined in both .c files,
or if the same .h file which defines NEW is included in both .c files,
or maybe NEW doesn't mean the same thing in both files.

--
pete

[Harti Brandt]

On Fri, 7 Nov 2003, Casper H.S. Dik wrote:

CHD>Keith Thompson <ks*@cts.com> writes:
CHD>
CHD>>The macros look fine, but the casts are still unnecessary and
CHD>>potentially dangerous. Why not just
CHD>
CHD>> #define NEW(type) \
CHD>> (malloc(sizeof(type)))
CHD>
CHD>
CHD>
CHD>The use of macros to "hide" standard constructs is not "fine" by any
CHD>definition of "fine" that I can think of.
CHD>
CHD>It makes the code *harder* to understand for other people.

Definitely. Look at unix v7 sh source for an example...

harti
--
harti brandt,
http://www.fokus.fraunhofer.de/resea...brandt/private
br****@fokus.fraunhofer.de, ha***@freebsd.org

[E. Robert Tisdale]

Casper H.S. Dik wrote:

Keith Thompson <ks*@cts.com> writes:

The macros look fine, but the casts are still unnecessary and
potentially dangerous. Why not just

#define NEW(type) \
((type *)malloc(sizeof(type)))

The use of macros to "hide" standard constructs is not "fine" by any
definition of "fine" that I can think of.

It makes the code *harder* to understand for other people.

Nonsense!

Using a functor ([inline] function call, C preprocessor macro, etc.)
is *always* preferable to inlining functions manually.

[Alan Balmer]

On Fri, 07 Nov 2003 10:39:49 -0800, "E. Robert Tisdale"
<E.**************@jpl.nasa.gov> wrote:

Casper H.S. Dik wrote:

Keith Thompson <ks*@cts.com> writes:

The macros look fine, but the casts are still unnecessary and
potentially dangerous. Why not just

#define NEW(type) \
((type *)malloc(sizeof(type)))

The use of macros to "hide" standard constructs is not "fine" by any
definition of "fine" that I can think of.

It makes the code *harder* to understand for other people.

Nonsense!

Using a functor ([inline] function call, C preprocessor macro, etc.)
is *always* preferable to inlining functions manually.

Nonsense!
It's not a function, it's a function *call*.

When I see "malloc" in a program, I know what it means. When I see
"NEW" in a program, I have no idea what it might be until I go find
the definition.

--
Al Balmer
Balmer Consulting
re************************@att.net

[Douglas A. Gwyn]

Harti Brandt wrote:

Definitely. Look at unix v7 sh source for an example...

He's referring to Bourne's use of macros to make the source more
resemble Algol, e.g.
IF whatever THEN blah; FI
Except for being upper-case, it's not really harder to read, and
it makes certain kinds of coding errors less likely (since the
macros always enforce use of compound statements). Having said
that, I agree that there is no pressing need to do this.

[Richard Tobin]

In article <3f***********************@news.xs4all.nl>,
Casper H.S. Dik <Ca********@Sun.COM> wrote:

The use of macros to "hide" standard constructs is not "fine" by any
definition of "fine" that I can think of.

It makes the code *harder* to understand for other people.

For other people not familiar with the code, yes.

But if it makes the code more readable for people who are familiar
with it and have to deal with it regularly - and I find some such
macros do - then maybe that outweighs the disadvantage.

-- Richard
--
Spam filter: to mail me from a .com/.net site, put my surname in the headers.

FreeBSD rules!

[Francis Glassborow]

In article <cl****************@plethora.net>, Douglas A. Gwyn
<DA****@null.net> writes

cody wrote:

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.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Fergus Henderson]

id**@hotmail.com (Dave Hansen) writes:

Fergus Henderson <fj*@cs.mu.oz.au> wrote:

CHECK_EXPR_TYPE(foo, int(*)[5]);

So use typedefs.

<shudder>

Typedefing arrays is _evil_.

Not if the typedef name ends in "_array".

--
Fergus Henderson <fj*@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.

[Casper H.S. Dik]

ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:

But if it makes the code more readable for people who are familiar
with it and have to deal with it regularly - and I find some such
macros do - then maybe that outweighs the disadvantage.

But over time such actions make the maintenance cost of your
software higher; not lower; new employees need more time to
come up to speed. Such effects can be considerable.
(Plus their job skills deteriorate; they become less useful for
others because such habits need to be unlearned)

On the subject of this thread: in my experience, C++ code is much
harder to maitain because of "over objectification". Rather than
a simple "initialize object", people go overboard, define to many
subclasses and before you know it you need to read 10 source files
to understand one line of code.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

[Richard Tobin]

In article <3f***********************@news.xs4all.nl>,
Casper H.S. Dik <Ca********@Sun.COM> wrote:

But over time such actions make the maintenance cost of your
software higher; not lower; new employees need more time to
come up to speed. Such effects can be considerable.
Quite likely for commercial software products with long lifetimes
written by large companies. Of course, not all programs are like
that.
Rather than
a simple "initialize object", people go overboard, define to many
subclasses and before you know it you need to read 10 source files
to understand one line of code.

That's certainly very true. I have tried to modify a widely-used
piece of free software where everything happens magically as the
side-effect of calls to "new", and it was very frustrating. On the
other hand, maybe the original author only wrote it because he enjoyed
that sort of thing. And the Internet would be a very different place
if he hadn't written it.

-- Richard

--
Spam filter: to mail me from a .com/.net site, put my surname in the headers.

FreeBSD rules!

[Francis Glassborow]

In article <cl****************@plethora.net>, Thad Smith
<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.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Douglas A. Gwyn]

Thad Smith wrote:

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.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Fred J. Tydeman]

Thad Smith wrote:

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
ty*****@tybor.com Programming, testing, numerics
[phone] Vice-chair of J11 (ANSI "C")
Sample C99+FPCE tests: ftp://jump.net/pub/tybor/
Savers sleep well, investors eat well, spenders work forever.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[P.J. Plauger]

"Thad Smith" <th**@ionsky.com> wrote in message
news:cl****************@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.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Fergus Henderson]

Casper H.S. Dik <Ca********@Sun.COM> writes:

Keith Thompson <ks*@cts.com> writes:

The macros look fine, but the casts are still unnecessary and
potentially dangerous. Why not just

#define NEW(type) \
(malloc(sizeof(type)))

The use of macros to "hide" standard constructs is not "fine" by any
definition of "fine" that I can think of.

Sure, if that is the only purpose. But as discussed in this thread,
the purpose here is to improve type-safety.

Most C programmers will be familiar with the use of "new" in C++, Java,
or C#, so this technique of using a "NEW" macro like the one above is
generally very easy to grasp. That, incidentally, is why I slightly
prefer this approach to the other approach suggested in this thread:

#define ALLOC(obj) \
(obj = malloc(sizeof(*obj)))

--
Fergus Henderson <fj*@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.

[Marc Espie]

In article <cl****************@plethora.net>,
Francis Glassborow <fr*****@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).
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Thad Smith]

"P.J. Plauger" wrote:

"Thad Smith" <th**@ionsky.com> wrote in message
news:cl****************@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
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Ben Pfaff]

"Douglas A. Gwyn" <DA****@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.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Fred J. Tydeman]

"Fred J. Tydeman" wrote:

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

---
Fred J. Tydeman Tydeman Consulting
ty*****@tybor.com Programming, testing, numerics
[phone] Vice-chair of J11 (ANSI "C")
Sample C99+FPCE tests: ftp://jump.net/pub/tybor/
Savers sleep well, investors eat well, spenders work forever.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Chris Hills]

In article <cl****************@plethora.net>, Thad Smith
<th*******@acm.org> writes

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 \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Fergus Henderson]

Ben Pfaff <bl*@cs.stanford.edu> writes:

"Douglas A. Gwyn" <DA****@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 <fj*@cs.mu.oz.au> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Hans-Bernhard Broeker]

In comp.lang.c.moderated Marc Espie <es***@tetto.gentiane.org> wrote:
[...]

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 (br*****@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Francis Glassborow]

In article <cl****************@plethora.net>, Ben Pfaff
<bl*@cs.stanford.edu> writes

"Douglas A. Gwyn" <DA****@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.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[P.J. Plauger]

"Thad Smith" <th*******@acm.org> wrote in message
news:cl****************@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
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[P.J. Plauger]

"Ben Pfaff" <bl*@cs.stanford.edu> wrote in message
news:cl****************@plethora.net...

"Douglas A. Gwyn" <DA****@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
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Thad Smith]

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?

Thad
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Mark Gordon]

On 11 Nov 2003 07:19:55 GMT
Thad Smith <th*******@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.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Keith Thompson]

"P.J. Plauger" <pj*@dinkumware.com> writes:
[...]

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)
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Douglas A. Gwyn]

Thad Smith wrote:

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).
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Dan Pop]

In <cl****************@plethora.net> "P.J. Plauger" <pj*@dinkumware.com> writes:

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: Da*****@ifh.de
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[David R Tribble]

Douglas A. Gwyn <DA****@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, [...]
Ben Pfaff <bl*@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 <pj*@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!
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Douglas A. Gwyn]

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.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Jonathan Leffler]

Douglas A. Gwyn wrote:

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: jl******@earthlink.net, jl******@us.ibm.com
Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/
--
comp.lang.c.moderated - moderation address: cl**@plethora.net