By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,105 Members | 2,541 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,105 IT Pros & Developers. It's quick & easy.

Is C99 the final C?

P: n/a
I was just thinking about this, specifically wondering if there's any
features that the C specification currently lacks, and which may be
included in some future standardization.

Of course, I speak only of features in the spirit of C; something like
object-orientation, though a nice feature, does not belong in C.
Something like being able to #define a #define would be very handy,
though, e.g:

#define DECLARE_FOO(bar) #define FOO_bar_SOMETHING \
#define FOO_bar_SOMETHING_ELSE

I'm not sure whether the features of cpp are even included in the C
standard though (and GCC has definitely taken quite a nonstandard approach
with regards to certain token expansions and whatnot), but that's one area
of improvement I see.

I would also like to see something along the lines of C++ templating,
except without the really kludgy implementation that the C++ folks decided
to go to ( and without the OOP ).

.... Mike pauses for the sound of a thousand *plonks*

Templates save a lot of time when it comes to commonly-used data
structures, and as they are entirely implemented at compile-time and don't
include, by their definition, OOP (although they can be well suited to
it), I think they would be a nice addition and in the spirit of C.

Your thoughts? I'm sure there's some vitriol coming my way but I'm
prepared 8)

--
Mike's Patented Blocklist; compile with gcc:

i=0;o(a){printf("%u",i>>8*a&255);if(a){printf(".") ;o(--a);}}
main(){do{o(3);puts("");}while(++i);}

Nov 13 '05 #1
Share this Question
Share on Google+
193 Replies


P: n/a
Michael B. wrote:
I was just thinking about this, specifically wondering if there's any
features that the C specification currently lacks, and which may be
included in some future standardization.


Of course there are. Can you imagine that people will /ever/ stop
fixing things just because they ain't broke?
--
Morris Dovey
West Des Moines, Iowa USA
C links at http://www.iedu.com/c
Read my lips: The apple doesn't fall far from the tree.

Nov 13 '05 #2

P: n/a
Morris Dovey wrote:
Michael B. wrote:
I was just thinking about this, specifically wondering if there's any
features that the C specification currently lacks, and which may be
included in some future standardization.

Of course there are. Can you imagine that people will /ever/ stop fixing
things just because they ain't broke?


There was a quote some years ago, I believe by one of the authors of the
original Fortran compiler, though it is hard to verify the source.
Something like:

"I don't know what the language of the year 2000 will look like, but it
will be called Fortran." (That is from memory, hopefully it is close.)

There is now, I believe, a Fortran 2003 that has very little in common
with the Fortran of 1954 or so. What will C look like when it is 50
years old?

I might prefer a new language rather than an extension of an existing one.

-- glen

Nov 13 '05 #3

P: n/a
in comp.lang.c i read:
Michael B. wrote:

I was just thinking about this, specifically wondering if there's any
features that the C specification currently lacks, and which may be
included in some future standardization.


Of course there are. Can you imagine that people will /ever/ stop
fixing things just because they ain't broke?


yes. (cf the pl/i standard)

--
a signature
Nov 13 '05 #4

P: n/a
in comp.lang.c i read:
I'm not sure whether the features of cpp are even included in the C
standard
all of them.
I would also like to see something along the lines of C++ templating,
except without the really kludgy implementation that the C++ folks decided
to go to ( and without the OOP ).


hard to see how you can do this properly without a pile of other stuff, but
if you've got an idea that makes sense advance it here, or to your national
body and see if they like it. you could even get involved in the standards
process yourself, though that's costly and too often thankless.

--
a signature
Nov 13 '05 #5

P: n/a
On Sat, 29 Nov 2003 17:19:59 -0800, "Michael B."
<us*****@spamblocked.com> wrote in comp.lang.c:
I was just thinking about this, specifically wondering if there's any
features that the C specification currently lacks, and which may be
included in some future standardization.
Wrong newsgroup, actually. The one that discusses the past, present,
and future of the C standard is news:comp.std.c.
Of course, I speak only of features in the spirit of C; something like
object-orientation, though a nice feature, does not belong in C.
Something like being able to #define a #define would be very handy,
though, e.g:

#define DECLARE_FOO(bar) #define FOO_bar_SOMETHING \
#define FOO_bar_SOMETHING_ELSE
I strongly disagree. This sort of thing only obfuscates code and
makes maintenance a nightmare.
I'm not sure whether the features of cpp are even included in the C
standard though (and GCC has definitely taken quite a nonstandard approach
with regards to certain token expansions and whatnot), but that's one area
of improvement I see.
If you are not aware of what is or is not in the current C standard,
that severely reduces the worth of any suggestions you make about
future changes or additions to that standard. There are a few, but
only a few, things about the preprocessor that are unspecified by the
standard.
I would also like to see something along the lines of C++ templating,
except without the really kludgy implementation that the C++ folks decided
to go to ( and without the OOP ).
I would like to see the next standard mandate that the compiler
generate code to do exactly what I meant, even when the code I typed
does not match that meaning. Expressing a thought like the one you
did in the paragraph above is truly meaningless. Where is the
analysis about what effort it would take on the part of compiler
writers to add this feature to the language? What existing code what
it break or not break? Can you provide a sample implementation to
show how it would work?

I could wish that pigs had wings so they could fly, but unless I can
come up with at least some solid engineering plans that showed
feasibility and a favorable cost-benefit ration, I would not expect
anyone to take my wish seriously.
... Mike pauses for the sound of a thousand *plonks*
Sorry to disappoint you, but I don't plonk off-topic posters unless
they are persistently off-topic or insulting.
Templates save a lot of time when it comes to commonly-used data
structures, and as they are entirely implemented at compile-time and don't
include, by their definition, OOP (although they can be well suited to
it), I think they would be a nice addition and in the spirit of C.

Your thoughts? I'm sure there's some vitriol coming my way but I'm
prepared 8)


--
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
Nov 13 '05 #6

P: n/a
Michael B. wrote:
I was just thinking about this, specifically wondering if there's any
features that the C specification currently lacks, and which may be
included in some future standardization.


I think C99 has come a long way to fix the most obvious problems in C89
(and its predecessors). I for one would be happy if more compilers would
fully start to support C99, It will be a good day when I can actually
start to use many of the new features without having to worry about
portability too much, as is the current situation.

There's always some things that could be improved of course. My personal
wish-list would include (in no particular order):

* mandatory support for fixed-width integers (in C99, this is optional).

* support for a "packed" attribute to structs, guaranteeing that no
padding occurs.

* some mandatory semantics for floating-points types; e.g. the assurance
that integers between certain limits can be represented exactly in the
FP types (with associated constants in limits.h)

* deprecation of implicit casts of fp-types to integer types (perhaps
supported by a mandatory compiler warning).

* deprecation of implicit casts of void* to other pointer types (perhaps
supported by a mandatory compiler warning). This is a desire not
likely to be shared by many here, though ;-)

* upgraded status of enum types (they are currently quite
interchangeable with ints); deprecation of implicit casts from
int to enum (perhaps supported by a mandatory compiler warning).

* a clear statement concerning the minimal level of active function
calls invocations that an implementation needs to support. Currently,
recursive programs will stackfault at a certain point, and this
situation is not handled satisfactorily in the standard (it is not
adressed at all, that is), as far as I can tell.

* a library function that allows the retrieval of the size of a memory
block previously allocated using "malloc"/"calloc"/"realloc" and
friends.

* a #define'd constant in stdio.h that gives the maximal number of
characters that a "%p" format specifier can emit. Likewise, for
other format specifiers such as "%d" and the like.

* a printf format specifier for printing numbers in base-2.

* I think I would like to see a real string-type as a first-class
citizen in C, implemented as a native type. But this would open
up too big a can of worms, I am afraid, and a good case can be
made that this violates the principles of C too much (being a
low-level language and all).

* Normative statements on the upper-bound worst-case asymptotic
behavior of things like qsort() and bsearch() would be nice.
O(n*log(n)) for number-of-comparisons would be fine for qsort,
although I believe that would actually preclude a qsort()
implementation by means of the quicksort algorithm :-)

* mandatory constants for many things that currently need to
be tested by autoconf and similar tools, e.g. endianness.

* deprecate trigraphs. Let's end the madness once and for all.

* a reliable and easy way to walk over all integers in a certain
interval, including the MAX value for that type, by means of a
for loop; eg., currently

for(unsigned i=0;i<=UINT_MAX;i++) ...

doesn't work as intended.

* a "reverse comma" type expression, for example denoted by
a reverse apastrophe, where the leftmost value is the value
of the entire expression, but the right-hand side is also
guaranteed to be executed.

* triple-&& and triple-|| operators: &&& and ||| with semantics
like the 'and' and 'or' operators in python:

a &&& b ---> if (a) then b else a
a ||| b ---> if (a) then a else b

(I think this is brilliant, and actually useful sometimes).

* a way to "bitwise invert" a variable without actually
assigning, complementing "&=", "|=", and friends.

* 'min' and 'max' operators (following gcc: ?< and ?>)

* a div and matching mod operator that round to -infinity,
to complement the current less useful semantics of rounding
towards zero.

These are just some thoughts. Maybe there are perfectly good reasons why
some of these are a bad idea, I would be interested to hear this.

Personally, I don't think it would be a good idea to have templates in
C, not even simple ones. This is bound to have quite complicated
semantics that I would not like to internalize.

Best regards,

Sidney

Nov 13 '05 #7

P: n/a
"Sidney Cadot" <si****@jigsaw.nl> wrote in message
news:bq**********@news.tudelft.nl...
Variable-width arrays are nice for performance-critical code since they
can be allocated on the stack in a few clock-cycles, and their
deallocation is free on most architectures, whereas malloc()/free() may
be more expensive. I would be glad when the day arrives when I can start
using them.


What compiler do you use then that you can't use them?
Nov 13 '05 #8

P: n/a
Servé Lau wrote:
"Sidney Cadot" <si****@jigsaw.nl> wrote in message
news:bq**********@news.tudelft.nl...
Variable-width arrays are nice for performance-critical code since they
can be allocated on the stack in a few clock-cycles, and their
deallocation is free on most architectures, whereas malloc()/free() may
be more expensive. I would be glad when the day arrives when I can start
using them.

What compiler do you use then that you can't use them?


I use gcc, mainly, but the software's users use a variety of systems
(mostly win32, Linux, Sun, HP, AIX, Irix, ...), and I cannot rely on
anything better than a C89 compiler to be available.

Best regards,

Sidney
Nov 13 '05 #9

P: n/a

On Sun, 30 Nov 2003, Simon Biber wrote:

"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote:
On Sun, 30 Nov 2003, Sidney Cadot wrote:
* support for a "packed" attribute to structs, guaranteeing
that no padding occurs.


Needs elaboration. As stated, this is flatly impossible.
Even on a vanilla Win/Intel platform,

struct { char c; double d; } x;

simply *cannot* be organized to completely avoid padding.
Unless you'd just allow the compiler to throw a warning
saying "Whoops! This struct can't be 'un-padded'!" But
then you'd have implementation-defined behavior, which is
basically what we have in C99 anyway.


Surely it is possible, if you add in extra code to handle a
memcpy to and from &x.d every time you read or write to the
unaligned x.d?


I suppose that would be possible -- but it would be ugly and
inefficient, and might have odd interactions with 'volatile'.
Plus, you'd need to generate code and/or space for a "staging
area" for all these misaligned values (the targets of all these
memcpy's), and that would probably make things a little more
complicated for the linker -- which object file gets the "staging
area" and which just refer to it? or does each TU get a separate
staging area, which would be inefficient?
I just don't like it. :)

* triple-&& and triple-|| operators: &&& and ||| with
semantics like the 'and' and 'or' operators in python:

a &&& b ---> if (a) then b else a
a ||| b ---> if (a) then a else b [snip]
result = a? b: 0; /* &&& */


ITYM a ? b : a


If a is non-zero, return b; else if a is zero, return a.
If a is non-zero, return b; else if a is zero, return 0.
Means the same thing, and my way doesn't have to evaluate
a two times, so it's macro-safe.
(result = a) && (result = b); /* ||| */


Or just a ? a : b


Ditto the above comment about macro-safety, although
I guess my way does evaluate 'result' twice. Bottom
line -- use whichever way makes the code do what you
want it to do. :) I don't think there's any need for
new operators here.
Oh, and just for kicks, note that the &&& operator
would break some [pathological] C code.

-Arthur
Nov 13 '05 #10

P: n/a
On Sun, 30 Nov 2003 14:37:28 +0100
Sidney Cadot <si****@jigsaw.nl> wrote:
Arthur J. O'Dwyer wrote:
On Sun, 30 Nov 2003, Sidney Cadot wrote:
Michael B. wrote:
<snip>
There's always some things that could be improved of course. My
personal wish-list would include (in no particular order):

* mandatory support for fixed-width integers (in C99, this is

optional).

This would make some platforms incompatible with C; up to this
point, C has never [to my knowledge] *required* any fixed-width
data types. How about those 9-bit-byte mainframes everyone likes
to bring up?


I think their main raison-d'etre at the moment is as serving as
counter-examples in c.l.c discussions. Perhaps it is time, in the next
C version, to mandate that CHAR_BIT==8. I don't know.


Definitely not. CHAR_BIT==9 may be rare these days, but CHAR_BIT==16 is
not once you start looking at DSP processors which often don't have the
ability to access less that 16 bits (or or) in one operation.

<snip>
And I really don't see
the point of this one, although I have vague recollections that
you don't like any of C's implicit conversions (you heretic
malloc-caster, you!).


... "Burn the malloc-casting witch! Burn!" ... :-)


Requiring a diagnostic (not necessarily an error) for using unprototyped
functions might be of help.

<snip>
* upgraded status of enum types (they are currently quite
interchangeable with ints); deprecation of implicit casts from
int to enum (perhaps supported by a mandatory compiler warning).
Agreed, it would be nice for enums to be more "special." On
the other hand, the biggest use for enums is as a drop-in
replacement for #defined integer constants, and I don't want to lose
that capability. (Yes, "constant" consts would fix *that* problem,
but that would basically turn C compilers into C++ compilers on a
complexity scale.


The last statement I do not understand. Care to elaborate?


Something like

fancy_enum { fred=32, george=23 } bar;
bar = fred;
bar++; /* bar nor equals george */

possibly?
* a reliable and easy way to walk over all integers in a certain
interval, including the MAX value for that type, by means of a
for loop; eg., currently

for(unsigned i=0;i<=UINT_MAX;i++) ...

doesn't work as intended.

What do you suggest? A new looping construct? :-) This is
an artifact of the way C handles numbers, and it won't go away
by wishing. Better to use one of the myriad ways already
standardized, e.g.

i = 0;
do {
...
} while (++i != 0);

Ugly, but functional. And I'm sure this is a FAQ anyway.


This can work for unsigned types, but I'm not so sure if a similar
thing
can work portably for signed types.


<snip>

i=0;
while (1) {
/* do stuff */
if (i==INT_MAX) break; /* or whatever other MAX */
i++;
}

Even uglier but safe for signed types.
--
Mark Gordon
Paid to be a Geek & a Senior Software Developer
Although my email address says spamtrap, it is real and I read it.
Nov 13 '05 #11

P: n/a

On Sun, 30 Nov 2003, Mark Gordon wrote:

Sidney Cadot <si****@jigsaw.nl> wrote:
Arthur J. O'Dwyer wrote:
On Sun, 30 Nov 2003, Sidney Cadot wrote:
>* upgraded status of enum types (they are currently quite
> interchangeable with ints); deprecation of implicit casts from
> int to enum (perhaps supported by a mandatory compiler warning).
Agreed, it would be nice for enums to be more "special." On
the other hand, the biggest use for enums is as a drop-in
replacement for #defined integer constants, and I don't want to lose
that capability. (Yes, "constant" consts would fix *that* problem,
but that would basically turn C compilers into C++ compilers on a
complexity scale.


The last statement I do not understand. Care to elaborate?


const int foo = 5;
char arr[foo];

Legal C++ (because in C++, const objects are really "constant"),
but illegal C (because 'foo' is an object whose value needn't
be stored [or even computed] at compile time). I think C's way
is easier for me to grasp. And I think (but this is just IMH
and uneducated O) that C++ compilers need a lot of extra baggage
to deal with constant "consts," and I wouldn't want to foist all
that on C compilers.
Something like

fancy_enum { fred=32, george=23 } bar;
bar = fred;
bar++; /* bar now equals george */

possibly?
Ooh, that would just be ugly and mean. ;)

i=0;
while (1) {
/* do stuff */
if (i==INT_MAX) break; /* or whatever other MAX */
i++;
}

Even uglier but safe for signed types.


Except possibly for flavors of 'char', why would anyone want to
walk over all values of a type anyway? Solving equations by
exhaustive search? ;-)

-Arthur
Nov 13 '05 #12

P: n/a
"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote:
On Sun, 30 Nov 2003, Simon Biber wrote:
Surely it is possible, if you add in extra code to handle a
memcpy to and from &x.d every time you read or write to the
unaligned x.d?
I suppose that would be possible -- but it would be ugly and
inefficient, and might have odd interactions with 'volatile'.
Plus, you'd need to generate code and/or space for a "staging
area" for all these misaligned values (the targets of all these
memcpy's), and that would probably make things a little more
complicated for the linker -- which object file gets the "staging
area" and which just refer to it? or does each TU get a separate
staging area, which would be inefficient?
I just don't like it. :)


I don't like it either, but it would be nice to have a well-defined
way to get packed structs on any implementation. Obviously, because
of the large performance hit, you would only use the packed attribute
where it was absolutely necessary.
result = a? b: 0; /* &&& */


ITYM a ? b : a


If a is non-zero, return b; else if a is zero, return a.
If a is non-zero, return b; else if a is zero, return 0.
Means the same thing, and my way doesn't have to evaluate
a two times, so it's macro-safe.


Of course, sorry.
(result = a) && (result = b); /* ||| */


Or just a ? a : b


Ditto the above comment about macro-safety, although
I guess my way does evaluate 'result' twice. Bottom
line -- use whichever way makes the code do what you
want it to do. :) I don't think there's any need for
new operators here.


Your way is unsuitable for macro use anyway -- there is
no result object in an expression-like macro.
Oh, and just for kicks, note that the &&& operator
would break some [pathological] C code.


Like this:
int a = 1, b, *p = &b;
if(a != 0 &&& b == p)
{
printf("a is non-zero and the address of b is equal to p\n");
}

--
Simon.
Nov 13 '05 #13

P: n/a
Mark Gordon wrote:
On Sun, 30 Nov 2003 14:37:28 +0100
Sidney Cadot <si****@jigsaw.nl> wrote:
I think their main raison-d'etre at the moment is as serving as
counter-examples in c.l.c discussions. Perhaps it is time, in the next
C version, to mandate that CHAR_BIT==8. I don't know.
Definitely not. CHAR_BIT==9 may be rare these days, but CHAR_BIT==16 is
not once you start looking at DSP processors which often don't have the
ability to access less that 16 bits (or or) in one operation.


Ok. Good point.
... "Burn the malloc-casting witch! Burn!" ... :-) Requiring a diagnostic (not necessarily an error) for using unprototyped
functions might be of help.


Yes, that would be a seriously good idea for a proposed change.
Agreed, it would be nice for enums to be more "special." On
the other hand, the biggest use for enums is as a drop-in
replacement for #defined integer constants, and I don't want to lose
that capability. (Yes, "constant" consts would fix *that* problem,
but that would basically turn C compilers into C++ compilers on a
complexity scale.


The last statement I do not understand. Care to elaborate?


Something like

fancy_enum { fred=32, george=23 } bar;
bar = fred;
bar++; /* bar nor equals george */

possibly?


I think this was not the intended meaning of the statement. However,
this raises an important question. For backward compatibility, it is
inevitable that (int)bar would equal 33 after the post-increment, I think.
This can work for unsigned types, but I'm not so sure if a similar
thing
can work portably for signed types.

<snip>

i=0;
while (1) {
/* do stuff */
if (i==INT_MAX) break; /* or whatever other MAX */
i++;
}

Even uglier but safe for signed types.


Ok. I'm not sure if I can think of a better way, so let's keep it like
it is :-)

Best regards, Sidney

Nov 13 '05 #14

P: n/a
Arthur J. O'Dwyer wrote:
The last statement I do not understand. Care to elaborate?

const int foo = 5;
char arr[foo];

Legal C++ (because in C++, const objects are really "constant"),
but illegal C (because 'foo' is an object whose value needn't
be stored [or even computed] at compile time).
This is legal at least in C99, and I think also in C89 (at least my gcc
doesn't even warn on it).
I think C's way
is easier for me to grasp. And I think (but this is just IMH
and uneducated O) that C++ compilers need a lot of extra baggage
to deal with constant "consts," and I wouldn't want to foist all
that on C compilers.


Given that it already works, this would be a moot point.
i=0;
while (1) {
/* do stuff */
if (i==INT_MAX) break; /* or whatever other MAX */
i++;
}

Even uglier but safe for signed types.

Except possibly for flavors of 'char', why would anyone want to
walk over all values of a type anyway? Solving equations by
exhaustive search? ;-)


That's a nice example ...

Best regards,

Sidney

Nov 13 '05 #15

P: n/a
Simon Biber wrote:
Oh, and just for kicks, note that the &&& operator
would break some [pathological] C code.

Like this:
int a = 1, b, *p = &b;
if(a != 0 &&& b == p)
{
printf("a is non-zero and the address of b is equal to p\n");
}


True, but at least this wouldn't go unnoticed under hypothetical &&&
semantics, given that the expression "b==p" isn't valid.

Best regards, Sidney

Nov 13 '05 #16

P: n/a
Sidney Cadot <si****@jigsaw.nl> wrote:
Arthur J. O'Dwyer wrote:
The last statement I do not understand. Care to elaborate?


const int foo = 5;
char arr[foo];

Legal C++ (because in C++, const objects are really "constant"),
but illegal C (because 'foo' is an object whose value needn't
be stored [or even computed] at compile time).


This is legal at least in C99, and I think also in C89 (at least my gcc
doesn't even warn on it).


It's not legal in C89. You didn't invoke gcc with the appropriate
set of options. ;-) You should get a

warning: ISO C89 forbids variable-size array `arr'

In C99 it should work, given that the variable length array 'arr' is
declared inside a function; otherwise you should get something like:

variable-size type declared outside of any function
I think C's way
is easier for me to grasp. And I think (but this is just IMH
and uneducated O) that C++ compilers need a lot of extra baggage
to deal with constant "consts," and I wouldn't want to foist all
that on C compilers.


Given that it already works, this would be a moot point.


But it doesn't work. :) 'const' qualified variables in C are not
compile-time constants. This is one of the important points
where C++ differs.

<snip>

Regards
--
Irrwahn
(ir*******@freenet.de)
Nov 13 '05 #17

P: n/a
Irrwahn Grausewitz wrote:
Sidney Cadot <si****@jigsaw.nl> wrote:
Arthur J. O'Dwyer wrote:

>The last statement I do not understand. Care to elaborate?

const int foo = 5;
char arr[foo];

Legal C++ (because in C++, const objects are really "constant"),
but illegal C (because 'foo' is an object whose value needn't
be stored [or even computed] at compile time).
This is legal at least in C99, and I think also in C89 (at least my gcc
doesn't even warn on it).

It's not legal in C89. You didn't invoke gcc with the appropriate
set of options. ;-) You should get a
warning: ISO C89 forbids variable-size array `arr'


You're right. I forgot the -pedantic ... Silly gcc folks ... Stupid me ...
In C99 it should work, given that the variable length array 'arr' is
declared inside a function; otherwise you should get something like:

variable-size type declared outside of any function
Check.
I think C's way
is easier for me to grasp. And I think (but this is just IMH
and uneducated O) that C++ compilers need a lot of extra baggage
to deal with constant "consts," and I wouldn't want to foist all
that on C compilers.


Given that it already works, this would be a moot point.


Ok, it's not a moot point, then.
But it doesn't work. :) 'const' qualified variables in C are not
compile-time constants. This is one of the important points
where C++ differs.


Okidoki. That's what I _thought_ until I tried and made a silly mistake.
Sigh.

Regards,

Sidney

Nov 13 '05 #18

P: n/a

"Jack Klein" <ja*******@spamcop.net> wrote in message
I would also like to see something along the lines of C++ templating,
except without the really kludgy implementation that the C++ folks
decided to go to ( and without the OOP ).
Can you provide a sample implementation to show how it would
work?

The easiest option would be to use C++ syntax, and run the code through a
C++ compiler if no C 2003 compiler is available, maybe with a simple front
end to check the code complies.
I could wish that pigs had wings so they could fly, but unless I can
come up with at least some solid engineering plans that showed
feasibility and a favorable cost-benefit ration, I would not expect
anyone to take my wish seriously.

I think there are two to be made for templates. The weak case is that often
it is handy to write a function once with several types of arguments. For
instance swap() naturally lends itself to a template implementation. So too
does mean().
Personally I don't think these cases are common enough to justify a new
language feature, and also involve some subtle problems. For instance mean()
is fine for floats and doubles, but will usually break when fed a char
array, and could easily break with a short.

The stronger case is that the C++ standard template library allows client
code to do away with dynamic memory, and almost to do away with pointers.
These are probably the two features of C which cause more bugs than any
other, and also doing away with them would allow safe applications, for
instance in programs to be distributed over the net. This may be an
advantage. The problem is that the new language would no longer be
recognisably C.
Nov 13 '05 #19

P: n/a
On Sun, 30 Nov 2003 18:08:09 +0100
Sidney Cadot <si****@jigsaw.nl> wrote:
Mark Gordon wrote:
On Sun, 30 Nov 2003 14:37:28 +0100
Sidney Cadot <si****@jigsaw.nl> wrote:
<snip>
Agreed, it would be nice for enums to be more "special." On
the other hand, the biggest use for enums is as a drop-in
replacement for #defined integer constants, and I don't want to
lose that capability. (Yes, "constant" consts would fix *that*
problem, but that would basically turn C compilers into C++
compilers on a complexity scale.

The last statement I do not understand. Care to elaborate?


Something like

fancy_enum { fred=32, george=23 } bar;
bar = fred;
bar++; /* bar nor equals george */

possibly?


I think this was not the intended meaning of the statement. However,
this raises an important question. For backward compatibility, it is
inevitable that (int)bar would equal 33 after the post-increment, I
think.


That was why I suggested something other than enum. I'm not sure what
else the person who said he wanted enums to be more special might have
meant.
This can work for unsigned types, but I'm not so sure if a similar
thing
can work portably for signed types.

<snip>

i=0;
while (1) {
/* do stuff */
if (i==INT_MAX) break; /* or whatever other MAX */
i++;
}

Even uglier but safe for signed types.


Ok. I'm not sure if I can think of a better way, so let's keep it like
it is :-)


I must admit that a simpler solution might be nice, but it would require
a new control structure.
--
Mark Gordon
Paid to be a Geek & a Senior Software Developer
Although my email address says spamtrap, it is real and I read it.
Nov 13 '05 #20

P: n/a
Sidney Cadot <si****@jigsaw.nl> wrote in message news:<bq**********@news.tudelft.nl>...
....
There's always some things that could be improved of course. My personal
wish-list would include (in no particular order):

* mandatory support for fixed-width integers (in C99, this is optional).
You do realize, of course, that such a change won't make fixed-width
integers any more widely available? All it will do is guarantee that a
conforming implementation of C99 won't be possible on some obscure
platforms. Is there any value in this?

.... * deprecation of implicit casts of fp-types to integer types (perhaps
supported by a mandatory compiler warning).
Warnings are, and should be, purely a matter of QoI. The standard is
only concerned with diagnostics, which can be either warning or error
messages (or, for that matter, gleeful celebrations), it's entirely up
to the implementor.
* a reliable and easy way to walk over all integers in a certain
interval, including the MAX value for that type, by means of a
for loop; eg., currently

for(unsigned i=0;i<=UINT_MAX;i++) ...

doesn't work as intended.


It's perfectly feasible to do this with the language as it currently
exists:

for(unsigned i=0; ; i++)
{
// Body of loop
if(i==UINT_MAX)
break;
}

or

unsigned i=0;

do
{
// Body of loop
}
while(++i);

These are a little clumsy, but is the alternative you're thinking of
any less clumsy? Until you make it more specific, we can't tell.
Nov 13 '05 #21

P: n/a
"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote in message news:<Pi**********************************@unix44. andrew.cmu.edu>...
On Sun, 30 Nov 2003, Sidney Cadot wrote:

....
* 'min' and 'max' operators (following gcc: ?< and ?>)


Ditto the "Huh?" This is what functions were built to
do. You know, curly braces and all that?


Actually, this is what templates are for. min() and max() are the
strongest simple argument for templates that I can think of. I don't
want to add templates to C; if I want C++, I'll use C++. But this is
one of the things that sometimes makes me prefer C++.
Nov 13 '05 #22

P: n/a
"Simon Biber" <ne**@ralminNOSPAM.cc> wrote in message news:<3f***********************@news.optusnet.com. au>...
"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote:
On Sun, 30 Nov 2003, Sidney Cadot wrote:
* support for a "packed" attribute to structs, guaranteeing
that no padding occurs.


Needs elaboration. As stated, this is flatly impossible.
Even on a vanilla Win/Intel platform,

struct { char c; double d; } x;

simply *cannot* be organized to completely avoid padding.
Unless you'd just allow the compiler to throw a warning
saying "Whoops! This struct can't be 'un-padded'!" But
then you'd have implementation-defined behavior, which is
basically what we have in C99 anyway.


Surely it is possible, if you add in extra code to handle a
memcpy to and from &x.d every time you read or write to the
unaligned x.d?


Can &x.d be passed to a function which expects a correctly aligned
double*? How is an implementor supposed to make that work properly, on
a platform where alignment is a real issue, not just a performance
hit?

....
* triple-&& and triple-|| operators: &&& and ||| with
semantics like the 'and' and 'or' operators in python:

a &&& b ---> if (a) then b else a
a ||| b ---> if (a) then a else b

[snip]
result = a? b: 0; /* &&& */


ITYM a ? b : a


a?b:0 is marginally faster than a?b:a on some compilers, otherwise
there's not much difference between them.
Nov 13 '05 #23

P: n/a
Sidney Cadot <si****@jigsaw.nl> wrote in message news:<bq**********@news.tudelft.nl>...
Arthur J. O'Dwyer wrote:
On Sun, 30 Nov 2003, Sidney Cadot wrote: ....
As to the fixed-width types: there is quite an important area of
application that needs this, which is interpretation of binary protocols
and file formats (this constitutes a large part of the work I'm involved
with at the moment).
But on any platform where those protocols apply, those types will be
available; the market will make sure of that, without any need to have
the standard say so. The only effect of mandating fixed-width types
will be to prevent a fully-conforming implementation of C on certain
rare platforms.

....
This would make some platforms incompatible with C; up to this
point, C has never [to my knowledge] *required* any fixed-width
data types. How about those 9-bit-byte mainframes everyone likes
to bring up?


I think their main raison-d'etre at the moment is as serving as
counter-examples in c.l.c discussions. Perhaps it is time, in the next C
version, to mandate that CHAR_BIT==8. I don't know.


That would also prohibit CHAR_BIT==16 or CHAR_BIT==32. I suspect that
there are currently more of those than platforms with CHAR_BIT==9
(though I myself have no personal experience with CHAR_BIT!=8).

....
Needs elaboration. As stated, this is flatly impossible. Even
on a vanilla Win/Intel platform, .... struct { char c; double d; } x;

simply *cannot* be organized to completely avoid padding. Unless
you'd just allow the compiler to throw a warning saying "Whoops!
This struct can't be 'un-padded'!" But then you'd have implementation-
defined behavior, which is basically what we have in C99 anyway.


It can be done by emitting a lot of code, but this wouldn't be a
problem; you'd only use it for applications where access to an
externally defined packed-binary specification is important.


"A lot of code", yes. On platforms where alignment actually matters,
every function that accepted a pointer argument would have to written
to cope with the possibility that it points into an object which is
actually misaligned, due to being a member of a packed struct.

....
This either already exists, or would require only a small change,
I think. FP types already have mantissa and exponent parts; all
this would require would be a standard minimum mantissa length.


As far as I am aware, the C standard doesn't mandate that floating point
values use sign/exponent/mantissa form; a hitherto unknown good trick
could be discovered for representing fractional numbers today, and it
could be implemented in C I think. My proposal is to have at least
boundaries for integers that can be represented without loss of precision.


The standard does not require that form, but it does define the
<float.h> constants in those terms, as a model. I suspect that there
would be lots of problems applying the C standard to a floating point
type not well-described by that model.

....
i = 0;
do {
...
} while (++i != 0);

Ugly, but functional. And I'm sure this is a FAQ anyway.


This can work for unsigned types, but I'm not so sure if a similar thing
can work portably for signed types.


for(int i=INT_MIN; ; i++)
{
// Body of loop
if(i==INT_MAX)
break;
}

* triple-&& and triple-|| operators: &&& and ||| with semantics
like the 'and' and 'or' operators in python:

a &&& b ---> if (a) then b else a
a ||| b ---> if (a) then a else b

(I think this is brilliant, and actually useful sometimes).

I think something like this is a GNU C extension; IIRC
they added a?>b for "max(a,b)". Anyway, I don't see the
advantage over

result = a? b: 0; /* &&& */
(result = a) && (result = b); /* ||| */

The second one is just about as cryptic...


I take it you mean

a &&& b ---> a ? b : a


That's another way to do it, but may be less efficient on some
compilers.
a ||| b ---> a ? a : b

This suffers from the fact that expression a possibly needs to be
evaluated twice, which I'd like to prevent.


That's one reason why the forms he originally gave are better than
your replacements. They both avoid the double-evaluation of 'a'.
Nov 13 '05 #24

P: n/a
James Kuyper wrote:
Surely it is possible, if you add in extra code to handle a
memcpy to and from &x.d every time you read or write to the
unaligned x.d?


Can &x.d be passed to a function which expects a correctly aligned
double*? How is an implementor supposed to make that work properly, on
a platform where alignment is a real issue, not just a performance
hit?


Ok, that's a good point. So how about if we forbid the taking of the
adress of a member of a packed struct using the "&" operator, in much
the same way as we can't do it for bit-fields.

Best regards,

Sidney

Nov 13 '05 #25

P: n/a
James Kuyper wrote:
Sidney Cadot <si****@jigsaw.nl> wrote in message news:<bq**********@news.tudelft.nl>...
As to the fixed-width types: there is quite an important area of
application that needs this, which is interpretation of binary protocols
and file formats (this constitutes a large part of the work I'm involved
with at the moment).
But on any platform where those protocols apply, those types will be
available; the market will make sure of that, without any need to have
the standard say so. The only effect of mandating fixed-width types
will be to prevent a fully-conforming implementation of C on certain
rare platforms.


Good point. Dropped from my wish-list.
This would make some platforms incompatible with C; up to this
point, C has never [to my knowledge] *required* any fixed-width
data types. How about those 9-bit-byte mainframes everyone likes
to bring up?


I think their main raison-d'etre at the moment is as serving as
counter-examples in c.l.c discussions. Perhaps it is time, in the next C
version, to mandate that CHAR_BIT==8. I don't know.


That would also prohibit CHAR_BIT==16 or CHAR_BIT==32. I suspect that
there are currently more of those than platforms with CHAR_BIT==9
(though I myself have no personal experience with CHAR_BIT!=8).

Conceded. Dropped from my wish-list.
struct { char c; double d; } x;

simply *cannot* be organized to completely avoid padding. Unless
you'd just allow the compiler to throw a warning saying "Whoops!
This struct can't be 'un-padded'!" But then you'd have implementation-
defined behavior, which is basically what we have in C99 anyway.


It can be done by emitting a lot of code, but this wouldn't be a
problem; you'd only use it for applications where access to an
externally defined packed-binary specification is important.


"A lot of code", yes. On platforms where alignment actually matters,
every function that accepted a pointer argument would have to written
to cope with the possibility that it points into an object which is
actually misaligned, due to being a member of a packed struct.


I propose to disallow & on members of a packed struct, or at least make
this implementation-defined.

I wonder how gcc handles this on those platforms.
This either already exists, or would require only a small change,
I think. FP types already have mantissa and exponent parts; all
this would require would be a standard minimum mantissa length.


As far as I am aware, the C standard doesn't mandate that floating point
values use sign/exponent/mantissa form; a hitherto unknown good trick
could be discovered for representing fractional numbers today, and it
could be implemented in C I think. My proposal is to have at least
boundaries for integers that can be represented without loss of precision. The standard does not require that form, but it does define the
<float.h> constants in those terms, as a model. I suspect that there
would be lots of problems applying the C standard to a floating point
type not well-described by that model.


Ok. Still, MIN and MAX constants for perfectly representable
integer-values for float, double, and long double might be useful.
a ||| b ---> a ? a : b

This suffers from the fact that expression a possibly needs to be
evaluated twice, which I'd like to prevent.

That's one reason why the forms he originally gave are better than
your replacements. They both avoid the double-evaluation of 'a'.


So, you're going to second this proposal? :-)

Best regards,

Sidney

Nov 13 '05 #26

P: n/a
those who know me have no need of my name wrote:
Morris Dovey wrote:
Michael B. wrote:

I was just thinking about this, specifically wondering if
there's any features that the C specification currently lacks,
and which may be included in some future standardization.


Of course there are. Can you imagine that people will /ever/
stop fixing things just because they ain't broke?


yes. (cf the pl/i standard)


Along the same lines, and probably in heavier use than PL/I today,
are Pascal (ISO 7185) and Extended Pascal (ISO 10206).

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 13 '05 #27

P: n/a
Sidney Cadot wrote:
Michael B. wrote:
I was just thinking about this, specifically wondering if
there's any features that the C specification currently lacks,
and which may be included in some future standardization.

.... snip ...
There's always some things that could be improved of course. My
personal wish-list would include (in no particular order):
What a list to shoot at :-) I am going to restrain myself and
muck with only a few items.

.... snip ...
* deprecation of implicit casts of fp-types to integer types
(perhaps supported by a mandatory compiler warning).
Breaks existing code.

* deprecation of implicit casts of void* to other pointer types
(perhaps supported by a mandatory compiler warning). This is
a desire not likely to be shared by many here, though ;-)
You called it :-)

.... snip ...
* deprecate trigraphs. Let's end the madness once and for all.
Unfortunately absolutely necessary in some environments. You
don't have to use them.

* a reliable and easy way to walk over all integers in a certain
interval, including the MAX value for that type, by means of a
for loop; eg., currently

for(unsigned i=0;i<=UINT_MAX;i++) ...

doesn't work as intended.
i = 0;
do {
stuff();
} while (i++ != UINT_MAX);

I see no law imposing the use of for loops.

.... snip ...
* a way to "bitwise invert" a variable without actually
assigning, complementing "&=", "|=", and friends.


Investigate the '~' operator.

.... snip ...

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 13 '05 #28

P: n/a
On Sun, 30 Nov 2003 13:54:02 GMT, in comp.lang.c , pete
<pf*****@mindspring.com> wrote:
Arthur J. O'Dwyer wrote:
I think // comments are obscene; I have no use for variable-width
arrays; any time I need an exactly 32-bit integer type, I'm probably
not writing completely portably anyway and might as well use 'int'
itself; and so on.


'long' might be a better choice
for when you need an exactly 32-bit integer type.


There's nothing that req uires long to be exactly 32 bits any more
than int. Both would be equally nonportable assumptions.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 13 '05 #29

P: n/a
"Sidney Cadot" <si****@jigsaw.nl> wrote in message
news:bq**********@news.tudelft.nl...
James Kuyper wrote:
Surely it is possible, if you add in extra code to handle a
memcpy to and from &x.d every time you read or write to the
unaligned x.d?


Can &x.d be passed to a function which expects a correctly aligned
double*? How is an implementor supposed to make that work properly, on
a platform where alignment is a real issue, not just a performance
hit?


Ok, that's a good point. So how about if we forbid the taking of the
adress of a member of a packed struct using the "&" operator, in much
the same way as we can't do it for bit-fields.


Not forbid, just a warning when the compiler notices that
the field offset is improperly aligned. Taking the address
may imply truncation of low-order bits and such when applied
to types with implicit alignment (depending on implementation),
so you want a warning when the generated pointer may not work
the same as a properly aligned item. If the field in the packed
structure just happens to be aligned properly, then fine (no
warning).

--
----------------------------------------------
Jeffrey D. Smith
Farsight Systems Corporation
24 BURLINGTON DRIVE
LONGMONT, CO 80501-6906
303-774-9381
http://www.farsight-systems.com
z/Debug debugs your Systems/C programs running on IBM z/OS!
Nov 13 '05 #30

P: n/a
Hi Michael!
"Michael B." <us*****@spamblocked.com> wrote in message...
Of course, I speak only of features in the spirit of C; something like
object-orientation, though a nice feature, does not belong in C.
Something like being able to #define a #define would be very handy,
though, e.g:

#define DECLARE_FOO(bar) #define FOO_bar_SOMETHING \
#define FOO_bar_SOMETHING_ELSE
Although this is my opinion, I think a lot of people would agree:
preprocessor magic should be kept simple and to a minimum. Although
some wonderful tricks can be accomplished using the current
preprocessor syntax (and indeed, your proposed extension), it quickly
becomes a maintenance and readability nightmare - for the coder who
originally wrote it, or for someone else who is picking up the code.

For large #if #else #endifs around platform-specific code, usually
there is a nicer solution found in abstracting said code, and writing
per-platform translation units which are then linked in by your build
system.

I'm not sure whether the features of cpp are even included in the C
standard
They are.

I would also like to see something along the lines of C++ templating,
except without the really kludgy implementation that the C++ folks decided
to go to ( and without the OOP ).
I'd imagine that adding a new fundamental concept such as this to the
C standard stands as good a chance at getting approval as a snowball's
chance of not melting in hell. :)

C is a very simple and uniform language - possibly a major reason for
the roaring success it has had over the years. It is also very
explicit - usually a statement does exactly what it says it does
(unless it includes a cpp macro ;). Concepts such as templates,
although useful, detract from the overall simplicity of the language.

Templates save a lot of time when it comes to commonly-used data
structures, and as they are entirely implemented at compile-time and don't
include, by their definition, OOP (although they can be well suited to
it), I think they would be a nice addition and in the spirit of C.
I would almost say that C already supports 'templates' for structures
at least. For example, imagine:

struct list_head {
struct list_head *next, *prev;
};

struct my_list_type {
struct list_head list_head;
void *my_data;
};

struct my_list_type ml;
As far as I can tell, accessing ml.list_head.next is just as quick
(after compilation) as accessing ml.next, assuming that 'ml.next' is
part of a structure that was generated using a template facility.

This example actually comes from a real project - namely the Linux
kernel. Lots of other people use it too. You could consider it a
'cultural standard idiom'. :)

Yes, coining a stupid phrase like that was completely unneccesary. :D

Your thoughts? I'm sure there's some vitriol coming my way but I'm
prepared 8)


C is simple. It has stood the test of time, and thus "if it ain't
broke, don't fix it".

I believe that C is on it's way out as a general use tool. Sure, it
probably has 20 years left, but programming ideologies are evolving,
and computing is moving to new heights.

C has found it's niche market in lower level and high performing
applications, it is relatively expressive, and it generates small,
tight code. That market isn't about to change, and neither (I believe)
is C. Let's leave it be until the dog has its day, and finally goes to
sleep.

C is dead! Long live QuantumC! ;)
David.
Nov 13 '05 #31

P: n/a

On Sun, 30 Nov 2003, Sidney Cadot wrote:

Simon Biber wrote:

[I wrote:]
Oh, and just for kicks, note that the &&& operator
would break some [pathological] C code.


Like this:
int a = 1, b, *p = &b;
if(a != 0 &&& b == p)
{
printf("a is non-zero and the address of b is equal to p\n");
}


True, but at least this wouldn't go unnoticed under hypothetical &&&
semantics, given that the expression "b==p" isn't valid.


Change "==p" to "==0", or just remove it altogether, to get
essentially the example of which I was thinking. As I said,
pathological -- but possible. :)

-Arthur
Nov 13 '05 #32

P: n/a
Someone wrote:
in comp.lang.c i read:
Michael B. wrote:
I was just thinking about this, specifically wondering if there's any
features that the C specification currently lacks, and which may be
included in some future standardization.
Of course there are. Can you imagine that people will /ever/ stop
fixing things just because they ain't broke?
yes. (cf the pl/i standard)


There has been a long discussion cross posted between comp.lang.fortran
and comp.lang.pl1, started by a troll, over which language is better.

Fortran has changed many times over the years, and now has many of the
features that PL/I started with in the 1960's. PL/I has changed a
little of the years, but the changes are pretty small. Partly because
the demand for changed is small, but also because they got a reasonable
number of things right.

OK, to make this a little bit on topic, one of the questions from the
Fortran troll had to do with doing C like pointer operations, choosing
between two strings by assigning a pointer to the selected string to a
pointer variable, and then printing the desired string.

As I had never done pointer variables in PL/I, it seemed like an
interesting challenge. It turns out PL/I pointers can't point to string
constants, but they can point to initialized string variables. (This
removes the possibility of changing constants.) PL/I pointer variables
are more suited to operations related to linked lists than to many of
the uses that C uses them for.

With all those features, why isn't it more popular today? One reason
might be that it was ahead of its time. The first PL/I compiler was
required to run in 44K (64K machine, 20K OS) while compiling a language
significantly more complex than C. There was a significant amount of
run-time overhead needed to support many of those features that other
languages didn't need. (Fortran statically allocated all variables, for
example.)

It might be that many of the additions in C99 already existed in the
first PL/I standard. Complex variables are one example.

I would say that a language that was designed with plans for future
machines, instead of just matching existing machines, is more likely to
last without needing major changes.

-- glen

Nov 13 '05 #33

P: n/a
Arthur J. O'Dwyer wrote:
On Sun, 30 Nov 2003, Sidney Cadot wrote:
Simon Biber wrote:


[I wrote:]
Oh, and just for kicks, note that the &&& operator
would break some [pathological] C code.

Like this:
int a = 1, b, *p = &b;
if(a != 0 &&& b == p)
{
printf("a is non-zero and the address of b is equal to p\n");
}


True, but at least this wouldn't go unnoticed under hypothetical &&&
semantics, given that the expression "b==p" isn't valid.

Change "==p" to "==0", or just remove it altogether, to get
essentially the example of which I was thinking. As I said,
pathological -- but possible. :)


Ok. I was thinking for a moment that since "&b==0" reduces to false, and
since "&b" (as a truth value) reduces to true, something clever was
going to happen to the entire expression but it isn't.

However: there is precedent for changing the semantics of pathalogically
weird C code with the C89 -> C99 transition, with respect to the
introduction of double-slash comments. So I don't see how this would,
per se, prevent &&& from being introduced as an operator, despite your
keen observation.

Best regards, Sidney

Nov 13 '05 #34

P: n/a
xarax wrote:
"Sidney Cadot" <si****@jigsaw.nl> wrote in message

Ok, that's a good point. So how about if we forbid the taking of the
adress of a member of a packed struct using the "&" operator, in much
the same way as we can't do it for bit-fields.


Not forbid, just a warning when the compiler notices that
the field offset is improperly aligned. Taking the address
may imply truncation of low-order bits and such when applied
to types with implicit alignment (depending on implementation),
so you want a warning when the generated pointer may not work
the same as a properly aligned item. If the field in the packed
structure just happens to be aligned properly, then fine (no
warning).


The problem with this is typical use of packed structures. Suppose
you're reading a binary file; at some point in this file, there's data
described by the packed structure.

While e.g. a double field may be properly aligned relative to the start
of the struct, it may no longer be properly aligned in memory relative
to the start of the chunk of bytes that we want to use the packed struct
to describe.
Simple example:

packed struct DStruct {
double x;
};

void f(double *arg);

unsigned char *x; (properly malloced, and containing the contents of the
binary file.)

Now I know that, there's 17 bytes of garbage at the start, then there's
a DStruct:

DStruct *dp = (struct DStruct *)(x+17);

If I now do:

f(&dp->x);

This may now fail because of improper alignement of the double.

Best regards,

Sidney

Nov 13 '05 #35

P: n/a
Mark Gordon wrote:
I think this was not the intended meaning of the statement. However,
this raises an important question. For backward compatibility, it is
inevitable that (int)bar would equal 33 after the post-increment, I
think.

That was why I suggested something other than enum. I'm not sure what
else the person who said he wanted enums to be more special might have
meant.


That would have been me. I was aiming for about the same status for
'enum' types as enumeration types have in Pascal. However, in C you can
of course assign definite integer values to members of an enum,
including duplicates - this complicates matters considerably.

I guess the only thing that could be done without breaking too much code
is mandating a compiler diagnostic on implicit conversion of an enum
value to an int value. Personally, I think that would be a good idea.

Best regards,

Sidney

Nov 13 '05 #36

P: n/a
In article <bq**********@news.tudelft.nl>
Sidney Cadot <si****@jigsaw.nl> writes:
... My personal wish-list [for some future C standard] would include
(in no particular order):
[numerous items snipped]
* triple-&& and triple-|| operators: &&& and ||| with semantics
like the 'and' and 'or' operators in python:

a &&& b ---> if (a) then b else a
a ||| b ---> if (a) then a else b

(I think this is brilliant, and actually useful sometimes).
Besides the syntactic shift (from being parsed as "&& &b" today),
I think it is worth pointing out that if "a" is false, it must compare
equal to 0; so assuming "a &&& b" means "if a then b else a", it
also means "if a then b else 0", which can be expressed today as
"a ? b : 0".

(GCC offers "a ||| b" as "a ?: b", which means "a ? a : b" without
evaluating "a" twice.)
* a way to "bitwise invert" a variable without actually
assigning, complementing "&=", "|=", and friends.
The expression "x = ~x" can always be transformed into "x ^= ~0U",
although the constant may need to be written as 0UL, 0ULL,
(uintmax_t)0, or some such. (Using ^= ~(uintmax_t)0 probably
always works, but probably draws warnings on some compilers.)
* 'min' and 'max' operators (following gcc: ?< and ?>)


It is also worth noting that Dennis Ritchie's early C compiler(s)
*had* min and max operators, spelled \/ and /\ respectively. They
were dropped, most likely from lack of use.

Someone else asked (further down in the thread) whether some CPUs
might have "min" and "max" instructions. I have never seen precisely
this myself, but many architectures have "synthetic" (and branchless)
min/max sequences -- usually involving the carry bit (many CPUs)
or "set if less than" instructions (MIPS) or the like -- and even
the x86 now has conditional-move. GCC will generate these for the
branch-ful "a < b ? a : b" sequence, e.g.:

int imin(int a, int b) { return a < b ? a : b; }

compiles to, e.g.:

cmpl %eax, %ecx
cmovle %ecx, %eax

when gcc is given the right options (-msse). (V9 sparc also has
conditional move, and ARM has conditional *everything*. :-) )
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Nov 13 '05 #37

P: n/a
"Simon Biber" <ne**@ralminNOSPAM.cc> wrote in message news:<3f***********************@news.optusnet.com. au>...
"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote:

<snipped>
[snip]
* triple-&& and triple-|| operators: &&& and ||| with
semantics like the 'and' and 'or' operators in python:

a &&& b ---> if (a) then b else a
a ||| b ---> if (a) then a else b

[snip]
result = a? b: 0; /* &&& */


ITYM a ? b : a


surely its the same thing ?

<snipped>

goose,
Nov 13 '05 #38

P: n/a
"Michael B." <us*****@spamblocked.com> wrote in message news:<pa****************************@spamblocked.c om>...
I was just thinking about this, specifically wondering if there's any
features that the C specification currently lacks, and which may be
included in some future standardization.

Of course, I speak only of features in the spirit of C; something like
object-orientation, though a nice feature, does not belong in C.
Something like being able to #define a #define would be very handy,
though, e.g:

#define DECLARE_FOO(bar) #define FOO_bar_SOMETHING \
#define FOO_bar_SOMETHING_ELSE
whats wrong with
#define DECLARE_FOO(bar) FOO_ ##bar## _SOMETHING_ELSE

(I assume you wanted to use "bar" as an argument to the
first macro, right ?)

I haven't yet come across a good reason for #defining a new
#define.

I'm not sure whether the features of cpp are even included in the C
standard though
they are.
(and GCC has definitely taken quite a nonstandard approach
with regards to certain token expansions and whatnot), but that's one area
of improvement I see.

I would also like to see something along the lines of C++ templating,
except without the really kludgy implementation that the C++ folks decided
to go to ( and without the OOP ).
the actual templating support in C++ is done, imho, fairly well.

... Mike pauses for the sound of a thousand *plonks*

Templates save a lot of time when it comes to commonly-used data
structures, and as they are entirely implemented at compile-time and don't
include, by their definition, OOP (although they can be well suited to
it), I think they would be a nice addition and in the spirit of C.
I suppose so, as long as its done carfully enough that it:
a) doesn't break existing code.
b) is different enough in syntax to C++ so that
idiots who use the language "C/C++" will catch a clue.
having it compilable by a C++ compiler encourages
people to write code that will compile on both C and
C++ compilers cleanly.
Your thoughts? I'm sure there's some vitriol coming my way but I'm
prepared 8)


<grin> are you sure ?

goose,
Nov 13 '05 #39

P: n/a
In <3F**************@yahoo.com> CBFalconer <cb********@yahoo.com> writes:
those who know me have no need of my name wrote:
Morris Dovey wrote:
> Michael B. wrote:

>> I was just thinking about this, specifically wondering if
>> there's any features that the C specification currently lacks,
>> and which may be included in some future standardization.
>
> Of course there are. Can you imagine that people will /ever/
> stop fixing things just because they ain't broke?


yes. (cf the pl/i standard)


Along the same lines, and probably in heavier use than PL/I today,
are Pascal (ISO 7185) and Extended Pascal (ISO 10206).


Which conforming implementations of ISO 7185 and ISO 10206 are in current
use today?

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #40

P: n/a
In <m1*************@usa.net> those who know me have no need of my name <no****************@usa.net> writes:
in comp.lang.c i wrote:
in comp.lang.c i read:

I would also like to see something along the lines of C++ templating,

hard to see how you can do this properly without a pile of other stuff, but
if you've got an idea that makes sense advance it here,


oops, advance it in comp.std.c rather than here.


It doesn't make any difference where you advance it: it will get ignored,
anyway.

If you want to promote an idea, either become a committee member or
convince one committee member that it's worth promoting it.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #41

P: n/a
In <3F**********@mindspring.com> pete <pf*****@mindspring.com> writes:
Arthur J. O'Dwyer wrote:
I think // comments are obscene; I have no use for variable-width
arrays; any time I need an exactly 32-bit integer type, I'm probably
not writing completely portably anyway and might as well use 'int'
itself; and so on.


'long' might be a better choice
for when you need an exactly 32-bit integer type.


Nope. long should be a better choice for when you need a 64-bit integer
type. The only unwasteful type assignation for the usual processors
currently used in hosted implementations is:

8-bit: char
16-bit: short
32-bit: int
64-bit: long

and there are C89 implementations that do the integral types this way.
No need for a long long at all.

Having int as an "alias" for either short or long was a historical
mistake that should have been exposed and corrected long ago. The C
standards keep blessing it, instead...

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #42

P: n/a
In <bq**********@news.tudelft.nl> Sidney Cadot <si****@jigsaw.nl> writes:
Arthur J. O'Dwyer wrote:
Agreed. Although besides the mixing of declarations and statements,
I can't think of any C99 features I *use* that are lacking in C90.
I think // comments are obscene; I have no use for variable-width
arrays; any time I need an exactly 32-bit integer type, I'm probably
not writing completely portably anyway and might as well use 'int'
itself; and so on.


I agree wholly on the // part, that's a C++-ism that I'd rather see
deprecated in the next standard ;-)


C++ didn't invent // comments, it merely inherited them from C's ancestor,
B. One could argue that they belonged to C since day one ;-)

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #43

P: n/a
In <pa****************************@spamblocked.com> "Michael B." <us*****@spamblocked.com> writes:
I was just thinking about this, specifically wondering if there's any
features that the C specification currently lacks, and which may be
included in some future standardization.


I would happily trade all the new stuff in C99 for all the sensible GNU C
extensions to C89. The resulting standard would be widely implemented
from day one and a lot more useful than a widely implemented C99 would
ever hope to be.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #44

P: n/a
In <20******************************@flash-gordon.me.uk> Mark Gordon <sp******@flash-gordon.me.uk> writes:
On Sun, 30 Nov 2003 14:37:28 +0100
Sidney Cadot <si****@jigsaw.nl> wrote:
Arthur J. O'Dwyer wrote:
> On Sun, 30 Nov 2003, Sidney Cadot wrote:
>
>>Michael B. wrote:
<snip>
>>There's always some things that could be improved of course. My
>>personal wish-list would include (in no particular order):
>>
>>* mandatory support for fixed-width integers (in C99, this is
>optional).
>
> This would make some platforms incompatible with C; up to this
> point, C has never [to my knowledge] *required* any fixed-width
> data types. How about those 9-bit-byte mainframes everyone likes
> to bring up?


I think their main raison-d'etre at the moment is as serving as
counter-examples in c.l.c discussions. Perhaps it is time, in the next
C version, to mandate that CHAR_BIT==8. I don't know.


Definitely not. CHAR_BIT==9 may be rare these days, but CHAR_BIT==16 is
not once you start looking at DSP processors which often don't have the
ability to access less that 16 bits (or or) in one operation.


But those are used in freestanding implementations only, and we ignore
such implementations by default, here.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #45

P: n/a
Mark McIntyre wrote:

On Sun, 30 Nov 2003 13:54:02 GMT, in comp.lang.c , pete
<pf*****@mindspring.com> wrote:
Arthur J. O'Dwyer wrote:
I think // comments are obscene; I have no use for variable-width
arrays; any time I need an exactly 32-bit integer type, I'm probably
not writing completely portably anyway and might as well use 'int'
itself; and so on.


'long' might be a better choice
for when you need an exactly 32-bit integer type.


There's nothing that requires long to be exactly 32 bits any more
than int. Both would be equally nonportable assumptions.


A type which is guaranteed to have at least 32 bits, is a better choice
than one which isn't guaranteed to have at least 32 bits,
for when you need an exactly 32-bit integer type.

--
pete
Nov 13 '05 #46

P: n/a
Dan Pop wrote:

In <3F**********@mindspring.com> pete <pf*****@mindspring.com> writes:
Arthur J. O'Dwyer wrote:
I think // comments are obscene; I have no use for variable-width
arrays; any time I need an exactly 32-bit integer type, I'm probably
not writing completely portably anyway and might as well use 'int'
itself; and so on.


'long' might be a better choice
for when you need an exactly 32-bit integer type.


Nope. long should be a better choice for when you need a 64-bit
integer type.
The only unwasteful type assignation for the usual processors
currently used in hosted implementations is:

8-bit: char
16-bit: short
32-bit: int
64-bit: long

and there are C89 implementations that do the integral types this way.
No need for a long long at all.

Having int as an "alias" for either short or long was a historical
mistake that should have been exposed and corrected long ago. The C
standards keep blessing it, instead...


That might be the case, if you're talking about implementing C,
but I beleive that Arthur J. O'Dwyer,
was talking about the the C programmer's choice
for when it comes to choosing a type, while writing C code.

I use long to implement psuedorandom number generators
which generate 32 bit values, portably.
I can't do that with int.

--
pete
Nov 13 '05 #47

P: n/a
In article <3f***********************@news.optusnet.com.au> ,
ne**@ralminNOSPAM.cc says...
I don't like it either, but it would be nice to have a well-defined
way to get packed structs on any implementation. Obviously, because
of the large performance hit, you would only use the packed attribute
where it was absolutely necessary.


Hmm, something like
#pack n
and
#pack default
to reset to whatever the compiler normally does?

--
Randy Howard _o
2reply remove FOOBAR \<,
______________________()/ ()______________________________________________
SCO Spam-magnet: po********@sco.com
Nov 13 '05 #48

P: n/a
In article <bq**********@news.tudelft.nl>, si****@jigsaw.nl says...
I would be glad when the day arrives when I can start
using them.


What compiler do you use then that you can't use them?


I use gcc, mainly, but the software's users use a variety of systems
(mostly win32, Linux, Sun, HP, AIX, Irix, ...), and I cannot rely on
anything better than a C89 compiler to be available.


If that's the case, then it hardly seems likely that the C0X extensions
which may or may not help you out will be any more useful than any of
the stuff in C99? :-)

Don't get me wrong, this is an interesting thread, but regardless of
the outcome, one has to wonder how many current C programmers will
live long enough to see C99 be available "practically everywhere",
much less whatever comes after it.

--
Randy Howard _o
2reply remove FOOBAR \<,
______________________()/ ()______________________________________________
SCO Spam-magnet: po********@sco.com
Nov 13 '05 #49

P: n/a
Sidney Cadot wrote:

James Kuyper wrote:
Sidney Cadot <si****@jigsaw.nl> wrote in message news:<bq**********@news.tudelft.nl>... ....
a ||| b ---> a ? a : b

This suffers from the fact that expression a possibly needs to be
evaluated twice, which I'd like to prevent.

That's one reason why the forms he originally gave are better than
your replacements. They both avoid the double-evaluation of 'a'.


So, you're going to second this proposal? :-)


No - I think that &&& and ||| would be so rarely used that their
meanings would become trivia questions.
Nov 13 '05 #50

193 Replies

This discussion thread is closed

Replies have been disabled for this discussion.