some well known stupidness in c99

[fir]

the question is how syntax to choose to distinguish between pointers-to-one and pointers-to-many in such cases:

void print(char* text) //pointer to undefined many
{

}

void print(char(1)* text) //pointer to one ?
{

}

also think sometimes (like here) if java-like
syntax wouldnt be clearer

char a; //a is adress to one
char[] a; //a is adress to undefined many
char[16] a; //a is adress to chunk of 16 chars

it seem clearer and *a could be reserved
eventually for old way

 

[fir]

I guess that English is not your first language, so perhaps you're
not aware that the word "stupid" is quite insulting. I suggest

I do like c in very much extent so it sound
totaly fantastic (not real( to me, I use
called it stupidness becouse I was/am real
angry/mad to know that I cannot use const int
in c99 and finding also explanation sort of 'consyt int x doeas not mean that x is const'
(and the fact that i can throw c compilers to trashbin)
I feel i can call it stupidnees though some
explanations what do I mean would be required
- I said what do I meant

 

[fir]

so (maybe I add it) i called it stupidness
in some way especially for its 'unpleasaant'
annoying consequences, though not giving better alternative to defines and enums also
is not to much wise for me but do not matter
(i do not want to hold on this word here to
much, maybe I shouldnt use it and use something
like 'bad thing' or 'annoying thing'

there should be also argumentation why define
is considered bad for me but i never reflected
on it too much, all preprocesor seem to me
like to much primitive rules tool and it is not so much bad as an external tool over c
but is bad for me if considered as an inavoidable part of c - (and enum way is silly ) - so it is like here it is :/

 

[fir]

void print(char text[])

{
for(int i=0; i<lengthof(text); i++)
put_char_on_console(text);
}

(soory for may maneer of writing under my own
posts, but I often feel a need to add more, and
there is no edit option so I use it this way)

eventually sizeof could be even considered
if

int a[100];

sizeof(a) // gives 400 bytes of size
sizeof(a[0]) // gives 4 bytes of size

sizeof(a[]) //could return 100 elements of size

(i am not saying that it is the better option
but it can be considered)

Those all ways considered are my own interest
couse I am working on some logical improvements to c language (codenamed also sometimes c2 language)

 

[BartC]

also think sometimes (like here) if java-like
syntax wouldnt be clearer

char a; //a is adress to one
char[] a; //a is adress to undefined many
char[16] a; //a is adress to chunk of 16 chars

it seem clearer and *a could be reserved
eventually for old way

In my opinion, C type syntax is broken. And that's not just the convoluted
syntax.

It's because char[] means different things in different contexts: an array
in some places, and a pointer in another:

char a[]={65,66,67}; // array

void fn (char[] a); // pointer

char[] meaning array would be illegal in a parameter context, but instead of
leaving that hole in the 'map' of possible types, everything moves up one
instead! The penchant for C to gloss over any dereferences needed - or not
needed - to index an array/pointer, just confuses things further.

I think you have your work cut out...

 

[fir]

W dniu wtorek, 20 listopada 2012 11:54:10 UTC+1 użytkownik Bart napisał:

the question is how syntax to choose to distinguish between
pointers-to-one and pointers-to-many in such cases:
void print(char* text) //pointer to undefined many
{
}
void print(char(1)* text) //pointer to one ?
{
}

also think sometimes (like here) if java-like
syntax wouldnt be clearer

char a; //a is adress to one
char[] a; //a is adress to undefined many
char[16] a; //a is adress to chunk of 16 chars

it seem clearer and *a could be reserved
eventually for old way

In my opinion, C type syntax is broken. And that's not just the convoluted
syntax.

It's because char[] means different things in different contexts: an array
in some places, and a pointer in another:



char a[]={65,66,67}; // array

void fn (char[] a); // pointer



char[] meaning array would be illegal in a parameter context, but insteadof
leaving that hole in the 'map' of possible types, everything moves up one
instead! The penchant for C to gloss over any dereferences needed - or not
needed - to index an array/pointer, just confuses things further.


I think you have your work cut out...

I do not understand 'cut out' phrase, but
I am thinking over applying logical
improvements for about and almost 10 years
till now and some good and logical ideas
(ways of improvements) arose

here this proposal seem also logical and
good one finally here (though some think
up over it is always good thing):

this could be considered as adding some
support for arrays in c, it would be this
way (as I repeat):

some length of operator should work
on arrays - in many cases it should work
in static (compiler) time, on some cases
then should use dynamic length info provided
in function call

arrays passing should offer some new way
of it

void foo(int some)
{
ShowBox( lengthof (some) );

//should give one - this is from compilet time static type analisis (givesone for all no arrays)
}

void foo(int[16] some)
{
ShowBox( lengthof (some) );

// should give 16 - compiler time info
}

void foo(int[] table)
{
ShowBox( lengthof (some) );

// this should give result based on number passed on stack (which then goes probably from static compiler info knowledge)
}


old pointer ways,

void foo(int* some)

void foo(int (*some)[16])

should probably be working to in old way,
thought probably pointer-to-one pointer-to-many type guarding should be used here too
(to skip off by casting if need probably)

this is logical and would work, some
syntaxic question as to use "int[] a" or
"int a[]" or lengthof(a) or lenghtof(a[]) or sizeof(a[]) would be for otherdetailed consideration maybe, but this would support
arrays reasonably nicely

 

[fir]

W dniu wtorek, 20 listopada 2012 11:54:10 UTC+1 użytkownik Bart napisał:

char a; //a is adress to one
char[] a; //a is adress to undefined many
char[16] a; //a is adress to chunk of 16 chars

It's because char[] means different things in different contexts: an array
in some places, and a pointer in another:

char a[]={65,66,67}; // array

void fn (char[] a); // pointer

this maybe is not so much bad that

int a[10]; //definietion

a[10]; //11th element

so this

int[10] a; //definietion
a[10]; //11th element

seem to be more logical, and also "int[10]" as
a type name seem to nicer

 

[fir]

W dniu wtorek, 20 listopada 2012 13:38:50 UTC+1 użytkownik pete napisał:

It is common for people to think

that something else is stupid,

because they can't understand it.

I meet often such ppl that call me stupid
(a horde of them) so I know it well - but here still this lack of other better than preprocesor and enum way seem not much wise
to me

 

[Ben Bacarisse]

int a[10]; //definietion

a[10]; //11th element

so this

int[10] a; //definietion
a[10]; //11th element

seem to be more logical, and also "int[10]" as
a type name seem to nicer

Nicer than what? As it happens, 'int[10]' is the type name
corresponding to the C declaration of 'a' that you wrote.

 

[fir]

W dniu wtorek, 20 listopada 2012 13:52:40 UTC+1 użytkownik Ben Bacarisse napisał:

int a[10]; //definietion
a[10]; //11th element
so this
int[10] a; //definietion

a[10]; //11th element
seem to be more logical, and also "int[10]" as

a type name seem to nicer

Nicer than what? As it happens, 'int[10]' is the type name

corresponding to the C declaration of 'a' that you wrote.

sorry for my weak english (most of my english
comest from RATM lyrics, and many rereadings of Nabokov's Pnin in english)

I mean that this way of array definition seem
to be better (than present)

int t[100]; <- worse

int[100] t; <- better

 

[Eric Sosman]

On 11/19/2012 4:55 PM, BartC wrote: ...

So I can define:

int table[table_max];

instead of:

int* table=malloc(table_max*sizeof(int));

In C99, or in C11 with VLA support, each of these is usable
wherever the other is, and neither is usable where the other is
not.

Wherever? Even at file scope?

Both are illegal at file scope. (Context: `table_max'
is declared `extern const int table_max;'.)

 

[Eric Sosman]

On 11/19/2012 4:55 PM, BartC wrote:

So I can define:

int table[table_max];

instead of:

int* table=malloc(table_max*sizeof(int));

In C99, or in C11 with VLA support, each of these is usable
wherever the other is, and neither is usable where the other is
not. So, what's the big hoo-haw? (By "hoo-haw," I of course
mean "glory.")

You really don't see that an array accessed by an offset in a data segment
might be better than one accessed via a pointer?

Propose a VLA mechanism that involves no pointers, and
maybe I'll see a difference.

Yes, actually I can see the possibility, because it would be bad
practice to
mix named and explicit constants like this (even if the compiler will
anyway
pick up the error).

Wasn't this whole thread started by somebody wishing a
const-qualified variable would act just like a constant
expression? And isn't that the drum you've been beating?
But now we're told "Oh, well, it would be bad practice to
mix-n-match *these* constant expressions with *those* constant
expressions, because some constant expressions are more
constant than others."

Let's hear it for regularizing the language ...

How is the above example different from this:

#include <windows.h>

switch (a) {
case CBN_DBLCLICK: ...
case 1: ...

That might *also* become a duplicate label with next week's version of
windows.h. (Or substitute any header that you haven't written yourself.)

You still don't understand what "separate compilation" is,
do you? I give up.

 

[Eric Sosman]

(snip, I wrote)

What would happen with

char string[100] = "Hello, world";
char *p = strchr(string, ' ');
strcpy(p + 1, "my ragtime gal");

? If the span of `p' covers the thirteen characters of the
original string, should strcpy() fail because it tries to
deposit characters beyond that range? If so, I don't like
it -- and if not, what good is it?

As I said, the whole string. So *p has to include the whole 100
characters of string, six before and 93 after.

Sorry, I misunderstood you. C defines the string as
all the characters up to and including the '\0', and I
thought that's what you meant. It appears you intended what
I termed "the entire array containing the string."

 

[James Kuyper]

On 11/19/2012 4:55 PM, BartC wrote: ...
So I can define:

int table[table_max];

instead of:

int* table=malloc(table_max*sizeof(int));

In C99, or in C11 with VLA support, each of these is usable
wherever the other is, and neither is usable where the other is
not.

Wherever? Even at file scope?

Both are illegal at file scope. (Context: `table_max'
is declared `extern const int table_max;'.)

Sorry, I wasn't paying enough attention. I was thinking of the second
one as shorthand for something functionally quite similar, but
syntactically somewhat different, which is perfectly legal:

int *table;
int main(void)
{
table = malloc(table_max*sizeof *table);
// Rest of program.
}

The closest permitted VLA equivalent that creates a file scope
identifier is very marginally more complicated:

int *table;
int main(void)
{
int local_table[table_max];
table = local_table;
// Rest of program
}

 

[BartC]

On 11/19/2012 6:38 PM, BartC wrote:

Propose a VLA mechanism that involves no pointers, and
maybe I'll see a difference.

It wasn't meant to be a VLA. Being able to import a constant as I suggested
means a file-scope or static array can be an option.

But now we're told "Oh, well, it would be bad practice to
mix-n-match *these* constant expressions with *those* constant
expressions, because some constant expressions are more
constant than others."

No. It's just bad practice.

You still don't understand what "separate compilation" is,
do you? I give up.

Apparently 'separate compilation' can involve hard-coding a constant
imported from a 3rd-party header, which needs to be repeated when that
header is updated.

That, according to you, is completely different from hard-coding a constant
imported from a header (3rd party or otherwise), if that header includes
some automatically gleaned content. (Although for all we know, windows.h is
also partly generated with tools we don't know about, extracting global data
in the manner I've suggested.)

 

[BartC]

W dniu wtorek, 20 listopada 2012 13:52:40 UTC+1 użytkownik Ben Bacarisse
napisał:

Nicer than what? As it happens, 'int[10]' is the type name

I mean that this way of array definition seem
to be better (than present)

int t[100]; <- worse

int[100] t; <- better

Have a look at some other languages. For example the D programming language
(dlang.org), which has tidied up the language quite a bit, and uses your
syntax for arrays. It might give some ideas.

(However I don't think it's gone quite far enough. That array would be
declared, in another language I use, as:

[100]int t

this uses a consistent left-to-right syntax which matches the description of
the type in English.)

 

[Adam Wysocki]

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

Are you related to Reginald Bunthorne?

Unfortunately, you are feeding a well known (in Poland) troll. He keeps
spamming Polish newsgroups (pl.comp.lang.c and pl.comp.programming) with
his brilliant ideas and the sad truth is that he just doesn't understand
C. Worse than that, he doesn't read anything that others are trying to
say and if you try to prove him wrong and criticise his ideas, he will
immediately insult you.

Sorry for him.

AW

 

[Rui Maciel]

I mean that this way of array definition seem
to be better (than present)

int t[100]; <- worse

int[100] t; <- better

The Go programming language supports a similar syntax for array declaration.
It goes something like:

var t [100]int


As a side note, after taking a look at Go, I suspect that it's only a matter
of time until Go takes C's place in the computing world, and the C
programming language finds itself going the way of the dodo (or cobol).


Rui Maciel

 

[BartC]

On 11/19/2012 6:38 PM, BartC wrote:

The difference is that the latter, using compile-time constants, can (and
*must*, AFAIK) be picked up at compile time. In the former, using runtime
"constants", the clash *cannot* be detected until the code is executed, at
which point it's too late. (Though, I suppose, it might theoretically be
able to be caught at link time.)

I think there's been some confusion because:

o Someone (the OP) was using 'const int' for named constants, but complained
it no longer worked

o Someone else (I think you) pointed out an example of 'const int' where the
value could not be known ('extern const int').

o I suggested that this could be made to work, but gave an example using
true named constants as used in another language.

o Others didn't think such an idea could work in C (whether for true
constants or not), and came up with a range of reasons why it wouldn't (eg.
it wouldn't be 'separate compilation', but I've already said what I think of
that).

So on my part, I've been talking mainly about true named constants (such as
you get with enums), while others, perhaps not realising we were also
discussing a hypothetical extension, may have had 'const ints' in mind.

After all that, it still leaves the OP's problem that 'const int' can't
reliably be used for true named constants, and he doesn't like using enum or
#define. Any other solutions I mentioned involve changes to the language,
which apart from everyone knowing will never happen, some people think are
impossible (even though I've implemented them elsewhere and they work well,
and I've also outlined some approaches to making them work in C using
add-ons).

 

[glen herrmannsfeldt]

(snip)

When strchr() finds a character in a string, what "span" should
the returned pointer have? Should its limits cover the whole string,
just the tail from the start of the search, just the part searched,
the entire array containing the string, just the located character,
or what? You have to know what the caller intends to do with the
pointer before you can know what kind of pointer to return.

(snip, I wrote)

Pretty much has to be the whole string.
What would happen with
char string[100] = "Hello, world";
char *p = strchr(string, ' ');
strcpy(p + 1, "my ragtime gal");
? If the span of `p' covers the thirteen characters of the
original string, should strcpy() fail because it tries to
deposit characters beyond that range? If so, I don't like
it -- and if not, what good is it?

As I said, the whole string. So *p has to include the whole 100
characters of string, six before and 93 after.

Sorry, I misunderstood you. C defines the string as
all the characters up to and including the '\0', and I
thought that's what you meant. It appears you intended what
I termed "the entire array containing the string."

Yes, at the time I was more thinking about the six before the ' ',
which pretty much have to be included.

But any bounds information, to be useful, has to go with the variable
(array) and not with the value (string). Consider the "value" of
p and string in the case:

char string[100];
char *p = string+1;
strcpy(p + 1, "my ragtime gal");

In the auto array case, string doesn't have any value that could
be used as a "string" length in your sense of string.

So, at least the left argument to strcpy() has to be allowed
without previously having any value, yet it should still have
bounds information.

-- glen