Is C99 the final C?
Michael B.
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);}
Morris Dovey
> 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.
glen herrmannsfeldt
> 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
those who know me have no need of my name
>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
those who know me have no need of my name
>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
Jack Klein
<use...@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
Sidney Cadot
> 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
those who know me have no need of my name
>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.
--
a signature
Simon Biber
> On Sun, 30 Nov 2003, Sidney Cadot wrote:
> > * support for a "packed" attribute to structs, guaranteeing
> > that no padding occurs.
>
> 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?
[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
> (result = a) && (result = b); /* ||| */
Or just a ? a : b
--
Simon.
those who know me have no need of my name
in comp.lang.c i read:
>On Sun, 30 Nov 2003, Sidney Cadot wrote:
[from sidney cadot's next-c wishlist:]
>> * a clear statement concerning the minimal level of active function
>> calls invocations that an implementation needs to support.
> Agreed.
how would you feel if the standard required merely, say, 10? seriously,
that's the sort of value that would have to be present (if it were
acceptable at all), and with such a trivial number (so as not to exclude
embedded systems) you'll probably just ignore it on a `substantial' system.
>> * 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.
>
> Interesting idea. This would be useful.
i don't think it's too interesting -- %p might be altered by the current
locale, so the maximum would have to be something totally silly, which
would probably induce worse silliness in the code (presumptions that other
platforms were just as low or high). i like int m = snprintf(0,0,"%p",p);
if (0 < m) { char s[m+1] /* or malloc(m+1) et seq if allocation safety is
needed and there is a recovery path */; ... } just fine.
>> * a printf format specifier for printing numbers in base-2.
>
> This, on the other hand, is kind of silly.
i do think that strto* handling arbitrary bases in [2,36] without any
corresponding tool to create strings is somewhat strange, there being other
(pseudo)symmetries. but i too have no need for the standard to demand that
such functions exist. strto* are in the standard so that their behavior
can be standardized, without which we'd be back to ato* which means we're
always trying to cope with each platform's notion of what to do on
overflow. but the hypothetical *tostr's and/or *printf conversion
specifiers wouldn't have that sort of problem, so there's not really any
need for them.
--
a signature
Walter
"Sidney Cadot" <sid...@jigsaw.nl> wrote in message
news:bqbolj$a6a$1...@news.tudelft.nl...
> * a printf format specifier for printing numbers in base-2.
Digital Mars C has supported this, %b, for nearly 20 years now! Base 2
integral constants are also supported with a leading 0b, as in:
0b0110 which is 6
>* deprecate trigraphs. Let's end the madness once and for all.
Has anyone seen trigraphs in any real code that is not a test suite or a
teaching project? I doubt anyone would miss it.
-Walter
www.digitalmars.com Free C/C++/D compilers
Servé Lau
news:pan.2003.11.30....@spamblocked.com...
> 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 ).
With that I don't agree. templates (and OO) should not be introduced in C.
If there would be one feature of C++ that I would like to see in C it would
be namespaces. namespaces encourage writing clearer names for identifiers
and they reduce accidental nameclashing. C will still be procedural only, no
existing code will be broken and it's more suitable for larger projects.
Sidney Cadot
> On Sun, 30 Nov 2003, 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.
>>
>>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.
>
> 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 ;-)
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.
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).
>>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.
>>* 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,
I don't see why. The only thing needed for this is that the target
architecture be able to adress things at the byte level.
> 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.
>>* 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)
>
> 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.
>>* deprecation of implicit casts of fp-types to integer types (perhaps
>> supported by a mandatory compiler warning).
>
> No such thing as an "implicit cast."
Obviously, some of the neurons in my head are stubbornly refusing to
reroute here. I'll have a serious talk with them about who's in charge
later on.
I meant "implicit conversions".
> 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!" ... :-)
> I think warnings about "possible loss of data" or "wider type converted
> to shorter type" are QoI issues at most.
You are probably right, this would break a lot of 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 ;-)
>
> Right. Not least because it would break just about every
> C program written in the last 10 years. And that's a somewhat
> conservative estimate.
...Not my C programs, it wouldn't ;-) ... But yes, this is a pet
peeve related wish that will not easily come true.
> If you want Java, you know where to find it. One of the great
> things about C is that it is (IMHO) more elegant than Java, with
> the latter's uber-strict typing rules and plethora of casts.
There's a lot about Java that I don't like, but I think its
type-strictness is better. A matter of taste, I think.
> Compare a C++ client program to a Java one sometime, and marvel
> at the difference. (But that's just me, and it's OT here anyway.)
>>* 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?
> I like the clear-cut distinction C makes between
> "objects" like 'const int foo' and "values" like 'enum { foo }',
> if you see what I mean.)
Yes, although I don't quite know if I agree.
>>* 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.
>
> Agreed.
Well, that was easy! Although it would be very hard to find a wording
that could fit the intent, it is too important an issue to be left
unhandled, I think.
>>* a library function that allows the retrieval of the size of a memory
>> block previously allocated using "malloc"/"calloc"/"realloc" and
>> friends.
>
> While this would be nice for newbies, it's redundant for Real
> Programmers (tm) who know how to store numbers in variables, and
> it would break lots of malloc implementations. I know, I've made
> a couple. Not all the efficient malloc implementations actually
> store the sizes of blocks anywhere.
> Unless you think it would be acceptable for
>
> msize(malloc(X)) > X
>
> in some (or all) cases; then it'd still break libraries, but the
> fix would be easier.
Something like the latter would be fine. This is not a high-priority
thing for me, but I always consider it somewhat of a waste that I have
to store the number of available slots in a dynamically growing
(realloced) array, while the heap manager is doing the same thing behind
my back.
>>* 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.
>
> Interesting idea. This would be useful.
Think so. The "%p" identifier is not restricted in any way by the
current standard, (i.e., it might emit a zillion characters in
principle); I think that is an oversight.
>>* a printf format specifier for printing numbers in base-2.
>
> This, on the other hand, is kind of silly.
Darn, I was doing quite well till here...
> Couldn't you just write your own two-line function to do this?
Of course. But printf is such a convenient function, and it would be
very little effort to add binary support (like a %b specifier).
> And after base-2, what's stopping you from demanding a printf()
> that can handle base-4, or base-9, or base-247? I think this is
> an idea whose time will never come.
Perhaps the "precision" field of a %b identifier could be used to
specify a base from 2--36, with 2 as default. Just brainstorming here
(effectively meaning you shouldn't be too harsh in your response).
> (Not to mention all those Intro Programming instructors
> who would have to find a new way of introducing recursion...)
They could always fall back on good old Fibonacci :-)
>>* 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).
> Yep.
..Alas!
>>* 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 :-)
> Given that the Standard gives minimum bounds on the size of
> any array, any *specific* qsort() implementation is O(foo) by
> definition, as one can write O(foo) <= C*foo for a specific,
> but very large, value of C.
I don't understand, unless you mean "maximum bounds" ?
> In other words, I bet you can't write a loophole-free version
> of this idea. And with loopholes, it's not worth changing the
> existing wording.
Ok.
>>* mandatory constants for many things that currently need to
>> be tested by autoconf and similar tools, e.g. endianness.
> Sounds good, until I consider that the Standard doesn't even
> mandate that integers *be* stored in one endianness or the other.
Alright, how about "precisely one of the following should be defined by
some_new_or_existing_header_file.h":
ENDIANNESS_LITTLE
ENDIANNESS_BIG
ENDIANNESS_IRREGULAR
This would cover 99% of cases in practice. At least I'd be able to write
#ifdef ENDIANNESS_IRREGULAR
#error "I'm sorry, this code only works on Big/Little Endian machines"
#endif
> Surely POSIX standardized this anyway, for those platforms that
> care so awful much about it.
>
>>* deprecate trigraphs. Let's end the madness once and for all.
>
> Haven't they been deprecated yet? ;-)
De facto, yes. I have yet to see a C book that mentions trigraphs in a
way other than "don't use this, ever".
As a side note, one of the things that annoyed me to no end in C++ is
that not only it keeps trigraphs, but it worsens things by also defining
digraph (2-character) sequences. Yew!
>>* 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.
>>* 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.
> Where's the sequence point?
After the evaluation of the expression preceding the apastrophe.
> How on earth would this construct possibly be useful to anybody?
(warning: C2017 code ahead...)
if (result=fopen("a","r") ` printf("result: %d\n", result))
{
...
}
.....instead of.....
result=fopen("a","r");
printf("result: %d\n", result);
if (result)
{
...
}
You may wonder why the first form would be preferable to the second
form. Well for one thing, it's shorter, (basically the same rationale as
for having a comma operator) and it wouldn't suffer from two evaluations
of the first expression (which might change of the right expression has
side effects).
> And who uses the reverse apostrophe character for anything, anyway? :)
Nobody, yet. (Of course, we'd need another trigraph!).
>>* 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
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.
>>* a way to "bitwise invert" a variable without actually
>> assigning, complementing "&=", "|=", and friends.
>
> Huh? You want to add logical-negation and arithmetic-negation
> "assignment operators" while you're at it? This is a purely
> vanity "improvement"; all modern compilers contain optimizers
> that can optimize "i = ~i" into the equivalent of "NOT EAX"
> anyway. No need to make the code illegible too.
Ok, you've conviced me. It always struck me as a bit irregular that it
isn't available but I can't come up with a clear syntax.
>>* 'min' and 'max' operators (following gcc: ?< and ?>)
>
> Ditto the "Huh?" This is what functions were built to
> do.
Except that functions need typed versions for all parameters, whereas
operators may be overloaded. Clears up syntax a bit.
> You know, curly braces and all that? (Question for
> those who know; Chris Torek, maybe?: Do any processors
> incorporate 'min' and 'max' instructions,
Chris is the regular "weird architecture" expert, I take it?
From my own experience: the Philips Trimedia embedded processors have
"min" and "max" opcodes. This is basically because they are VLIW
processors that thrive on undisturbed pipeline execution. Having a
branch would halt all parallel execution, which is The One Thing To Avoid.
I would expect similar opcodes to exist in IA-64, but I don't know.
>>* a div and matching mod operator that round to -infinity,
>> to complement the current less useful semantics of rounding
>> towards zero.
> I think the math library may already have these. If
> not, then yes, this is a good idea.
Thanks for the interesting points you raised. It's a nice enough subject
to think about isn't it...
Best regards,
Sidney
pete
> 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.
Sidney Cadot
> "Sidney Cadot" <sid...@jigsaw.nl> wrote in message
> news:bqbolj$a6a$1...@news.tudelft.nl...
>
>>* a printf format specifier for printing numbers in base-2.
>
>
> Digital Mars C has supported this, %b, for nearly 20 years now! Base 2
> integral constants are also supported with a leading 0b, as in:
>
> 0b0110 which is 6
Something like that would be nice. Didn't know this compileer, pity it
only targets dos/wintel systems, but I'll check it out anyway.
>>* deprecate trigraphs. Let's end the madness once and for all.
>
> Has anyone seen trigraphs in any real code that is not a test suite or a
> teaching project? I doubt anyone would miss it.
....Even the International Obfuscated C Code Contest has abolished it....
Regards,
Sidney
Servé Lau
> 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?
Sidney Cadot
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
Mark Gordon
Sidney Cadot <sid...@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.
Simon Biber
> > 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?
>
> 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.
Sidney Cadot
> On Sun, 30 Nov 2003 14:37:28 +0100
> Sidney Cadot <sid...@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
Sidney Cadot
>>>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
Sidney Cadot
>> 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
Irrwahn Grausewitz
> 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
(irrw...@freenet.de)
Sidney Cadot
> Sidney Cadot <sid...@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
Malcolm
"Jack Klein" <jack...@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 ).
>
> work?
>
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.
>
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.
Mark Gordon
Sidney Cadot <sid...@jigsaw.nl> wrote:
> Mark Gordon wrote:
>
> > On Sun, 30 Nov 2003 14:37:28 +0100
> > Sidney Cadot <sid...@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.
James Kuyper
...
> 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.
James Kuyper
> On Sun, 30 Nov 2003, Sidney Cadot wrote:
...
> > * 'min' and 'max' operators (following gcc: ?< and ?>)
>
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++.
James Kuyper
> "Arthur J. O'Dwyer" <a...@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.
James Kuyper
> 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'.
Sidney Cadot
>>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
Sidney Cadot
> Sidney Cadot <sid...@jigsaw.nl> wrote in message news:<bqcrqn$jt7$1...@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
CBFalconer
> 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.
> >
> > 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 (cbfal...@yahoo.com) (cbfal...@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
CBFalconer
> 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.
>
>
> 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 ...
Mark McIntyre
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 =---
xarax
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!
David M. Wilson
"Michael B." <use...@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.
Arthur J. O'Dwyer
On Sun, 30 Nov 2003, Sidney Cadot wrote:
>
> Simon Biber wrote:
[I wrote:]
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
glen herrmannsfeldt
> 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
Sidney Cadot
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
Sidney Cadot
> "Sidney Cadot" <sid...@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
Sidney Cadot
>>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
Chris Torek
Sidney Cadot <sid...@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.
goose
> "Arthur J. O'Dwyer" <a...@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,
goose
> 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.
>
> 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,
Dan Pop
>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: Dan...@ifh.de
Dan Pop
>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 Pop
>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 Pop
>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 Pop
>On Sun, 30 Nov 2003 14:37:28 +0100
>Sidney Cadot <sid...@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 Pop
>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.
pete
>
> On Sun, 30 Nov 2003 13:54:02 GMT, in comp.lang.c , pete
> <pfi...@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.
>
> 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
pete
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
Randy Howard
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: postm...@sco.com
Randy Howard
> >>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.
James Kuyper
>
> James Kuyper wrote:
>
> > Sidney Cadot <sid...@jigsaw.nl> wrote in message news:<bqcrqn$jt7$1...@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.
Chris Hills
<kuy...@saicmodis.com> writes
>No - I think that &&& and ||| would be so rarely used that their
>meanings would become trivia questions.
see Rule 36 of the MISTRAY-C C coding standard at
Http://mistray-c.phaedsys.org
It is the antidote to MISRA-C and should raise a smile or three.
I am looking for some code examples to illustrate some of the rules.
regards
Chris
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ ch...@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
James Kuyper
> Arthur J. O'Dwyer wrote:
>
> >
> >
> > 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).
That's because C99 now allows variable-length arrays, so an integer
constant expression is no longer required in that context. However,
they were required in C89 in this context, so if a compiler fails to
issue a diagnostic, it isn't a conforming implementation of C89. All
of the following uses of foo except the one that is marked are still
illegal in C99, because they still require integer constant
expressions:
struct bf_holder{
int bit_field:foo;
} x[foo+1] = // Only legal use of foo in this section.
{[foo] = {10}}; // Subscript for designated initializer
enum {enumeration_value=foo};
switch(x[0].bit_field)
{
case foo:
}
struct bf_holder *p=x+foo;
James Kuyper
...
> 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.
I'm curious - why do you think that? I don't know that you're wrong,
but I can't think of any reason why it would be a significant cost.
Mark McIntyre
<pfi...@mindspring.com> wrote:
*shrug*. I understand your point, but when in implementation-dependent
territory, its quite immaterial what ISO requires, its never going to
safely port anyway so abandon all hope, ye who enter here....
Dan Pop
The C programmer's choice is not that clear. See below.
>I use long to implement psuedorandom number generators
>which generate 32 bit values, portably.
>I can't do that with int.
It depends on your definition of portability. For current hosted
implementations, int will give you 32 bits, while long may give you more
than that. If you think that being portable to MSDOS is a great idea,
than you have to use long and accept the fact that you're wasting memory
on other platforms. No big deal for scalars, but it may become a
performance issue when dealing with arrays.
CBFalconer
> Mark Gordon wrote:
>
... snip ...
> >
> > 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.
IMO you cannot correct the existing enum without breaking valid
code. To gain the abilities of the Pascal enumeration requires an
entirely new type. This could be conveniently combined with the
addition of sub-range types, none of which would break old code,
but would provide much additional safety.
--
Chuck F (cbfal...@yahoo.com) (cbfal...@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
CBFalconer
> Mark Gordon <spam...@flash-gordon.me.uk> writes:
>
... snip ...
> >
> > 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.
"We" don't, but maybe you do. Such implementations are among the
most important users of C today.
E. Robert Tisdale
> [Are there any] features that the C specification currently lacks
> and which may be included in some future standardization.
The future of C is C++. The question now is,
"Will any future C++ standard adopt the features introduced in C99?"
restricted pointers,
variable-length arrays,
etc.
andr...@littlepinkcloud.invalid
>>> 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.
Nah, not really hard at all. It was Tony Hoare (now living here in
Cambridge!):
"I don't know what the language of the year 2000 will look like, but
it will be called Fortran."
- C. A. R. Hoare, 1982
> 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.)
Perfect!
Andrew.
Sidney Cadot
>>* 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.)
Especially this latter form is quite useful, expressing the idea that
'a' is to be used if it has a non-zero value, else use 'b' as a
fallback. This could be threaded, as in 'a ?: b ?: c'... I'd seriously
hope the next committee would consider this. This actually /is/ useful.
>>* 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.)
Ok, then I'd rather stick to 'x=~x', which is clearer. It has always
sort-of annoyed me that the binary operators '+' '-' .... and so on have
assignment forms, while the unary '~' hasn't.
>>* '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.
Funny, I didn't know that - weird syntax.
Personally, I would like to see min/max operators make a comeback. They
are quite often needed in practice, supported by some hardware, and
have clear algebraic foundations (max-plus algebras, and all that).
> 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*. :-) )
Interesting. The only processor I've seen that has this is the Philips
Trimedia, an embedded processor optimized for multimedia streaming. It's
a VLIW processors with five parallel instruction units. Branch
prediction failure rollback is quite expensive on these beasts.
Best regards,
Sidney
Sidney Cadot
>>>>* 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 ?
Eg.
a() ? b() : a()
is not equivalent to
a() ? b() : 0
if a() has side-effects.
Regards,
Sidney
Sidney Cadot
>>>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
Right-o. How does one become a committee member?
> or convince one committee member that it's worth promoting it.
... My idea was to convice one reader to convince one committee member
that it's worth promoting it.
At least about the stack-fault thing. That really ought to be fixed next
time 'round.
Best regards,
Sidney
Sidney Cadot
> 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.
Not if the int has 32-bits, and the long has 64 bits.
An other answer is: why? We're not in a casino, tring to improve the
odds. If you need exactly 32-bit integers, nothing besides a 32-bit
integer type will do.
Regards, Sidney
Sidney Cadot
> In article <3fca19e7$0$13591$afc3...@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?
Many compiler support something similar to this, via a #pragma pack(n).
I'd prefer something that's a bit more natural-looking though... This
that start with a '#' look like preprocessor-food to me.
Best regards,
Sidney
Sidney Cadot
> In article <bqd0e6$l7p$2...@news.tudelft.nl>, sid...@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.
We have to think about our grandchildren ... It's bad enough we're
leaving them a world without whales and a polar ice cap, let's not
worsen things by denying them a "|||" operator.
Best regards,
Sidney
Sidney Cadot
>>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.
I sort of hoped that role would be reserved for my soon-to-be-proposed
quadruple |||| and &&&& operators.
Ah well.
Best regards,
Sidney
Sidney Cadot
I would think so. More problems are expected with the C++ committee
deprecating classes, templates, and exceptions. However, the old lesson
that it's never too late to mend your ways should prevail.
The future of C++ is C.
Best regards,
Sidney
Mark Gordon
CBFalconer <cbfal...@yahoo.com> wrote:
> Sidney Cadot wrote:
> > Mark Gordon wrote:
> >
> ... snip ...
> > >
> > > 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.
>
> IMO you cannot correct the existing enum without breaking valid
> code. To gain the abilities of the Pascal enumeration requires an
> entirely new type. This could be conveniently combined with the
> addition of sub-range types, none of which would break old code,
> but would provide much additional safety.
If we are stealing bits from Pascal then I would like a set type with a
full set of set operators including cardinality (number of elements in
set if I remember my sets properly).
--
Mark Gordon
Paid to be a Geek & a Senior Software Developer
Although my email address says spamtrap, it is real and I read it.
Sidney Cadot
> If we are stealing bits from Pascal then I would like a set type with a
> full set of set operators including cardinality (number of elements in
> set if I remember my sets properly).
A hybrid monster is heaving into view....
Integer main(input, output)
{
PrintLn('Hello World')
}
Best regards,
Sidney
glen herrmannsfeldt
(snip)
> 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 ;-)
Does anyone know where /* comments came from?
There is a discussion in another group related to them, as /* is
the end of input signal for some IBM OS's. (starting in column 1).
So /* comments in those OS can't start in column 1 unless the
end of input sequence is changed.
-- glen
Arthur J. O'Dwyer
On Mon, 1 Dec 2003, CBFalconer wrote:
>
> Dan Pop wrote:
> > Mark Gordon <spam...@flash-gordon.me.uk> writes:
> > >
> > > 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.
>
> "We" don't, but maybe you do. Such implementations are among the
> most important users of C today.
Nit: "We" do (for values of "we" equivalent to "the general topicality
of comp.lang.c"), but the *C standard* and committees pertaining thereto
don't -- and that's the audience to which Sidney implicitly directed
his post.
Such [free-standing] implementations are indeed among, etc., etc.
:-)
-Arthur
Irrwahn Grausewitz
You forgot the period. ;-)
--
Irrwahn,
END.
CBFalconer
/| /| | |
||__|| | Please do not |
/ O O\__ | feed the |
/ \ | Trolls |
/ \ \|_____________________|
/ _ \ \ ||
/ |\____\ \ ||
/ | | | |\____/ ||
/ \|_|_|/ | _||
/ / \ |____| ||
/ | | | --|
| | | |____ --|
* _ | |_|_|_| | \-/
*-- _--\ _ \ | ||
/ _ \\ | / `
* / \_ /- | | |
* ___ c_c_c_C/ \C_c_c_c____________
+-------------------+ .:\:\:/:/:.
| PLEASE DO NOT | :.:\:\:/:/:.:
| FEED THE TROLLS | :=.' - - '.=:
| | '=(\ 9 9 /)='
| Thank you, | ( (_) )
| Management | /`-vvv-'\
+-------------------+ / \
| | @@@ / /|,,,,,|\ \
| | @@@ /_// /^\ \\_\
@x@@x@ | | |/ WW( ( ) )WW
\||||/ | | \| __\,,\ /,,/__
\||/ | | | jgs (______Y______)
/\/\/\/\/\/\/\/\//\/\\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
==============================================================
Simon Biber
> A hybrid monster is heaving into view....
>
> Integer main(input, output)
> {
> PrintLn('Hello World')
> }
I wouldn't mind some pascal-like declaration forms, that support
cdecl syntax:
main(argc: int; argv: pointer to pointer to char): int
{
linebuf: array 100 of char;
fp: pointer to FILE;
if(argc == 2 && (fp = fopen(argv[1], "r")) != NULL)
{
fgets(linebuf, sizeof linebuf, fp);
fclose(fp);
}
return 0;
}
--
Simon.
Chris Torek
>> (GCC offers "a ||| b" as "a ?: b", which means "a ? a : b" without
>> evaluating "a" twice.)
In article <news:bqg9li$qt0$1...@news.tudelft.nl>
Sidney Cadot <sid...@jigsaw.nl> writes:
>Especially this latter form is quite useful, expressing the idea that
>'a' is to be used if it has a non-zero value, else use 'b' as a
>fallback. This could be threaded, as in 'a ?: b ?: c'... I'd seriously
>hope the next committee would consider this. This actually /is/ useful.
It appears in other forms in other languages. For instance, the
Bourne shell has the syntax: ${var-default}, meaning "use the value
of variable foo if the variable exists, otherwise use the default".
(It nests as well: ${NEWSAUTHOR-${USER-`whoami`}}, for instance.)
In C it would have the slight flaw that "compares-equal-to-zero" is
the "unset" value, but C is pretty cavalier about zero being false. :-)
[on min/max instructions and/or conditional moves -- it is not clear
what antecedent "this" referred to:]
>... The only processor I've seen that has this is the Philips
>Trimedia, an embedded processor optimized for multimedia streaming. It's
>a VLIW processors with five parallel instruction units. Branch
>prediction failure rollback is quite expensive on these beasts.
To short-circuit this thread with another, I think Paul Hseih should
write a lot of hand-coded assembly for such hardware; he might
change his mind about what C code is "efficient". :-) (VLIW can
really strain one's perceptions. In particular, it often becomes
better to do work that may be discarded, than to avoid that work,
because the work takes zero time while the avoidance takes several
cycles. Itanium, with its odd "bundling", can be viewed as a
poor-man's VLIW, too.)
--
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.
Richard Bos
> Michael B. wrote:
>
> > [Are there any] features that the C specification currently lacks
> > and which may be included in some future standardization.
>
> The future of C is C++.
Actually, C++ is C's disreputable past.
But you know that, being part of it ;->
Richard
Paul Hsieh
> "Jack Klein" <jack...@spamcop.net> wrote:
> > 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.
> [...]
So, rather than implementing a whole new mechanism that takes the
language in another direction, why not try to implement templates
using the existing facilities and see where we are lacking?
The most obvious thing to use is macros -- in fact, I actually use
macros for templates all the time. But one has a difficult time
publishing a library of templates (you know something like a ...
STANDARD TEMPLATE LIBRARY) using such an idea because of the
following:
- The preprocessor does not have its own namespace for its own
symbols, so even something as simple as declaring temporaries and
using them with other variables passed as parameters is walking a
tight rope since the author cannot guarantee that its in a
different name space, and therefore might collide unintentionally.
For example:
#define swap(type,v1,v2) do { \
type tmp; \
tmp = v1; \
v1 = v2; \
v2 = tmp; \
} while (0)
actually doesn't work for something like swap(int,tmp,tmp1); So
using something like $tmp instead would be better -- the idea
being that "$" would be a valid symbol prefix only in the
preprocessor context and be the syntax error you would expect it
to be in ordinary C code.
- There is no type checking of parameters that can be performed at
compile time. Implementing compile time mechanisms as simple as:
assertTypeEqual(a, b, ...)
- Issues a compile time error if all the parameters are not
exactly equal in type.
assertTypeOneOf(a, b, ...)
- Issues error if a is not the same as at least one of the types
of the rest of the parameters.
assertTypeCoercable(a, b, ...)
- Issues error any pair of the set of parameters are not
coercable with each other.
would solve this problem.
- Once cannot perform computations or useful control flow at
preprocessor time. Compare with the Microsoft Assembler's
preprocessor for example. Such features would
#forc $c in "ABCDEF..."
putchar($c)
#endforc
would result in putchar('A'); putchar ('B'); ... etc.
#for $c in 0,1,2,3,4,5
# define $d #eval($c * 2)
printf ("%2d", $c);
#endfor
would result in printf("%2d", 0); print ("%2d", 2); ... etc.
#range(0,5)
would expand as 0,1,2,3,4 and so on.
Such ideas could also take away a lot of the ideas like "lambda
expansion" in languages like Lisp/Scheme.
--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/
Paul Hsieh
Well actually they probably will -- and it is in fact *that* which
will spell the final death nail to C99. Any good feature of C99 is
likely to be adopted by the C++ committee while every misfeature (like
defined complex numbers) will simply be ignored. Compiler vendors
(who, of course, make C++ compilers as well) that have passed up C99
comformance because of what pathetically little it did to try to move
forward the cause of the C language, will more likely adopt the C++
standard and just leave the remaining C99 nonsense in the trash bin
where it belongs.
Richard Bos
> Well actually they probably will -- and it is in fact *that* which
> will spell the final death nail to C99. Any good feature of C99 is
> likely to be adopted by the C++ committee
Can't be. Not needing to cast void pointers left, right and everywhere
is a very good feature of C, which will always be missing from C++.
Ditto most other features which make C a sleek, useful language and C++
a humungous monstrum.
Richard
pete
> spell the final death nail
I think you mean "sound the final death knell"
--
pete
Dan Pop
>Dan Pop wrote:
>
>>>>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
>
>Right-o. How does one become a committee member?
As I understand it, it's a matter of having enough money and free time
on your hands.
>> or convince one committee member that it's worth promoting it.
>
>... My idea was to convice one reader to convince one committee member
>that it's worth promoting it.
>
>At least about the stack-fault thing. That really ought to be fixed next
>time 'round.
Spend more time on comp.std.c and you won't be so optimistic. There are
huge loopholes in the current standard, inherited from the old standard
and no one wants to do anything to fix them. "It's not a problem in
practice" is the usual lame excuse.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan...@ifh.de
Dan Pop
>Dan Pop wrote:
>> Mark Gordon <spam...@flash-gordon.me.uk> writes:
>>
>... snip ...
>> >
>> > 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.
^^^^^^^^^^^^^^^^
>"We" don't, but maybe you do. Such implementations are among the
>most important users of C today.
Yes, we do. All the time we discuss about the main function or include
standard library functions in our solutions we implicitly ignore
freestanding implementations, where main() need not have any special
semantics and where no standard library functions may be available.
We *have* to ignore freestanding implementations, because they're
too loosely covered by the standard. If you disagree, please post
a C program (it doesn't need to do anything at all) that is portable
to *any* freestanding implementation.
And don't forget to engage your brain next time you want to object to
one of my posts.
James Kuyper
...
> *shrug*. I understand your point, but when in implementation-dependent
> territory, its quite immaterial what ISO requires, its never going to
> safely port anyway so abandon all hope, ye who enter here....
As a practical matter, implementation-dependent is not all-or-nothing.
There are degrees of implmentation-dependence; some constructs impede
portability more than others (and that includes many strictly
conforming constructs, since not all implementation are fully
conforming). Relying on 'int' being exactly 32 bits restricts the
portability of your code to a certain set of implementations. Relying
upon 'long' being exactly 32 bits restricts the portability of your
code to a different, overlapping set of implementations. It's
legitimate to worry about which of those two sets is bigger.
It's better to write code that checks for INT32_MAX and uses int32_t,
relying a supplemental "inttypes.h" if necessary until you have access
to a true C99 implementation. However, it's not completely wrong to
use the other approach.
goose
no, but if a and b are not macros which expand to a() and b(), then
a ? b : 0
is identical to
a ? b : a
<nit>
the example code above did not actually state whether or not
macros were used, or if there were any side-effects.
it *did* however, use a and b, and not a() and b().
hand
goose,
not busy today at all.
Paul Hsieh
> Michael B. wrote:
> > I was just thinking about this, specifically wondering if there's
> > any features that the C specification currently lacks, and which
>
> C89 (and its predecessors).
It has? I can't think of a single feature in C99 that would come as
anything relevant in any code I have ever written or will ever write
in the C with the exception of "restrict" and //-style comments.
There are a number of features in C99 that I will steer away from if
this issue ever comes up.
> [...] 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.
I don't think that day will ever come. In its totallity C99 is almost
completely worthless in real world environments. Vendors will be
smart to pick up restrict and few of the goodies in C99 and just stop
there.
> 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).
Hmm ... no, if you can determine that a platform does not suppose such
a fixed-width type at compile time, that's probably good enough.
> * support for a "packed" attribute to structs, guaranteeing that no
> padding occurs.
Indeed, this is something I use on the x86 all the time. The problem
is that on platforms like UltraSparc or Alpha, this will either
inevitably lead to BUS errors, or extremely slow performing code.
If instead, the preprocessor were a lot more functional, then you
could simply extract packed offsets from a list of declarations and
literally plug them in as offsets into a char[] and do the slow memcpy
operations yourself.
> * 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).
I agree. Enums, as far as I can tell, are almost useless from a
compiler assisted code integrity point of view because of the
automatic coercion between ints and enums. Its almost not worth the
bothering to ever using an enum for any reason because of it.
> * 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.
That doesn't seem possible. The amount of "stack" that an
implementation might use for a given function is clearly not easy to
define. Better to just leave this loose.
> * a library function that allows the retrieval of the size of a memory
> block previously allocated using "malloc"/"calloc"/"realloc" and
> friends.
There's a lot more that you can do as well. Such as a tryexpand()
function which works like realloc except that it performs no action
except returning with some sort of error status if the block cannot be
resized without moving its base pointer. Further, one would like to
be able to manage *multiple* heaps, and have a freeall() function --
it would make the problem of memory leaks much more manageable for
many applications. It would almost make some cases enormously faster.
> * 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.
Ah -- the kludge request. Rather than adding format specifiers one at
a time, why not instead add in a way of being able to plug in
programmer-defined format specifiers? I think people in general would
like to use printf for printing out more than just the base types in a
collection of just a few formats defined at the whims of some 70s UNIX
hackers. Why not be able to print out your data structures, or
relevant parts of them as you see fit?
> * 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).
The problem is that real string handling requires memory handling.
The other primitive types in C are flat structures that are fixed
width. You either need something like C++'s constructor/destructor
semantics or automatic garbage collection otherwise you're going to
have some trouble with memory leaking.
With the restrictions of the C language, I think you are going to find
it hard to have even a language implemented primitive that takes you
anywhere beyond what I've done with the better string library, for
example (http://bstring.sf.net). But even with bstrlib, you need to
explicitely call bdestroy to clean up your bstrings.
I'd be all for adding bstrlib to the C standard, but I'm not sure its
necessary. Its totally portable and freely downloadable, without much
prospect for compiler implementors to improve upon it with any native
implementations, so it might just not matter.
> * Normative statements on the upper-bound worst-case asymptotic
> behavior of things like qsort() and bsearch() would be nice.
Yeah, it would be nice to catch up to where the C++ people have gone
some years ago.
> 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 :-)
Anything that precludes the implementation of an actual quicksort
algorithm is a good thing. Saying Quicksort is O(n*log(n)) most of
the time is like saying Michael Jackson does not molest most of the
children in the US.
> * mandatory constants for many things that currently need to
> be tested by autoconf and similar tools, e.g. endianness.
A good idea.
> * deprecate trigraphs. Let's end the madness once and for all.
Let's not and say we did.
> * 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.
Hmmm ... its not like you can't construct a loop to do this correctly,
so I'm not sure you need a language extension just for this. I think
this is too marginal.
> * 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.
This seems too esoteric.
> * 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).
Hmmm ... why not instead have ordinary operator overloading? While
this is sometimes a useful shorthand, I am sure that different
applications have different list cutesy compactions that would be
worth while instead of the one above.
> * a way to "bitwise invert" a variable without actually
> assigning, complementing "&=", "|=", and friends.
Is a ~= a really that much of a burden to type?
> * 'min' and 'max' operators (following gcc: ?< and ?>)
As I mentioned above, you might as well have operator overloading instead.
> * a div and matching mod operator that round to -infinity,
> to complement the current less useful semantics of rounding
> towards zero.
Well ... but this is the very least of the kinds of arithmetic operator
extensions that one would want. A widening multiply operation is
almost *imperative*. It always floors me that other languages are not
picking this up. Nearly every modern microprocessor in existence has
a widening multiply operation -- because the CPU manufacturer *KNOW*
its necessary. And yet its not accessible from any language. Probably
because most languages have been written on top of C or C++. And what
about a simple carry capturing addition?
> 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.
Right -- this would just be making C into C++. Why not instead
dramatically improve the functionality of the preprocessor so that the
macro-like cobblings we put together in place of templates are
actually good for something? I've posted elsewhere about this, so I
won't go into details.
Dan Pop
>It's better to write code that checks for INT32_MAX and uses int32_t,
^^^^^^^^^^^
>relying a supplemental "inttypes.h" if necessary until you have access
>to a true C99 implementation.
That's open to debate. Hiding the real type behind a typedef has its own
costs in terms of readability and maintainabilty and it's more bug prone
than using a well defined type. It's trivial to check the assumption at
compile time, so there is no risk of generating broken code.
>However, it's not completely wrong to use the other approach.
This is true, regardless of which is the other approach ;-)
Sidney Cadot
>>Right-o. How does one become a committee member?
> As I understand it, it's a matter of having enough money and free time
> on your hands.
Ah well, won't be joining anytime soon then.
>>At least about the stack-fault thing. That really ought to be fixed next
>>time 'round.
>
> Spend more time on comp.std.c and you won't be so optimistic. There are
> huge loopholes in the current standard, inherited from the old standard
> and no one wants to do anything to fix them. "It's not a problem in
> practice" is the usual lame excuse.
I never understood why people get so worked up about practice. It's
clearly an overrated part of reality.
Best regards,
Sidney
Sidney Cadot
> no, but if a and b are not macros which expand to a() and b(), then
>
> a ? b : 0
>
> is identical to
>
> a ? b : a
>
> <nit>
> the example code above did not actually state whether or not
> macros were used, or if there were any side-effects.
>
> it *did* however, use a and b, and not a() and b().
Well, I used a and b as stand-ins for "any two expressions".
By the way, got any funny looks talking to people today?
(You forgot the </nit>)
Best regards,
Sidney
Keith Thompson
> Sidney Cadot <sid...@jigsaw.nl> wrote:
[...]
> > * support for a "packed" attribute to structs, guaranteeing that no
> > padding occurs.
>
> Indeed, this is something I use on the x86 all the time. The problem
> is that on platforms like UltraSparc or Alpha, this will either
> inevitably lead to BUS errors, or extremely slow performing code.
>
> If instead, the preprocessor were a lot more functional, then you
> could simply extract packed offsets from a list of declarations and
> literally plug them in as offsets into a char[] and do the slow memcpy
> operations yourself.
Obviously an implementation of packed structures is useless if it
leads to bus errors.
There's ample precedent in other languages (Pascal and Ada at least)
for packed structures. Typically the members are aligned on byte
boundaries rather than on the most efficient alignment boundaries.
The generated code just has to deal with any misalignment; this
shouldn't be all that difficult. (In the worst case, the compiler can
just generate calls to memcpy().) Users need to be aware that they're
trading size for performance.
One potential problem (assume 4-byte ints, normally requiring 4-byte
alignment):
_Packed struct { /* or whatever syntax you like */
char c; /* offset 0, size 1 */
int i; /* offset 1, size 4 */
} packed_obj;
You can't sensible take the address of packed_obj.i. A function that
takes an "int*" argument will likely die if you give it a misaligned
pointer (unless you want to allow _Packed as an attribute for function
arguments). The simplest approach would be to forbid taking the
address of a member of a packed structure (think of the members as fat
bit fields). Another possibility (ugly but perhaps useful) is to make
the address of a member of a packed field yield a void*.
> > * 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).
>
> I agree. Enums, as far as I can tell, are almost useless from a
> compiler assisted code integrity point of view because of the
> automatic coercion between ints and enums. Its almost not worth the
> bothering to ever using an enum for any reason because of it.
I don't think enums can be repaired without breaking tons of existing
code. And they are useful as currently defined for defining names for
a number of distinct integer values. If you want Pascal-like
enumeration types, you'd need a new construct -- but I think having
two distinct kinds of enumeration types would be too ugly for new
users.
> > * 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.
>
> That doesn't seem possible. The amount of "stack" that an
> implementation might use for a given function is clearly not easy to
> define. Better to just leave this loose.
Agreed. The limit on call depth is typically determined by the amount
of available memory, something a compiler implementer can't say much
about. You could sensibly add a call depth clause to the Translation
Limits section (C99 5.2.4.1); that would the implementation to handle
at least one program with a call depth of N, but wouldn't really
guarantee anything in general.
[...]
> > * 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.
>
> Ah -- the kludge request. Rather than adding format specifiers one at
> a time, why not instead add in a way of being able to plug in
> programmer-defined format specifiers? I think people in general would
> like to use printf for printing out more than just the base types in a
> collection of just a few formats defined at the whims of some 70s UNIX
> hackers. Why not be able to print out your data structures, or
> relevant parts of them as you see fit?
Well, you can do that with the "%s" specifier, as long as you've
defined a function that returns an image string for a value of your
type (with all the complications of functions returning dynamic
strings).
I think that base-2 literals (0b11001001) and a corresponding printf
format specifier would be sensible additions.
[...]
> > * 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.
>
> This seems too esoteric.
And you'd need a trigraph (and probably a digraph) for the reverse
apostrophe character.
If you really need such a thing, you can fake it:
( tmp = LHS, RHS, tmp )
> > * 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).
>
> Hmmm ... why not instead have ordinary operator overloading? While
> this is sometimes a useful shorthand, I am sure that different
> applications have different list cutesy compactions that would be
> worth while instead of the one above.
>
> > * a way to "bitwise invert" a variable without actually
> > assigning, complementing "&=", "|=", and friends.
>
> Is a ~= a really that much of a burden to type?
I think you mean "a = ~a".
> > * 'min' and 'max' operators (following gcc: ?< and ?>)
>
> As I mentioned above, you might as well have operator overloading instead.
Most languages that provide operator overloading restrict it to
existing operator symbols. If you want "min" and "max" for int, there
aren't any spare operator symbols you can use. If you want to allow
overloading for arbitrary symbols (which some languages do), you'll
need to decide how and whether the user can define precedence for the
new operators. And of course it would provide rich fodder for the
IOCCC.
[...]
> > 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.
>
> Right -- this would just be making C into C++. Why not instead
> dramatically improve the functionality of the preprocessor so that the
> macro-like cobblings we put together in place of templates are
> actually good for something? I've posted elsewhere about this, so I
> won't go into details.
Hmm. I'm not sure that making the preprocessor *more* powerful is
such a good idea. It's too easy to abuse as it is:
#include <stdio.h>
#define SIX 1+5
#define NINE 8+1
int main(void)
{
printf("%d * %d = %d\n", SIX, NINE, SIX * NINE);
return 0;
}
If you can improve the preprocessor without making it even more
dangerous, that's great. (I don't think I've see your proposal.)
--
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)
Sidney Cadot
> Sidney Cadot <sid...@jigsaw.nl> wrote:
>>I think C99 has come a long way to fix the most obvious problems in
>>C89 (and its predecessors).
> It has? I can't think of a single feature in C99 that would come as
> anything relevant in any code I have ever written or will ever write
> in the C with the exception of "restrict" and //-style comments.
For programming style, I think loop-scoped variable declarations ae a
big win. Then there is variable sized array, and complex numbers... I'd
really use all this (and more) quite extensively in day-to-day work.
>>[...] 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.
> I don't think that day will ever come. In its totallity C99 is almost
> completely worthless in real world environments. Vendors will be
> smart to pick up restrict and few of the goodies in C99 and just stop
> there.
Want to take a bet...?
>>* support for a "packed" attribute to structs, guaranteeing that no
>> padding occurs.
>
> Indeed, this is something I use on the x86 all the time. The problem
> is that on platforms like UltraSparc or Alpha, this will either
> inevitably lead to BUS errors, or extremely slow performing code.
Preventing the former is the compiler's job; as for the latter, the
alternative is to do struct unpacking/unpacking by hand. Did that, and
didn't like it for one bit. And of course it's slow, but I need the
semantics.
> If instead, the preprocessor were a lot more functional, then you
> could simply extract packed offsets from a list of declarations and
> literally plug them in as offsets into a char[] and do the slow memcpy
> operations yourself.
This would violate the division between preprocessor and compiler too
much (the preprocessor would have to understand quite a lot of C semantics).
>>* 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).
>
>
> I agree. Enums, as far as I can tell, are almost useless from a
> compiler assisted code integrity point of view because of the
> automatic coercion between ints and enums. Its almost not worth the
> bothering to ever using an enum for any reason because of it.
Yes.
>>* 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.
> That doesn't seem possible. The amount of "stack" that an
> implementation might use for a given function is clearly not easy to
> define. Better to just leave this loose.
It's not easy to define, that's for sure. But to call into recollection
a post from six weeks ago:
#include <stdio.h>
/* returns n! modulo 2^(number of bits in an unsigned long) */
unsigned long f(unsigned long n)
{
return (n==0) ? 1 : f(n-1)*n;
}
int main(void)
{
unsigned long z;
for(z=1;z!=0;z*=2)
{
printf("%lu %lu\n", z, f(z));
fflush(stdout);
}
return 0;
}
...This is legal C (as per the Standard), but it overflows the stack on
any implementation (which is usually a sumptom of UB). Why is there no
statement in the standard that even so much as hints at this?
>>* a library function that allows the retrieval of the size of a memory
>> block previously allocated using "malloc"/"calloc"/"realloc" and
>> friends.
>
> There's a lot more that you can do as well. Such as a tryexpand()
> function which works like realloc except that it performs no action
> except returning with some sort of error status if the block cannot be
> resized without moving its base pointer. Further, one would like to
> be able to manage *multiple* heaps, and have a freeall() function --
> it would make the problem of memory leaks much more manageable for
> many applications. It would almost make some cases enormously faster.
But this is perhaps territory that the Standard should steer clear of,
more like something a well-written and dedicated third-party library
could provide.
>>* 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.
> Ah -- the kludge request.
I'd rather see this as filling in a gaping hole.
> Rather than adding format specifiers one at
> a time, why not instead add in a way of being able to plug in
> programmer-defined format specifiers?
Because that's difficult to get right (unlike a proposed binary output
form).
> I think people in general would
> like to use printf for printing out more than just the base types in a
> collection of just a few formats defined at the whims of some 70s UNIX
> hackers. Why not be able to print out your data structures, or
> relevant parts of them as you see fit?
The %x format specifier mechanism is perhaps not a good way to do this,
if only because it would only allow something like 15 extra output formats.
>>* 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).
>
> The problem is that real string handling requires memory handling.
> The other primitive types in C are flat structures that are fixed
> width. You either need something like C++'s constructor/destructor
> semantics or automatic garbage collection otherwise you're going to
> have some trouble with memory leaking.
A very simple reference-counting implementation would suffice. But yes,
it would not rhyme well with the rest of C.
> With the restrictions of the C language, I think you are going to find
> it hard to have even a language implemented primitive that takes you
> anywhere beyond what I've done with the better string library, for
> example (http://bstring.sf.net). But even with bstrlib, you need to
> explicitely call bdestroy to clean up your bstrings.
>
> I'd be all for adding bstrlib to the C standard, but I'm not sure its
> necessary. Its totally portable and freely downloadable, without much
> prospect for compiler implementors to improve upon it with any native
> implementations, so it might just not matter.
>>* Normative statements on the upper-bound worst-case asymptotic
>> behavior of things like qsort() and bsearch() would be nice.
>
> Yeah, it would be nice to catch up to where the C++ people have gone
> some years ago.
I don't think it is a silly idea to have some consideration for
worst-case performance in the standard, especially for algorithmic
functions (of which qsort and bsearch are the most prominent examples).
>> 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 :-)
> Anything that precludes the implementation of an actual quicksort
> algorithm is a good thing. Saying Quicksort is O(n*log(n)) most of
> the time is like saying Michael Jackson does not molest most of the
> children in the US.
>>* 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.
>
> This seems too esoteric.
Why is it any more esoteric than having a comma operator?
>>* 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).
>
> Hmmm ... why not instead have ordinary operator overloading?
I'll provide three reasons.
1) because it is something completely different
2) because it is quite unrelated (I don't get the 'instead')
3) because operator overloading is mostly a bad idea, IMHO
> While
> this is sometimes a useful shorthand, I am sure that different
> applications have different list cutesy compactions that would be
> worth while instead of the one above.
... I'd like to see them. &&& is a bit silly (it's fully equivalent to
"a ? b : 0") but ||| (or ?: in gcc) is actually quite useful.
>>* a way to "bitwise invert" a variable without actually
>> assigning, complementing "&=", "|=", and friends.
>
> Is a ~= a really that much of a burden to type?
It's more a strain on the brain to me, why there are coupled
assignment/operators for neigh all binary operators, but not for this
unary one.
>>* 'min' and 'max' operators (following gcc: ?< and ?>)
>
> As I mentioned above, you might as well have operator overloading instead.
Now I would ask you: which existing operator would you like to overload
for, say, integers, to mean "min" and "max" ?
>>* a div and matching mod operator that round to -infinity,
>> to complement the current less useful semantics of rounding
>> towards zero.
> Well ... but this is the very least of the kinds of arithmetic operator
> extensions that one would want. A widening multiply operation is
> almost *imperative*. It always floors me that other languages are not
> picking this up. Nearly every modern microprocessor in existence has
> a widening multiply operation -- because the CPU manufacturer *KNOW*
> its necessary. And yet its not accessible from any language.
...It already is available in C, given a good-enough compiler. Look at
the code gcc spits out when you do:
unsigned long a = rand();
unsigned long b = rand();
unsigned long long c = (unsigned long long)a * b;
> Probably because most languages have been written on top of C or C++.
> And what about a simple carry capturing addition?
Many languages exists where this is possible, they are called
"assembly". There is no way that you could come up with a well-defined
semantics for this.
Did you know that a PowerPC processor doesn't have a shift-right where
you can capture the carry bit in one instruction? Silly but no less true.
>>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.
> Right -- this would just be making C into C++. Why not instead
> dramatically improve the functionality of the preprocessor so that the
> macro-like cobblings we put together in place of templates are
> actually good for something? I've posted elsewhere about this, so I
> won't go into details.
This would intertwine the preprocessor and the compiler; the
preprocessor would have to understand a great deal more about C
semantics than in currently does (almost nothing).
Best regards,
Sidney
CBFalconer
>
> > * 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).
>
> I agree. Enums, as far as I can tell, are almost useless from a
> compiler assisted code integrity point of view because of the
> automatic coercion between ints and enums. Its almost not worth the
> bothering to ever using an enum for any reason because of it.
On the contrary they are extremely useful in defining a series of
constants that must follow each other, and yet allow easy
revision. Compare:
#define one 1
#define two (one + 1)
#define three (two + 1)
....
#define last (something + 1)
with
enum (one = 1, two, three, .... last};
and compare the effort (and potential error) of injecting
twoandahalf in each.