Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > some well known stupidness in c99

Reply
Thread Tools

some well known stupidness in c99

 
 
James Kuyper
Guest
Posts: n/a
 
      11-19-2012
On 11/19/2012 06:35 AM, BartC wrote:
> "fir" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>
>> c lacks an lengthof() operator, it could be
>> done easily and also use efficiently (more
>> efficient than size passing)

>
> You mean like this:
>
> #define lengthof(x) (sizeof(x)/sizeof(x[0]))
>
> In C it's all done with macros.
>
> Oh I forgot, you don't like macros...


I'm reasonably sure he's interested in an operator that could be applied
to a pointer (not an array) to give the length of the array it points
at. This is quite feasible, but would require pointers to carry more
information than is currently required. You'd also have to add a feature
to the language to create a pointer to only part of an array; lengthof()
would then give the length of the desired part of the array, rather than
the entire array.

The key problem is that mandating support for such a feature would
require that ALL pointers carry this information. The collection and
transmission of that extra information could be optimized away in some
circumstances, but not in the general case. With pointers being such a
fundamental feature of C, that would significantly degrade the
performance of all programs, even the ones that don't make any use of
lengthof(). One of the key design principles for the C language is that
you shouldn't have to pay for the costs of features that your code
doesn't use.
--
James Kuyper
 
Reply With Quote
 
 
 
 
fir
Guest
Posts: n/a
 
      11-19-2012
W dniu poniedziałek, 19 listopada 2012 14:21:40 UTC+1 użytkownik James Kuyper napisał:
> On 11/19/2012 06:35 AM, BartC wrote:
>
> > "fir" <(E-Mail Removed)> wrote in message

>
> > news:(E-Mail Removed)...

>
> >

>
> >> c lacks an lengthof() operator, it could be
> >> done easily and also use efficiently (more
> >> efficient than size passing)

> >
> > You mean like this:
> >
> > #define lengthof(x) (sizeof(x)/sizeof(x[0]))
> >
> > In C it's all done with macros.
> >
> > Oh I forgot, you don't like macros...

>
>
> I'm reasonably sure he's interested in an operator that could be applied
>


damn, youre right here, I mislooked one thing
here (must rethink that and modify, the other
parts of my reasoning was good)

> to a pointer (not an array) to give the length of the array it points
> at. This is quite feasible, but would require pointers to carry more
> information than is currently required. You'd also have to add a feature
> to the language to create a pointer to only part of an array; lengthof()
> would then give the length of the desired part of the array, rather than
> the entire array.
>
>
>
> The key problem is that mandating support for such a feature would
> require that ALL pointers carry this information. The collection and
> transmission of that extra information could be optimized away in some
> circumstances, but not in the general case. With pointers being such a
> fundamental feature of C, that would significantly degrade the
> performance of all programs, even the ones that don't make any use of
> lengthof(). One of the key design principles for the C language is that
> you shouldn't have to pay for the costs of features that your code
> doesn't use.
>


sure, I do agree with that :/
 
Reply With Quote
 
 
 
 
James Kuyper
Guest
Posts: n/a
 
      11-19-2012
On 11/19/2012 08:21 AM, James Kuyper wrote:
> On 11/19/2012 06:35 AM, BartC wrote:

....
>> #define lengthof(x) (sizeof(x)/sizeof(x[0]))
>>
>> In C it's all done with macros.

....
> I'm reasonably sure he's interested in an operator that could be applied
> to a pointer (not an array) to give the length of the array it points
> at.


Correction: if pointer did point at an array:

int (*parray)[15];

lengthof(*parray) would gives 15, the desired value. That's not the
problematic case. It's pointers that point at the first element of an
array (such as "Hello world!") that lengthof() doesn't handle in the
desired fashion.
--
James Kuyper
 
Reply With Quote
 
fir
Guest
Posts: n/a
 
      11-19-2012
> sure, I do agree with that :/

(thoug i disagree if you say that every
pointer used then would have to contain
additional lengthof information, It would
be necessary only for arrays (pointers to
many)
It can be distinguished by definietion

foo(Type1 p1[], Type2* p2)
{
// here pi could be fat pointer
// p2 normal thin pointer
}

this distinguish could be good for c
language (even without usage of fat pointers
just static control - some control over
over dereferencing pointers-to-one could
be much usefull) - but this is side thing

as to array pointers there fat pointers had appeared again :/ I do not like tem to much
- must rethink it over again
 
Reply With Quote
 
BartC
Guest
Posts: n/a
 
      11-19-2012
"James Kuyper" <(E-Mail Removed)> wrote in message
news:k8dbp3$brj$(E-Mail Removed)...
> On 11/19/2012 06:35 AM, BartC wrote:
>> "fir" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>>
>>> c lacks an lengthof() operator, it could be


>> #define lengthof(x) (sizeof(x)/sizeof(x[0]))


> I'm reasonably sure he's interested in an operator that could be applied
> to a pointer (not an array) to give the length of the array it points
> at. This is quite feasible, but would require pointers to carry more
> information than is currently required. You'd also have to add a feature
> to the language to create a pointer to only part of an array; lengthof()
> would then give the length of the desired part of the array, rather than
> the entire array.
>
> The key problem is that mandating support for such a feature would
> require that ALL pointers carry this information.


I think we discussed this before. My suggestion would be to have two kinds
of pointers: what we have now, and 'fat' pointers consisting of a pointer,
and a length (what I called 'slices').

This fat pointer need do nothing more than formalise what is done now, when
a pointer+length is passed, or a struct containing a pointer and length is
created, and that is passed.

But being part of the language, the (pointer,length) type can be used with
any target type, while you'd need to define a new struct for each target, or
use lots of untidy casts.

(I partly lost interest in implementing such a type for my own projects, for
this level of language. You reserve those goodies for the next level where
you can do it properly! For example, the logical next step is to have a
flexible array type (where the size can vary, usually upwards). But for that
purpose, a (pointer,length) type isn't enough.)

> With pointers being such a
> fundamental feature of C, that would significantly degrade the
> performance of all programs, even the ones that don't make any use of
> lengthof().


No, you'd leave ordinary pointers alone. They're used in such a variety of
ways anyway, that a length attribute would often be meaningless. (For
example when they point to an individual value; it may or may not be part of
a homogeneous set, but you don't care if it is.)

--
Bartc

 
Reply With Quote
 
BartC
Guest
Posts: n/a
 
      11-19-2012


"James Kuyper" <(E-Mail Removed)> wrote in message
news:k8decd$sdq$(E-Mail Removed)...
> On 11/19/2012 08:21 AM, James Kuyper wrote:
>> On 11/19/2012 06:35 AM, BartC wrote:

> ...
>>> #define lengthof(x) (sizeof(x)/sizeof(x[0]))
>>>
>>> In C it's all done with macros.

> ...
>> I'm reasonably sure he's interested in an operator that could be applied
>> to a pointer (not an array) to give the length of the array it points
>> at.

>
> Correction: if pointer did point at an array:
>
> int (*parray)[15];
>
> lengthof(*parray) would gives 15, the desired value. That's not the
> problematic case. It's pointers that point at the first element of an
> array (such as "Hello world!") that lengthof() doesn't handle in the
> desired fashion.


That's another problem, distinguishing between a char array itself, and the
zero-terminated string it might contain. Perhaps it's better to assume a
char array, and use strlen() for strings, where you know there will be extra
overhead.

(However. once a string length *has* been calculated, you can then construct
a (pointer,length) type, and now you have counted strings! As well as string
slices, pointing to a substring in the middle of a string, etc.)

--
Bartc

 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      11-19-2012
On 11/19/2012 09:06 AM, fir wrote:
>> sure, I do agree with that :/

>
> (thoug i disagree if you say that every
> pointer used then would have to contain
> additional lengthof information, It would
> be necessary only for arrays (pointers to
> many)


The C standard treats pointers to single objects as if they were
pointers to the first element of a 1-element array. This concept is
built into C pointer arithmetic.

> It can be distinguished by definietion
>
> foo(Type1 p1[], Type2* p2)


While I routinely make that distinction in my own code, it's just a
coding convention; as far as C itself is concerned, there's no
distinction between p1 and p2, and a lot of existing code relies upon
the fact that this is the case - one form is used in the function
declaration, a different form is used in the function definition, but
since C says that they are equivalent, that's perfectly acceptable.
Existing code will break if the two declarations indicate different
argument passing mechanisms.
One of the C committee's guiding principles is to avoid changes that
would break existing code.
--
James Kuyper
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      11-19-2012
On 11/18/2012 7:04 PM, BartC wrote:
> "Eric Sosman" <(E-Mail Removed)> wrote in message
> news:k8bpeq$h0m$(E-Mail Removed)...
>> On 11/18/2012 5:45 PM, BartC wrote:
>>> "James Kuyper" <(E-Mail Removed)> wrote in message

>
>>>> Because, at compile time for file2.c, file1.c is not visible, and the

>
>>> Well, OK, in the language I had in mind
>>> ... it would look like this:
>>> [...]

>>
>> You've missed James' point. Try this example:
>>
>> /* file1.c */
>> const int table_max = 100;
>>
>> /* file2.c */
>> const int table_max = 200;
>>
>> /* victim.c */
>> extern const int table_max;
>> int table[table_max];
>>
>> From these three files I want to make two programs: One
>> that links file1.o+victim.o, the other using file2.o+victim.o.
>> Explain how table_max is a compile-time constant in victim.

>
> We're talking about compile-time constants, not link-time ones.
>
> Also about something that C might be made to do, not as it is now.
> However I'm assuming that this new C would need still the dimension of
> table[] - table_max - to be known to the compiler.
>
> So when victim is compiled, it will use the current value of table_max
> in whichever file1 or file2 has been chosen. To create two programs with
> two different values of table_max, requires recompilation of victim in
> each case.


... which was James' point: "Any language that allows you
to do this does not support true separate compilation." If I
must recompile victim.c for each potential partner fileX.c, there
is no more separate compilation.

>> Also, I just wrote file1.c and file2.c today, but I wrote
>> and compiled victim.c->victim.o a month ago. Again, explain
>> how table_max was a compile-time constant a month before I
>> decided on any of the values it might someday have.

>
> Yes, there are still build dependencies, the same as there might be now
> when you use header files:
>
> you compiled victim.c a month ago, using a header file1.h containing
> some particular function prototype which is contained in file1.c. Today
> you modify the function in file1.c so that the prototype needs to
> change. victim.c needs to be recompiled if you want to link it with a
> file1 object file created today.


An #include'd file or header is part of the "translation unit,"
and it makes sense to require re-translation when any part of the
translation unit changes. But what you're suggesting requires
re-compilation of a translation unit that has *not* changed, because
of something that's happened in some other translation unit.

--
Eric Sosman
http://www.velocityreviews.com/forums/(E-Mail Removed)d
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      11-19-2012
On 11/19/2012 9:25 AM, BartC wrote:
>
>
> "James Kuyper" <(E-Mail Removed)> wrote in message
> news:k8decd$sdq$(E-Mail Removed)...
>> On 11/19/2012 08:21 AM, James Kuyper wrote:
>>> On 11/19/2012 06:35 AM, BartC wrote:

>> ...
>>>> #define lengthof(x) (sizeof(x)/sizeof(x[0]))
>>>>
>>>> In C it's all done with macros.

>> ...
>>> I'm reasonably sure he's interested in an operator that could be applied
>>> to a pointer (not an array) to give the length of the array it points
>>> at.

>>
>> Correction: if pointer did point at an array:
>>
>> int (*parray)[15];
>>
>> lengthof(*parray) would gives 15, the desired value. That's not the
>> problematic case. It's pointers that point at the first element of an
>> array (such as "Hello world!") that lengthof() doesn't handle in the
>> desired fashion.

>
> That's another problem, distinguishing between a char array itself, and
> the zero-terminated string it might contain. Perhaps it's better to
> assume a char array, and use strlen() for strings, where you know there
> will be extra overhead.
>
> (However. once a string length *has* been calculated, you can then
> construct a (pointer,length) type, and now you have counted strings! As
> well as string slices, pointing to a substring in the middle of a
> string, etc.)


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.

(Digression

Everybody's always coming up with ideas about things that could
be added to C, and making a case for their usefulness. In C99 we
saw the fruit of invention: Lots of new and useful features were
added, and what happened? Adoption was dismally slow, and now in
C11 we've got __STDC_NO_VLA__ and __STDC_NO_COMPLEX__ and six more
"conditional feature" macros: one hundred ninety-two[*] distinct
languages, all legitimately called "C." This is exactly the kind
of fragmentation ANSI C set out to minimize, and I think we can
trace its explosive resurgence to feature creep. Let's at least
make it no worse, okay?
[*] Not 256, because two of the macros are interdependent.

--
Eric Sosman
(E-Mail Removed)d
 
Reply With Quote
 
fir
Guest
Posts: n/a
 
      11-19-2012
> just static control - some control over
> over dereferencing pointers-to-one could
> be much usefull) - but this is side thing
>


at least (when my attempt to had a lenghtof()
without fat pointers somewhat fails by now here)
i could done one important remark to my
own self (which i not noticed before):

c language can (and probably should) guard
the type safety between pointers-to-one and
pointers-to-many, it would straighten (type)
safety and wold also improve the expresiveness
of the code :/



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Is this phase-accumulator trick well-known??? Mike Treseler VHDL 0 02-08-2009 07:17 PM
List mutation method gotcha - How well known? Hendrik van Rooyen Python 20 03-16-2008 09:55 AM
Difference between "library parts" of C99 and "language parts" of C99 albert.neu@gmail.com C Programming 3 03-31-2007 08:14 PM
C99 struct initialization (C99/gcc) jilerner@yahoo.com C Programming 3 02-20-2006 04:41 AM
well-known Internet sites which use Java based web servers Mladen Adamovic Java 3 10-24-2005 09:48 PM



Advertisments