jacob navia <jacob@[EMAIL PROTECTED]
> writes:
> Ben Bacarisse wrote:
>> jacob navia <jacob@[EMAIL PROTECTED]
> writes:
>>
>>> Keith Thompson wrote:
>>> [snip]
>>>
>>>> What could be done, I suppose, is to add an entirely new array-like
>>>> construct to C, one that doesn't depend on pointer semantics for its
>>>> fundamental operations or decay to a pointer in most contexts. Let's
>>>> call it a "vector".
>>> Correct. This is the way that lcc-win has choosen. Using
>>> operator overloading of the '[' and ']' operators lcc-win
>>> offers a true array type that doesn't "decay" to anything.
>>
>> Way off-topic now so I've set followup-to comp.compilers.lcc, but I
>> can't see how that can do anything. In this code:
>>
>> int a[10];
>> f(a);
>>
>> there are no [] operators, so how does the compiler know which sort of
>> array I want?
>>
>
> Because you tell it to:
>
> int a[10]; // Normal C array
> Vector v = newVector(10,sizeof(int));
>
> a[2] = 5;
> v[2] = 5;
I added #include <vector.h> and wrapped it in a main function, but
this does not compile. Are vectors a work in progress?
At any rate, as far as I can see you agree with me. You don't do it
as you seemed to be suggesting with an array that does not decay to a
pointer. You just use a new type -- most likely some sort of struct
type.
>> <snip>
>>> ... Operator overloading provides a simple and elegant solution as
>>> I have been claiming since several years now.
>>
>> I think treating initialisation as assignment and, if I recall
>> correctly, *not* treating argument passing as assignment makes your
>> operator overloading much less useful than it might have been.
>>
>
> All argument passing are assignments in standard C.
Yes I know. I was curious as to why they seem to be excluded, since
they are, in effect assignments. In other words, having defined
assignment for type T from type X, I'd expect to see it used when
passing an X to function taking a T.
However, I now discover that for some reason one can't define
assignment between two type T objects. That seems to exclude lots of
useful implementations like reference counting and copy on write. Are
the precise semantics of operator overloading and with is and is not
permitted written down anywhere?
> But if you want C++, no, it is not C++.
Eh? I'd like it to be consistent. Are you saying that the only way
to do overloading in C properly is to move all the way to C++?
--
Ben.
|
