some well known stupidness in c99

F

fir

It is sad to say so but there is some real
and terrible stupidnes in c99. When i wrote
programs in c (and I am involved c user) I
just use const int for array boundaries but
in c99 (and some previous too, terribly) it
will not compile (see for example
http://stackoverflow.com/questions/1712592/variably-modified-array-at-file-scope ) It is terribly wrong
thing for ppl who just wants to use const int to this
purposes and not to use preprocesor - as I do.
It is terribly stupidness in my opinion, it have to
be changed.
 
T

Thomas Richter

Am 18.11.2012 10:21, schrieb fir:
It is sad to say so but there is some real
and terrible stupidnes in c99. When i wrote
programs in c (and I am involved c user) I
just use const int for array boundaries but
in c99 (and some previous too, terribly) it
will not compile (see for example
http://stackoverflow.com/questions/1712592/variably-modified-array-at-file-scope ) It is terribly wrong
thing for ppl who just wants to use const int to this
purposes and not to use preprocesor - as I do.
It is terribly stupidness in my opinion, it have to
be changed.

This is valid C++ code, thus one option would be just to switch to C++.
In C, however, const is probably not quite what you expect it to be.
 
S

SG

Am 18.11.2012 10:21, schrieb fir:
It is sad to say so but there is some real
and terrible stupidnes in c99. When i wrote
programs in c (and I am involved c user) I
just use const int for array boundaries but
in c99 (and some previous too, terribly) it
will not compile (see for example
http://stackoverflow.com/questions/1712592/ ) It is terribly wrong
thing for ppl who just wants to use const int to this
purposes and not to use preprocesor - as I do.
It is terribly stupidness in my opinion, it have to
be changed.

To my knowledge this has been the way in C for ever. Are you complaining
about C99 not adopting the C++ style in treating a file-scope const
"variable" with a constant initializer as a constant [compile-time]
expression? Or are you suggesting that C90 handles this any better and
that C99 is actually a regression in this department?

In C++ you can actually do this and

const int foo = 10;

is implicitly static (file-scope) due to the top-level constness and foo
can be used as compile-time constant expression. This is by design
because B. Stroustrup doesn't like macros very much, either.

I sort of accepted this difference between C and C++. In C you just have
to #define something like this in order to be able to use it as the size
of a non-VL array. But I would appreciate it if this unnecessary
incompatibility went away...
 
F

fir

W dniu niedziela, 18 listopada 2012 10:41:55 UTC+1 użytkownik SG napisał:
Am 18.11.2012 10:21, schrieb fir:
It is sad to say so but there is some real
and terrible stupidnes in c99. When i wrote
programs in c (and I am involved c user) I
just use const int for array boundaries but
in c99 (and some previous too, terribly) it
will not compile (see for example
thing for ppl who just wants to use const int to this
purposes and not to use preprocesor - as I do.
It is terribly stupidness in my opinion, it have to
be changed.



To my knowledge this has been the way in C for ever. Are you complaining

about C99 not adopting the C++ style in treating a file-scope const

"variable" with a constant initializer as a constant [compile-time]

expression? Or are you suggesting that C90 handles this any better and

that C99 is actually a regression in this department?



In C++ you can actually do this and



const int foo = 10;



is implicitly static (file-scope) due to the top-level constness and foo

can be used as compile-time constant expression. This is by design

because B. Stroustrup doesn't like macros very much, either.



I sort of accepted this difference between C and C++. In C you just have

to #define something like this in order to be able to use it as the size

of a non-VL array. But I would appreciate it if this unnecessary

incompatibility went away...

yes, i know; i dislike #define and must to switch to c++ compatybility modeto compile
my besides that pure c codes

it is terrible, it should just change becouse
in other way though I am c (not c++) coder I must throw c compilers to trashbin - becouse
I dislike macros and do not use no one of them

c should just accept

const int table_max = 1000;
int table[table_max};

I do not know where this no 'const int array boundaries' dirty shit originates
but it seem to me that in older c there it was possible to use const ints as array boundaries, (not sure to this, usualy switched to c++ mode to resolve other old c troubles with int i before for loop and so :/ )

make c const int usable in c, call the comitee or compiler writers to include some switch :/
 
S

SG

Am 18.11.2012 11:02, schrieb fir:
W dniu niedziela, 18 listopada 2012 10:41:55 UTC+1 użytkownik SG napisał:
Am 18.11.2012 10:21, schrieb fir:
[snip]
To my knowledge this has been the way in C for ever.
[snip]
of a non-VL array. But I would appreciate it if this unnecessary
incompatibility went away...

yes, i know; i dislike #define and must to switch to c++ compatybility mode to compile
my besides that pure c codes
[snip]

c should just accept

const int table_max = 1000;
int table[table_max};

I do not know where this no 'const int array boundaries' dirty shit originates
but it seem to me that in older c there it was possible to use const ints as array boundaries, (not sure to this, usualy switched to c++ mode to resolve other old c troubles with int i before for loop and so :/ )

I don't think you're right. "older C" wasn't "better" in that respect.
 
N

Nick Keighley

It is sad to say so but there is some real
and terrible stupidnes in c99. When i wrote
programs in c (and I am involved c user) I
just use const int for array boundaries

no you didn't
but
in c99 (and some previous too, terribly)

all previous
it
will not compile (see for examplehttp://stackoverflow.com/questions/1712592/variably-modified-array-at... ) It is terribly wrong
thing for ppl who just wants to use const int to this
purposes and not to use preprocesor - as I do.
It is terribly stupidness in my opinion, it have to
be changed.

:)

C changes pretty slowly so don't hold your breath
 
B

Ben Bacarisse

fir said:
I do not know where this no 'const int array boundaries' dirty shit
originates but it seem to me that in older c there it was possible to
use const ints as array boundaries, (not sure to this, usualy switched
to c++ mode to resolve other old c troubles with int i before for loop
and so :/ )

It seems you've been writing C++ for some years now, so why not just be
a happy C++ programmer rather than an unhappy C one?
 
F

fir

W dniu niedziela, 18 listopada 2012 13:16:48 UTC+1 użytkownik Ben Bacarisse napisał:
It seems you've been writing C++ for some years now, so why not just be

a happy C++ programmer rather than an unhappy C one?

becouse i dislike all c++ features (and soul), and deply appreciate most ofc features (and its spirit), this

const int table_max = 100;
int table[table_max];

i consider as it should belong to c language also It should be, it is terrible that it fails here, (indeed i write in c but i change
to c++ becouse of some old c slight quirks
and was unaware that this terrible const int
boundary distaster is present here
 
B

Ben Bacarisse

You might want to look into using either the older Google groups
interface or a stand-alone news reader. The new Google groups seems to
mess up posts that go to Usenet very badly. (You might also consider
using your shift key.)
W dniu niedziela, 18 listopada 2012 13:16:48 UTC+1 użytkownik Ben Bacarisse napisał:

becouse i dislike all c++ features (and soul), and deply appreciate
most of c features (and its spirit),

You obviously don't dislike all C++ features since you want C to adopt
one of them!
this
const int table_max = 100;
int table[table_max];

You don't *have* to use a macro. You can use an enum constant instead:

enum { table_max = 100 };
int table[table_max];
i consider as it should belong to c language also It should be, it is
terrible that it fails here, (indeed i write in c but i change to c++
becouse of some old c slight quirks and was unaware that this terrible
const int boundary distaster is present here

You have only two realistic options: keep using C++, or switch back to C
and use a macro or an enum. There is no hope at all that the C
committee will change the meaning of const any time soon. It's likely
to be 10 years before the next major revision of the language and even
then I don't think it's likely. If you want to try, posting here is
going to be of little use. You'll need a proposal and, probably,
backing from your national standards body.

BTW, I agree with you in theory: C should have used C++'s meaning of
const from the start, but back in the late 80s no one new that C++ would
become what it has, and C compilers were already using the more
restricted notion that became standard.
 
F

fir

W dniu niedziela, 18 listopada 2012 15:24:34 UTC+1 użytkownik Ben Bacarisse napisał:
You might want to look into using either the older Google groups

interface or a stand-alone news reader. The new Google groups seems to

mess up posts that go to Usenet very badly. (You might also consider

using your shift key.)


W dniu niedziela, 18 listopada 2012 13:16:48 UTC+1 użytkownik Ben Bacarisse napisał:

becouse i dislike all c++ features (and soul), and deply appreciate
most of c features (and its spirit),



You obviously don't dislike all C++ features since you want C to adopt

one of them!


const int table_max = 100;
int table[table_max];



You don't *have* to use a macro. You can use an enum constant instead:



enum { table_max = 100 };

int table[table_max];


i consider as it should belong to c language also It should be, it is
terrible that it fails here, (indeed i write in c but i change to c++
becouse of some old c slight quirks and was unaware that this terrible
const int boundary distaster is present here



You have only two realistic options: keep using C++, or switch back to C

and use a macro or an enum. There is no hope at all that the C

committee will change the meaning of const any time soon. It's likely

to be 10 years before the next major revision of the language and even

then I don't think it's likely. If you want to try, posting here is

going to be of little use. You'll need a proposal and, probably,

backing from your national standards body.



BTW, I agree with you in theory: C should have used C++'s meaning of

const from the start, but back in the late 80s no one new that C++ would

become what it has, and C compilers were already using the more

restricted notion that became standard.

I could try to talk with some ppl in this comitee if i would konow how to do it, couse
I am curious what they would say to me

(though have neber tried this yet)

I am far involved in area of c language
improvements, as I said few weeks ago,
and I am working on my own compiler and
language (which I consider is still c )

so one options is to write my own
compiler (can do, and will do that)

other option is also to say to some
compiler makers to make some switch which
would accept const ints as array boundaries
(though they probably would say that i can
use c-like subset of c++ as I am doing
now (it is ok though i would feel bad if
it would be named as writing in c++, I am
absolutely c spitit not c++ programmer
 
F

fir

language (which I consider is still c )

or, at least, I would like it to be still c
(this may need some smewhat difficult care
maybe to feel what c is, especially on improved
area :-()
 
J

James Kuyper

It is sad to say so but there is some real
and terrible stupidnes in c99. When i wrote
programs in c (and I am involved c user) I
just use const int for array boundaries but
in c99 (and some previous too, terribly) it
will not compile (see for example
http://stackoverflow.com/questions/1712592/variably-modified-array-at-file-scope ) It is terribly wrong
thing for ppl who just wants to use const int to this
purposes and not to use preprocesor - as I do.
It is terribly stupidness in my opinion, it have to
be changed.

In C++, a const object initialized with a constant expression can itself
be used as a constant expression, but in C, this is not the case, and it
has never been the case. You're wrong when you claim to have previously
written C programs where such code worked. Perhaps you actually compiled
them as C++?

I like this feature of C++, and favor it's adoption in C. It would not
break any strictly conforming code, and would allows better type safety
than is provided by the C alternatives. However, describing this as a
stupid feature of C ignores the fact that C does provide perfectly
workable alternatives, such
#define CONSTANT 4
or
enum {CONSTANT=4};

Constant expressions are required in the following cases (and possibly
others that I missed):
_Alignas(CONSTANT)/*C2011*/ static struct {
unsigned bit_field:CONSTANT
} array[CONSTANT] = {
[CONSTANT/2].bit_field /*C99*/ = CONSTANT
};
enum {OTHER=CONSTANT};
case CONSTANT:
#if CONSTANT
#elif CONSTANT
_Static_assert(CONSTANT, "CONSTANT is 0"); /*C2011*/

C99 didn't make this issue any worse - in fact, C99 no longer required
the use of constant expressions for array dimensions unless the array
was defined with static storage duration (as was the case in your code)
(in C2011, constants are also required for the dimensions of arrays with
thread storage duration). When you don't use a constant expression, the
result is a Variable Length Array, as was mentioned in the title of your
stackoverflow question.

As a result, if you need to have global access to the array (which
suggests that your program is poorly designed), there is another
alternative in C99 or later:

types.h:
static const int NUM_TYPES = 4;
extern int *types;

main.c:
#include <types.h>
int *types;
int main(void)
{
int type_list[NUM_TYPES] = {
1,
2,
3,
4 };
types = type_list;
// The rest of your program.
}

Is there any reason why none of the C alternatives described above would
be acceptable for use in your program?
 
J

James Kuyper

or, at least, I would like it to be still c
(this may need some smewhat difficult care
maybe to feel what c is, especially on improved
area :-()

You compiler could qualify as C, so long as every feature that it
supports which deviates from the requirements specified by the standard
can either be disabled by a compiler option, or requires the use of a
#pragma or a C feature with undefined behavior to enable it. If your
extension always involves something that constitutes a syntax error or a
constraint violation in C, your compiler can fully conform to the
standard simply by issuing a diagnostic message (such as "Warning: this
program relies upon our file scope VLA extension to standard C")
whenever the program uses the feature.

However, you'll need to know precisely what the C standard requires, in
order to meet those requirements. Since this issue surprised you, and
particularly since you mis-identified it as something new in C99, I
suspect that you have a lot to learn before you'll be able to build a
standard-conforming implementation of C.
 
F

fir

this question on stack overflow was not mine, just found it ocasionally
Is there any reason why none of the C alternatives described above would
be acceptable for use in your program?

#define is not acceptable by me I dislike
using preprocessor and use only few includes
(do not like it either) and nothing more of it

enum would be eventually hardly acceptable
but its just bad (from my aestehetic point of
view), nothing else to say :<
 
F

fir

W dniu niedziela, 18 listopada 2012 18:22:47 UTC+1 użytkownik Kenneth Brody napisał:
W dniu niedziela, 18 listopada 2012 13:16:48 UTC+1 użytkownik Ben Bacarisse napisał:
[...]
It seems you've been writing C++ for some years now, so why not just be
a happy C++ programmer rather than an unhappy C one?
becouse i dislike all c++ features (and soul), and deply appreciate most of c features (and its spirit), this
const int table_max = 100;
int table[table_max];
i consider as it should belong to c language also It should be, it is terrible that it fails here, (indeed i write in c but i change
to c++ becouse of some old c slight quirks
and was unaware that this terrible const int
boundary distaster is present here



I find it highly unlikely that this fart of the language will change,

considering the fact that you can have:



===== file1.c



const int table_max = 100;



===== file2.c



extern const int table_max;



.... references to "table_max" that cannot be a compile-time constant ...

here, it should be just some requirement that
array boundary const int must be defined in the
same module as aray itself (end compile error
if not) it is not general problem with const int here
 
B

Ben Pfaff

fir said:
It is sad to say so but there is some real
and terrible stupidnes in c99. When i wrote
programs in c (and I am involved c user) I
just use const int for array boundaries but
in c99 (and some previous too, terribly) it
will not compile (see for example
http://stackoverflow.com/questions/1712592/variably-modified-array-at-file-scope ) It is terribly wrong
thing for ppl who just wants to use const int to this
purposes and not to use preprocesor - as I do.
It is terribly stupidness in my opinion, it have to
be changed.

Just use an enum.

enum { LIMIT = 10 };
int myarray[LIMIT];
 
E

Eric Sosman

this question on stack overflow was not mine, just found it ocasionally


#define is not acceptable by me I dislike
using preprocessor and use only few includes
(do not like it either) and nothing more of it

enum would be eventually hardly acceptable
but its just bad (from my aestehetic point of
view), nothing else to say :<

In short, "stupidity" is "whatever offends fir's delicate
aesthetic sensibilities."

Are you related to Reginald Bunthorne?
 
B

BartC

Kenneth Brody said:
On 11/18/2012 8:27 AM, fir wrote:
const int table_max = 100;
int table[table_max];
I find it highly unlikely that this fart of the language will change,
considering the fact that you can have:

===== file1.c

const int table_max = 100;

===== file2.c

extern const int table_max;

.... references to "table_max" that cannot be a compile-time constant ...

Why not? I can do this in another language (albeit using true named
constants, rather than read-only variables, although the latter can be
possible in the same way).

In any case, the language ought to provide true named constants, which are
pretty fundamental, not expect everyone to mess around with enums, defines,
and const attributes. Then the above won't be a problem.
 
F

fir

W dniu niedziela, 18 listopada 2012 21:10:33 UTC+1 użytkownik Eric Sosman napisał:
In short, "stupidity" is "whatever offends fir's delicate

aesthetic sensibilities."

When I wrote some messages on this group
(not many times that was my third visit here)
really I often met a ppl which I see try to make 'much effort to not understand me'
(Really, I see suc thing here)

It would be hard to explain such basic
things why

coinst int table_max = 4096;

is better than

enum { table_max = 4096 }

(this reason is not purely aesthetic but i
meant that giving up with const ints here
and go intu enums would be terrible aesthetic
failure for me) Seem terribly obvious for me,
and not seeing it end using enums here seem
to be very stupid for me

defines are not such stupid but preprocesor
can be consideren not as part of c but some
external tool to use over it (it was initialy
considered like that, check out c history note)
and i also treat it such way (as external tool
over c, with not to much use for me personally)

it is not to much speak here, just simple
thing - imo the question is how to made this
change in c language (If I would be C 'director' (I should be*) I would just
change that

* becouse I am really well prepared for this things :>
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,754
Messages
2,569,521
Members
44,995
Latest member
PinupduzSap

Latest Threads

Top