Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Are you Ready For C99?

By Carnage4Life in Technology
Fri Feb 23, 2001 at 10:26:49 PM EST
Tags: Software (all tags) 		Software

ANSI and the ISO ratified the newest draft of the C standard in 1999 and unleashed the biggest changes to the language to date. New keywords, library functions, and macros are just the tip of the iceberg when it comes to the new improved C. In fact, the language is so different it is no longer compatible with C++. This article attempts to give an overview of the major changes made to the C language and also attempts to discover why no one yet seems to be affected by the new standard.

Interesting New Features

A list of features that should[0] have made it into the C99 standard is available on Thomas Wolf's webpage. Listed below are the changes that most developers would notice or care about at first use.
  1. Increased identifier size limits: specifically 63 significant initial characters in an internal identifier or macro name, 31 significant initial characters in an external identifier, and 4095 characters in a logical source line. These values were 31, 6, and 509, respectively, in C89.

    The small identifier size is the reason so many ANSI functions had terse names (strcpy, strstr, strchr, etc) since the standard only guaranteed that the first six characters would be used to uniquely identify the functions.

  2. C++ style/line comments: The characters '//' can now be used to delineate a line of commented text, just like in C++.

  3. Macros take variable arguments denoted by elipsees: Function-like macros will accept variable arguments denoted by using the ellipsis (...) notation. For replacement, the variable arguments (including the separating commas) are "collected" into one single extra argument that can be referenced as __VA_ARGS__ within the macro's replacement list.

  4. Inline functions: The C language now supports the inline keyword which allows functions to be defined as inline, which is a hint to the compiler that invocations of such functions can be replaced with inline code expansions rather than actual function calls.

  5. Restricted pointers: The C language now supports the restrict keyword which allows pointers to be defined as restricted, which is a hint to the compiler to disallow two restricted pointers from being aliases to the same object which allows for certain optimizations when dealing with the said pointers.

  6. _Bool Macro: There is a _Bool type which is a actually two valued integer type. True is defined as
    #define true (_Bool)1
    while false is defined as
    #define false (_Bool)0
  7. Variable Declarations can appear anywhere in the code block: No longer do variables have to be defined at the top of the code block.

  8. Variable length arrays: These are arrays whose size is determined at runtime.

  9. Variable declarations in for loops: Variables can now be declared and initialized in for loops just like in C++ and Java.

  10. Named initialization of structs: The members of a struct can now be initialized by name such as is done in the code block below
    struct {float x, y, z;} s = { .y = 1.0, .x = 3.5, .z = 12.8};
  11. New long long type: There is a new type called long long which is at least 64 bits and can be both signed or unsigned. The new suffixes "LL" or "ll" (and "ULL" or "ull") are used for constants of the new long long type.

  12. Functions must declare a return value: Function return types no longer defaults to int if the function declares no return type.

  13. Last member of a struct may be an incomplete array type. : This is to support the "struct hack" which works on most existing C compilers already. A code example of the struct hack is shown on Thomas's site.

  14. Addition of _Complex and _Imaginary number types: A boon for programmers doing any sort of advanced math in their programs.

  15. Multiple uses of a type qualifier are ignored after the first occurence: If a type qualifier appears several times (either directly or indirectly through typedefs) in a type specification, it's treated as if it appeared only once. E.g.
    const const int x;
    is the same as
    const int x;
C++ Incompatibilities

The aforementioned features are rather impressive but one soon realizes that this means that C is no longer a subset of C++. There is a list of the major incompatibilities between the current ISO standards for C and C++ on David Tribble's webpage. At this point it is still too early to see if either C or C++ will be harmed by this development but it is clear that there will be some growing pains once C99 adoption becomes widespread.

Bjarne Stroustrup mentioned in a recent interview with LinuxWorld that he would have liked for both languages to be compatible and would favor a technical committee whose express purpose would be integrating both languages, but doubts the possibility of this coming to pass. Stroustrup also contrasted how C's technical commitee decided to implement most of the added functionality via changes to the actual C language against the C++ approach which was by adding additional libraries.

Compiler support

After describing all the exciting new features of C99, one would expect there to be more awareness of the standard by now but there isn't. The primary reason for the lack of awareness of C99 is the fact that compiler support at the current time is practically non-existent. Here is the status of the major compiler vendors for the development platforms that I'm interested in:
  1. Microsoft: A search on Microsoft's site for C99 draws a total blank. It looks like Microsoft does not plan to upgrade the C compiler that ships with Visual C++ to cover the C99 standard.

  2. Borland: A search on Borland's site for C99 also draws a blank. Again it looks like exclusive C++ development has won over keeping their C compiler up to date.

  3. Comeau Computing: The most recent version of their compiler (version 4.2.45.1) which is available for online testing claims to support a large number of features from C99. The compiler has not yet been released but can be tested online by submitting code snippets in an HTML form.

  4. SAS Institute: SAS/C version 7.0 supports the "long long" type, inline functions and a few of the preprocessor directives.

  5. Edison Design Group: The EDG C++ front end supposedly supports both C89 and C99 as well as Microsoft C++ and ANSI/ISO C++.

  6. GNU: GCC has a status page of C99 compliance which shows that they are quite close to becoming fully compliant with the C99 standard.


Where To Get It

If you are interested in being the first kid on your block who knows the finer points of restricted pointers and variable argument macros, you can purchase the C99 standard online from ANSI. Finally no discussion of C99 is complete without a reference to Dennis Ritchie's opinion of the C99 standard.

[0] I didn't buy a copy of the standard, so I cannot guarantee that everything on that site made it into the standard although there is a good chance that everything did.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
Are you looking forward to using C99?
o Yes 34%
o No 16%
o Undecided 21%
o Don't Use C 27%

Votes: 103
Results | Other Polls

Related Links
o Thomas Wolf's webpage
o code example of the struct hack
o list of the major incompatibilities between the current ISO standards for C and C++
o David Tribble's webpage
o recent interview with LinuxWorld
o search on Microsoft's site for C99
o search on Borland's site for C99
o available for online testing
o SAS/C version 7.0
o EDG C++ front end
o status page of C99 compliance
o purchase the C99 standard online
o Dennis Ritchie's opinion of the C99 standard
o Also by Carnage4Life

Display: Sort:
Are you Ready For C99? | 242 comments (238 topical, 4 editorial, 0 hidden)
Some reservations (2.81 / 11) (#4)
by Inoshiro on Fri Feb 23, 2001 at 08:11:26 PM EST

Some of these new 'features' look like concesions for people who can't learn the personal discipline required to create C code effectively.

* Variable Declarations can appear anywhere in the code block: No longer do variables have to be defined at the top of the code block. and * Variable declarations in for loops: Variables can now be declared and initialized in for loops just like in C++ and Java.

Way to encourage bad code. Why not just make us use VB? As for adding long long, why not rename long long to huge? I'd hate to see 128bit processors -- can you say long long long? Or will they add the 'really' keyword? A keyword like 'huge' would've been more effective.



--
[ イノシロ ]
Damned committees... (3.40 / 10) (#9)
by trhurler on Fri Feb 23, 2001 at 09:26:56 PM EST

C99 has precisely one new feature that matters. That's the restrict keyword. The longer identifiers are nice, but that's not really a new feature. The C++ style comments serve no proper purpose and make the language bigger; this is C, not perl. The varargs macros are evil incarnate; macros cause enough problems without the ability to further complicate them. If your compiler is too stupid to figure out when it should inline functions without being told, you need a new compiler. Bool is like the // comments; it is pointless language bloat. Variable declarations should NOT be allowed anywhere but the top of a code block; if you want them elsewhere, you are wrong. Variable length arrays are nice, but again, they complicate the language, and there's no reason you ever need them given the presence of malloc. Variable declarations in loops and named initialization of structs are more syntax sugar; see my opinion of // comments above. The long long type, while a convenient hack to avoid modifying old code, is not really necessary, and it complicates things. Making long 64 bits doesn't create problems for most old code anyway. Functions must declare a return type - great, but that's not really a new feature so much as it takes away a bad old one. The standard should have specifically DISALLOWED the struct hack, not endorsed it. It is an example of what Dennis Ritchie once aptly termed "unwarranted chumminess with the compiler." The complex and imaginary number support is nothing but bloat; it is easily added in a library, and doing it that way doesn't lose you much of anything - C is a general purpose language, not a newer version of Fortran! The multiple identifier prefix elimination is nice, but it is more of a language bugfix than a feature per se, and it really only improves the compiler's ability to deal with badly written code - the real fix is to not write bad code.

Dennis Ritchie was right - the committee should have worked harder to not add crap to the language. C is beautiful because it is small.

--
'God dammit, your posts make me hard.' --LilDebbie
Microsoft C (3.40 / 5) (#12)
by ucblockhead on Fri Feb 23, 2001 at 09:57:14 PM EST

Microsoft: A search on Microsoft's site for C99 draws a total blank. It looks like Microsoft does not plan to upgrade the C compiler that ships with Visual C++ to cover the C99 standard.

Very likely, especially considering that there are fairly trivial aspects of the C++ standard that they still don't support after five years. Between that, their move away from C++ in general with C#, and the fact that they mostly pretend straight C doesn't exist (though they do compile it), I wouldn't ever expect them to support any of this.


-----------------------
This is k5. We're all tools - duxup

My breakdown of the new features... (3.69 / 13) (#15)
by DJBongHit on Fri Feb 23, 2001 at 10:55:49 PM EST

I may be showing my bias towards old-school C here, but I'll throw in my 2 cents (and a bit of pocket lint).

C++ style/line comments: The characters '//' can now be used to delineate a line of commented text, just like in C++.
I don't think this is necessarily a good thing - I mean, it lets you type in comments a bit quicker, but I think it's at a cost of a bit of readability.

Macros take variable arguments denoted by elipsees: Function-like macros will accept variable arguments denoted by using the ellipsis (...) notation. For replacement, the variable arguments (including the separating commas) are "collected" into one single extra argument that can be referenced as __VA_ARGS__ within the macro's replacement list.
Oooh. Now that's nifty... I always wanted to be able to do that in a macro.

Inline functions: The C language now supports the inline keyword which allows functions to be defined as inline, which is a hint to the compiler that invocations of such functions can be replaced with inline code expansions rather than actual function calls.
Didn't C89 have this already? I know that at least every compiler I've used supported this (although it wasn't mandatory for the compiler to actually listen to you, and still doesn't appear to be).

Restricted pointers: The C language now supports the restrict keyword which allows pointers to be defined as restricted, which is a hint to the compiler to disallow two restricted pointers from being aliases to the same object which allows for certain optimizations when dealing with the said pointers.
By this you mean that 2 restricted pointers can't point at the same memory address, correct? I'm not sure I'm grasping the usefulness of this. How does this allow the compiler to speed things up?

_Bool Macro: There is a _Bool type which is a actually two valued integer type.
God. Useless. And I can see this being a problem for somebody who either doesn't quite know the language or simply hasn't thought out their algorithm. In a situation where you might've done something like this in the past:

if (SomeFunction()) {DoThis();}

Now somebody may be tempted to, for readability or some other reason, do something like this:

if (SomeFunction() == true) {DoThis();}

This appears to be the same on first glance, but while the first one DoesThis() for any non-zero return value from SomeFunction(), the second one only does it when SomeFunction() returns 1. It seems like a way to subtly sneak hard-to-find bugs into code. Someone who's familiar with C's intricacies would probably catch the error, but a less-skilled programmer may not.

Variable Declarations can appear anywhere in the code block: No longer do variables have to be defined at the top of the code block.
Dear God, no. This is just another way to decrease coding standards to the lowest-common-denomiator.

Variable length arrays: These are arrays whose size is determined at runtime.
Good. I always wondered why C didn't allow you to do this and instead made you malloc() it out yourself.

Variable declarations in for loops: Variables can now be declared and initialized in for loops just like in C++ and Java.
Double-God-no.

Named initialization of structs: The members of a struct can now be initialized by name such as is done in the code block below struct {float x, y, z;} s = { .y = 1.0, .x = 3.5, .z = 12.8};
Ahh. Excellent :) Initializing structs in C89 is entirely too much of a pain in the ass unless you do it when variable is declared.

Functions must declare a return value: Function return types no longer defaults to int if the function declares no return type.
Good idea, but I think it's a bit too late to throw a rule like this into the mix - this is gonna break an awful lot of code.

Last member of a struct may be an incomplete array type. : This is to support the "struct hack" which works on most existing C compilers already. A code example of the struct hack is shown on Thomas's site.
Neato. Not sure I'd use it much, but I can definitely see this being useful in a variety of situations.

Addition of _Complex and _Imaginary number types: A boon for programmers doing any sort of advanced math in their programs.
This does ABSOLUTELY NOT belong as a part of the C language - writing a library to support them is simple with the already-existing variable types. One of the reasons I like C is that it doesn't tend to suffer from feature bloat. Let's not start now.

Multiple uses of a type qualifier are ignored after the first occurence: If a type qualifier appears several times (either directly or indirectly through typedefs) in a type specification, it's treated as if it appeared only once.
Are you KIDDING me? C should not try to work around a programmer's badly written code - it's the programmer's job to write proper code to begin with.

~DJBongHit

--
GNU GPL: Free as in herpes.
C (3.83 / 6) (#18)
by FigBug on Fri Feb 23, 2001 at 11:48:15 PM EST

> In fact, the language is so different it is no longer compatible with C++.

C never has been a subset C++, so they never have been 'compatible'

Things like sizeof character constants, recursive calls to main(), empty parameter list, casting, and a few other things I forget.

Post in comp.lang.c and say you are programming in C/C++ and you'll see what I mean.

I wanted operator overloading! Waaaah! (3.33 / 3) (#19)
by 42 on Fri Feb 23, 2001 at 11:56:04 PM EST

Much as I distrust and dislike the whole OOP thing, when I came across operator overloading in C++, I started lusting for it in C. It is so cool to define an arbitrary datatype A, define an operation that makes sense for it (for example +), and then use that operator on two variables of the same type thus :

A x,y,z;

/* Initialize x and y */

z = x + y;

....and there you have it - the power to express your ideas in a few lines elegantly and in a way that closely resembles what you would have written in pseudocode.

And while I'm here whining away, could you please give me some templates too?

New rules..... GCC support? (2.40 / 5) (#21)
by Blarney on Sat Feb 24, 2001 at 12:07:50 AM EST

It may or may not be a good thing to be able to declare variables whenever you want. I've seen a few demented people write code like this in C in order to get the "declare when you want" effect :

int foo()
{
  char * zebra = "640K is all ";
...... page or so of code ....
  /* oh crud, I need another variable */
  {
  char * horse = "all your base";
...... more code, blah, blah, blah,
  /* just add one more bracket here, nobody will ever notice :) */
}}
 So this is not really a big change, all it has to do is insert a couple "virtual" curly braces!

One thing that I'm wondering about all these changes is how long GCC will take to support them? While I understand that GCC is not officially standards compliant, in practice it is pretty much closer to standard C/C++ then most commercial compilers - MSVC, MIPS Pro, etc..... It'll be a sad and lonely standard if GCC won't run it.

Imaginary & Complex (3.50 / 4) (#27)
by SlydeRule on Sat Feb 24, 2001 at 01:09:44 AM EST

N. Addition of _Complex and _Imaginary number types: A boon for programmers doing any sort of advanced math in their programs.
Since they have a separate _Imaginary type (as opposed to using a float or double), it sounds like they might've gone with the more involved method of dealing with imaginary and complex numbers. See this paper (PDF) by Kahan and Darcy for some details.

As I understand it (and I don't pretend to really understand it), the primary issue revolves around the necessity of distinguishing between -0.0i and +0.0i. From the cited paper:

A streamline goes astray when the complex functions SQRT and LOG are implemented, as is necessary in Fortran and in libraries currently distributed with C/C++ compilers, in a way that disregards the sign of ± 0.0 in IEEE 754 arithmetic and consequently violates identities like SQRT( CONJ( Z ) ) = CONJ( SQRT( Z ) ) and LOG( CONJ( Z ) ) = CONJ( LOG( Z ) ) whenever the COMPLEX variable Z takes negative real values. Such anomalies are unavoidable if Complex Arithmetic operates on pairs (x, y) instead of notional sums x + i·y of real and imaginary variables. The language of pairs is incorrect for Complex Arithmetic; it needs the Imaginary type.
A controversial Complex Arithmetic Extension to the programming language C incorporating that correction, among other things, has been put before ANSI X3J11, custodian of the C language standard, as part of the C9X proposal. It is controversial because it purports to help programmers cope with certain physically important discontinuities by suspending thereat ( and nowhere else ) the logical proposition that " x == y " implies " f(x) == f(y) ". Many a programmer will prefer this anomaly to its alternatives.
Declarations anywhere (3.42 / 7) (#36)
by arnald on Sat Feb 24, 2001 at 05:37:37 AM EST

I feel I must comment...

Why do so many people feel this is a bad thing? I think it's probably the most important improvement of ALL the new C99 features.

The simplest way to avoid silly mistakes and problems with variables is to make sure they are initialised as soon as they are declared (this is what Stroustrup recommends). But you can't generally do this at the top of the block. So you have a load of declared variables that are unitialised; dangerous!

With unrestricted declarations, you can introduce the variable WHEN you need it, and when it makes SENSE to introduce it.

Moreover, anything that allows restricted-scope declarations has got to be a good thing in large projects.

So why don't more people seem to share my views?!



VA_ARG macros (1.25 / 4) (#37)
by pellemell on Sat Feb 24, 2001 at 07:43:42 AM EST

Do we really need variable argument macros?
How about supporting inline keyword for functions instead?

On declaring variables anywhere (4.12 / 8) (#38)
by Pseudonym on Sat Feb 24, 2001 at 08:20:31 AM EST

<RANT SERIOUSNESS="half">

I'm shocked at what I'm hearing from those who don't like declaring variables anywhere. Haven't you people ever heard of the principle of latest binding? It should be etched in the skull of every programmer.

AEleen Frisch called it the virtue of "laziness". Kent Beck called it the rule of "you aren't gonna need it". Don Knuth summed one instance of the rule nicely with "premature optimization is the root of all evil". It all boils down to one simple generalisation: Don't type it until you need it. Declaring a variable too far before its first use violates this cornerstone of programming. So there.

</RANT>

On a more serious note, something that nobody seems to have brought up yet is that the argument for declaring variables anywhere is much stronger in C++ than it is in C. The reason is that declaring a variable in C (assuming there's no initialiser part) does nothing more than tell the compiler that space will be needed for a variable of such-and-such-a-type with this name at some point in the enclosing scope. When you declare a C++ variable, on the other hand, you might also call the type's constructor. If all the data that you need for the real initialisation of the variable is not available yet, you would need to re-initialise when it does become available if you were forced to declare it too early. To avoid this cost, C++ lets you declare the variable when all the data needed to construct it is ready.


sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
My take. (4.42 / 7) (#55)
by i on Sat Feb 24, 2001 at 11:57:34 AM EST

  • Long identifiers -- identifier length should not be limited.
  • C++ style comments -- cool, because block comments are brain damage.
  • Vararg macros -- it's about time.
  • Inline functions -- gosh, another register keyword! When will people learn.
  • Restricted pointers -- probably the single extension that's worth a new round of standartisation.
  • Bool -- good, all those user-defined bools (one per library) must die.
  • Declarations anywhere -- well, there are two schools of thought here, I can't really make up my mind.
  • VLA -- good, alloca must die, but this means sizeof is not a compile-time expression anymore, and this is Not A Good Thing, and a source of some major incompatibilities with C++.
  • Declarations in loops -- way cool.
  • Named initialisation -- way cool.
  • Long long -- this is serious brain damage. C99 already has sized integer types (like int32 and int64). Why on earth anybody would use long long instead of one of those?
  • Functions must declare a return value -- just about time.
  • Struct hack -- ok, everybody uses it anyway.
  • Complex -- seems like another source of incompatibilities with C++.
  • Type qualifiers -- ?? It's Ok with typedefs, but directly? Why?
All in all, it's a pity the committee didn't consider C++ compatibility.
—
and we have a contradicton according to our assumptions and the factor theorem
C/C++ User's Journal (3.50 / 2) (#65)
by jeanlucpikachu on Sat Feb 24, 2001 at 02:30:25 PM EST

http://www.cuj.com/ They've ran some interesting articles on C99 already. Worth a read if you don't want to find out about it through trial & error.

--
Peace,
Capt. Jean-Luc Pikachu AIM: jeanlucpikachu
A response to various criticisms (4.50 / 4) (#66)
by damien on Sat Feb 24, 2001 at 02:57:06 PM EST

A number of people are unhappy about various additions to the standard -- C++-style // comments, looser rules on where variables can be declared, long long, etc.

One thing to realize about the standards committee is that it exists, among other things, to standardize common practice. A number of members were very much against long long, but it still made it in. The reason? Virtually every compiler out there supports it already. A lot of code uses it. For better or worse, it's become a part of C in practice; all the committee did was formalize this.

The same thing applies to // comments. Support for this is so widespread now that adding them to the standard merely acknowledges the current state of affairs.

It's not perfect, but it works. New features get tested in the real world; the ones that survive the court of popular opinion get standardized. Compilers comply to the standard faster, since they already supported many of the changes.

The real botches occur when things get added that weren't common practice. Consider trigraphs, for example.

-Damien

Not so good for embedded developers (4.25 / 4) (#77)
by pw201 on Sat Feb 24, 2001 at 07:56:19 PM EST

I work on hard real time embedded systems, mostly in C (and I'm not speaking for my employer :-). I can't see many people in my application area going for C99 in a big way. We're already using restricted subsets of C90. C99 seems to add a lot of stuff which will just get restricted away again.

Let's see:

  • Identifier size limits: Good idea, fair enough, no problem.
  • Variable argument macros: The preprocessor is the source of enough errors already without adding this.
  • Inline functions: probably a good idea.
  • _Bool: Do the results of comparisons now have this type? What happens when people compare things to this type: are non-zero integer types going to compare equal to "true"? Do comparisons evaluate to a _Bool type? It's possibly a good thing to have a type for flags and so on, but not sure whether it'll end up causing confusion.
  • Declare variables anywhere: may lead to messy code. As people have pointed out, C already allows you do so this by starting a new block.
  • Functions must declare return type: Finally, something unequivocally good.
  • Complex types: What happened to the elevator controller argument? I find the inclusion of complex types bizarre.

ISTM that the good bits of C99 are mostly things which do away with poor coding practices which can already be caught by static analysis tools. I don't feel C99 has any significant advantages over C90 for me, in fact, quite the reverse.

No symmetric treatment of void (3.25 / 4) (#85)
by SIGFPE on Sat Feb 24, 2001 at 11:13:40 PM EST

I think C should treat a void like any other type. For example this should be valid:

void f() {
void a;
return a;
}
 I've always thought it weird that void is treated in a special way and it's useful to be able to do this when writing certain types of macro that can take a type as argument. This would add no bloat to the compiler. C++ does it though that's not an argument for anything.
SIGFPE

C++ with no class (4.50 / 4) (#109)
by ucblockhead on Sun Feb 25, 2001 at 11:48:28 AM EST

It came to me while responding to another post that many of these features can be gotten today simply by using C++ and refraining from using classes, member functions in structures, templates and other OOP features.

That gives you A,B,D,E,F,G,H(I think)I and L. All today.

No one says that just because you compile a ".cpp" file instead of a ".c" one, that you have to use classes, streams, templates or any of that other stuff.


-----------------------
This is k5. We're all tools - duxup

Some things I find confusing (3.00 / 2) (#119)
by nymia_g on Sun Feb 25, 2001 at 05:02:26 PM EST

I confused. I think what most posters mean about declaration is actually initialization.

In C, or what I know about C, I can declare storage anywhere in the block. These declarations, if they're local, would then be defined on the local stack. So there, I think I'm explaining myself now. What C99 is probably saying is storage initialization will happen irregardless of location.

C99 does not change anything, it adds new... (4.00 / 1) (#161)
by C on Mon Feb 26, 2001 at 10:44:32 AM EST

C99 changes this, which is unfortunate.
You are merging two things which should not.

Yes, one can write valid C code which is at the same time valid C++ code. Yes, this is the way to go if you want to be portable. But C99 does not change anything here. It does not remove (i.e. in practice the restrictions of C99 vs. C90 are not a problem¹), nor it does add anything (i.e. you shoult not use any of the new feature, if you want to stay portable). You should stick to the common idiom (which is the subset of C you were referring), which was also acceptable to both C90 and C++98 compilers, and will be accepted by the forecoming C99 compilers. And this will continue this way for a number of years... No change here.

At the same time, C99 brings a lot of new possibilities (inline, longer identifiers, intmax_t, etc.), but this can be seen as an extension of C90. For a part, these extensions are not compatible with C++98 (but one can expect of the next revision of C++ Standard to get some of them; one can also expect the C/C++ compilers vendors to accept them as extensions in C++). At the same time, most compilers do not support them either. And when they'll do, clearly if you are using these new features, then you will be using brand new stuff, exactly what had happened when you wrote your first C++ classes some years ago. And this new stuff brings some advantages, but you cannot ask for backward compatibility at the same time, and everybody knows that.

 

¹: Yes, I know of the heated discussions, for example in comp.std.c, about some C99's new stuff to create problem with well-written code, for example with the assumption of long being the widest integer type available, or size_t to be safely casted to unsigned long, two assumtions that are not valid any more with C99. I consider this to be theological discussions best left to this very forum.

gazillion... (3.00 / 1) (#163)
by C on Mon Feb 26, 2001 at 11:24:44 AM EST

The largest function of any of my programs is aproxamitely 30 to 35 lines.
I tend to have case's to stand in different lines that the code they triggers, and the break; in yet another line. I assume you do the same.

Now, more than once, I needed to handle a switch with more than 10 different "cases"...
In fact, it looks like to me the most interesting use of switch: to stay readable and manageable even with more than 10 case's hence more than 35 lines.

I almost never considered replacing the switch into the equivalent cascade of if + else, and dispatching the if's between various functions, except when dealing with bad code generators in time critical parts of the program.
Also, arrays of function pointers are great when you are at the top level of an editor, but the (mandatory, no inline here) implied cost of a call with the needed pointer(s) to the context is less desired at the very heart of the critical section...
And finally, I consider a 131-line declaration of an array of function pointers to be exactly as long as 131 lines of code in a function... ;-) but I am not a style teacher!

2 restricted ptrs to same loc: don't do that! (4.00 / 1) (#171)
by C on Mon Feb 26, 2001 at 11:56:24 AM EST

Now what happens if the programmer marks 2 pointers as restricted, but then later in the code they end up pointing to the same location?
I would say that if it is able to figure the situation, any half-decent compiler will at least flag the probable wreckage, and much better will refuse to call the function with the restricted parameters.

Now the problem is how to figure the situation. The whole purpose of restrict is just to help the compiler; so we can be sure that there are cases where even the smarter compilers will have problem to really know if two pointers passed as two arguments are in fact aliases or not. And furthermore, to dig into the intrincaties of the graphes of calls, the smart compiler will need quite an amount of time, and perhaps the programmer does not in fact want to allow it to spent its precious time this way, and would like to see the compiler do more productive tasks. This is where restrict is aimed.

As a result, you cannot be sure that the compiler will even flag the dubious use of restrict. Hence, you as a programmer has to make sure that restricted pointers are not aliased. And thou shalt not do that!

What about Objective C? (3.50 / 2) (#185)
by Futeiru on Mon Feb 26, 2001 at 07:58:18 PM EST

Everyone is so busy talking about C++ incompatabilities they forget that Objective C is reemerging with the advent of OS X as a large programming language.

I'm looking at the standard, and I'm curious what ramifications the new standard might have on Objective C (which I code in as often as possible, it's my current favorite language).

The way I see it, this can't affect things in ObjC that much, a few minor tweaks and it's just a speedbump, but I am far from an expert. Does anyone know what kind of ramifications it will have on Objective C?

The *Real* link for Dennis Ritchie's comments (none / 0) (#240)
by phliar on Mon Mar 05, 2001 at 04:59:51 PM EST

The link given above for Dennis Ritchie's comments on the language is bogus: if you refuse cookies, it just comes up as a blank page.

And it's just a frame provided by those assholes, er I mean fine redistributors of e-commerce news or whatever, around the original article by Linux World.

Go to the Linuxworld article on Dennis Ritchie's comments on the new features in C99.


Faster, faster, until the thrill of...

Shifts (none / 0) (#242)
by NeXtAgain on Wed Mar 28, 2001 at 04:16:15 AM EST

Hope this isn't spam...

I guess there's no compiler around any longer doing it wrongly but my lint still warns me:

Shifts (left and right) of signed values are handled wrongly by some compilers.

Now here are my questions:
Is it defined?
If so how? (correctly I do hope)
And when? With C99? Earlier?

I'm really frustrated with this warning since one of the main advancements of higher languages is to free me of having to think of using either ASR or LSR...

Of course you can come over this warning by using * and / instead but it's so much easier to implement (and read) block floating point using shift operations.

Are you Ready For C99? | 242 comments (238 topical, 4 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest © 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!