473,889 Members | 1,734 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Is C99 the final 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 .

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_SOMETHI NG \
#define FOO_bar_SOMETHI NG_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&25 5);if(a){printf (".");o(--a);}}
main(){do{o(3); puts("");}while (++i);}

Nov 13 '05
193 9701
In <bq**********@n ews.tudelft.nl> Sidney Cadot <si****@jigsaw. nl> writes:
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: Da*****@ifh.de
Nov 13 '05 #81
In <3F************ ***@yahoo.com> CBFalconer <cb********@yah oo.com> writes:
Dan Pop wrote:
Mark Gordon <sp******@fla sh-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.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #82
Mark McIntyre <ma**********@s pamcop.net> wrote in message news:<h9******* *************** **********@4ax. com>...
....
*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.
Nov 13 '05 #83
Sidney Cadot <si****@jigsaw. nl> wrote in message news:<bq******* ***@news.tudelf t.nl>...
goose wrote:
>* 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.


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.
Nov 13 '05 #84
Sidney Cadot <si****@jigsaw. nl> 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).


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.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/
Nov 13 '05 #85
In <8b************ **************@ posting.google. com> ku****@wizard.n et (James Kuyper) writes:
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 ;-)

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #86
Dan Pop wrote:
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

Nov 13 '05 #87
goose wrote:
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

Nov 13 '05 #88
qe*@pobox.com (Paul Hsieh) writes:
Sidney Cadot <si****@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_Keit h) 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)
Nov 13 '05 #89
Paul Hsieh wrote:
Sidney Cadot <si****@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
Nov 13 '05 #90

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

1
3456
by: Anthony Martin | last post by:
I've been reading the Java Language Specification, and in Chapter 16 there's an interesting topic called Definite Assignment. http://tinyurl.com/3fqk8 I'm wondering about the idea of "Deferred Final Automatic Variables" like the following: void unflow(boolean flag) { final int k;
14
23153
by: Medi Montaseri | last post by:
Hi, I think my problem is indeed "how to implement something like java's final in C++" The long version.... I have an abstract base class which is inherited by several concrete classes. I have a group of methods that I'd like to implement in the base class
48
8734
by: David J Patrick | last post by:
I'm trying to rewrite the CSS used in http://s92415866.onlinehome.us/files/ScreenplayCSSv2.html. using the w3.org paged media standards as described at http://www.w3.org/TR/REC-CSS2/page.html The ScreenplayCSS is flawed, for several reasons; -overuse of <div id= tags -doesn't scale screen resolutions (convert from px to in, pt ?) -no media="print" (how much coule be shared between "screen" & "print") -no automatic page breaks (with...
10
5126
by: Bezalel Bareli | last post by:
I know I have seen some threads on the subject long time ago and it was using a virtual base class ... in short, what is the nicest way to implement the Java final class in c++ Thanks.
14
1780
by: My4thPersonality | last post by:
Has the fact that both Java and C# are garbage collected, and C++ in not, anything to do with the fact that there is no language item to prevent a class from being inherired from? I once read that Java and C# implement this feature for preformance, but the C++ creators said it was not worse the effort. So because Java and C# are garbage collected, in their case is it worse the effort? What is the connection?
1
8625
by: silverburgh.meryl | last post by:
I am trying to convert this code from java to c++: public final class Type { public static final int DEFAULT = 1; private static int index = 2; public static final int COLUMN1 = (int) Math.pow(2, index++); public static final int COLUMN2 = (int) Math.pow(2, index++); public static final int COLUMN3 = (int) Math.pow(2, index++); public static final int COLUMN4 = (int) Math.pow(2, index++);
5
1403
by: Anthony Baxter | last post by:
On behalf of the Python development team and the Python community, I'm happy to announce the release of Python 2.4.3 (final). Python 2.4.3 is a bug-fix release. See the release notes at the website (also available as Misc/NEWS in the source distribution) for details of the more than 50 bugs squished in this release, including a number found by the Coverity Scan project. Assuming no major bugs pop up, the next release of Python will be...
14
3004
by: Rahul | last post by:
Hi Everyone, I was searching for final class in c++, and i came across few links which suggests to have the constructor of the, to be final class, as private so that any derived class's constructors can't access the same. class C { private:
1
1710
by: Rajib | last post by:
Not that this serves any real purpose, but gcc allows me to do some hack like this: class hide_A { public: class A { public: virtual int final() { return 42; } };
0
9967
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
11202
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
1
10895
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
10443
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
9611
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
1
7998
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
5830
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
0
6029
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
4650
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.