jacob navia <jacob@[EMAIL PROTECTED]
> writes:
> Ben Bacarisse wrote:
>> jacob navia <jacob@[EMAIL PROTECTED]
> writes:
>>
>>> Ben Bacarisse wrote:
>>>> Maybe I missed the do***ent you mean.
>>>>
>>> http://www.q-software-solutions.de/~jacob/
>>> There you will find a link to the specifications.
>>
>> Ah, yes. That says a little more but not really enough. For example
>> I don't see anything about not allowing
>>
>> T &operator=(T&, T&);
>>
>
> The prolem with that construct is that it has a well defined meaning in
> C. The code
> T a,b;
> a=b;
> means there is a bitwise copy from b to a. If we would allow the
> overloading of the assignment operator, then the lecture of the code
> would be more complicated as it is now.
>
> One way out could be to allow:
> a += b;
> to have the meaning YOU want, and leave a=b; alone. Would that be
> acceptable to you?
I am not asking because I want any particular semantics. You are
free to choose the meanings you think are right. My comment was that
the specification (or what you thought of as a specification) did not
say anything about this case (unless I missed it). It is not a
specification and will not be taken seriously unless all legal cases
are given meanings and all illegal cases are de***ented.
>> lcc-win32 seems to reject
>>
>> T &operator=(T&, T*);
>>
>> but that is not explained. Is that a problem with the compiler or the
>> specification?
>>
>
> Normally, references are read only. They can't be changed except
> at initialization (or first assignment). Why would you like to allow
> that? What would be the use of that code?
I don't want anything form you, please. The specification does not
say if the above is allowed. It is not a specification unless it
does.
>> How many times is operator= called in these cases:
>>
>> T &operator=(T& x, int i) { ... }
>>
>> T a1[5] = {1,2};
>
> I see above only one assignment. But that assignment is not conforming
> to the specification of the overloaded operator. We could issue a
> "Too many initializers" error message, or call it twice and keep the
> last result. It depends on seeing {1,2} as a single object or not.
I think you don't understand your own compiler. Your specification
says that the overloaded = is called when arrays are initialised so I
wanted to know if it would be called twice of 5 times in the above case.
Your compiler calls it twice, but I expected 5. Neither is "right"
but you have not specified how overloading works with arrays unless I
can tell from reading the do***ent.
> In case of doubt, we could do as C++ does.
>
>> T a2 = {3};
>
> This is a conforming call of the assignment operator.
The you have a bug in lcc-win32. operator= is called when I write:
T a2 = 3;
but not when I write:
T a2 = {3};
which I though was a deliberate (although potentially confusing)
feature to allow aggregate initialisation without using the overloaded
operator. However, the real point is that your specification is too
vague unless I can tell what lcc-win32 should do with both of these.
I should have been able to tell that there was bug without waiting for
you to tell me that there should have been a call to the assignment
operator.
> But this can be done only at compile time, if at global
> level since we have no function calls before main().
Yes, we've talked about this before and I disagree about your choice
on this.
>> (T[2]){1,2};
>>
>
> If you mean
> T tab[2] = {1,2};
>
> then two calls should be done.
Why two here? Did you not see the array in the example above?
Anyway, I did not mean what you wrote. Your specification has another
gap -- it does not say what happens when an aggregate is initialised
using a compound literal.
(T[2]){1,2};
is valid C and I'd expect you to make two calls to operator=. I'd
expect five if I write:
(T[5]){1,2};
but you spec says nothing about this form.
>> struct S { T t; };
>> S s1 = {1};
>
> One.
>
>> S s2 = {.x = 2};
>
> Did you mistype? What is "x"? It is the T t member?
Yes, should have been ".t = 2". I am sure you know lcc-win32 traps on
this syntax. Presumably it should simply call operator= once.
BTW, as an aside, I noticed that this program:
typedef struct T { int i; } T;
typedef struct S { T t; } S;
int main(void)
{
S s = {42};
return s.t.i;
}
is refused by lcc-win32 but I *think* is is valid, despite the missing
second {}s round the 42.
>> S as[5] = {1,2};
>
> Two calls to T's initializer.
OK. I'd have expected 5. The spec does not say what happens with
extra array elements. lcc-win32 re****ts two errors and refuses to
compile. (I am not complaining about that, I can see you are still
working on what overloading should and should not do in various
cases.)
>> Is the following permitted:
>>
>> const T x = 42;
>> x = 43;
>>
>> The compiler allows it but the specifications says nothing about it.
>
> This is the old problem of "const" in C that is not really
> const...
No. This is a new problem of an extension that does not warn the
programmer when they modify a read-only object. I C, a good compiler
tells me if I try to modify a const object.
>> What is the meaning of a pointer argument?
>
> This means that there are operators that have a meaning in C
> when using pointers.
>
> Operator ADD/SUB is well defined in C for
>
> Pointer + integer
> Pointer - integer
>
> Pointer - Pointer
>
> That is why pointer operator overloading is restricted.
Yes, I got that. I think I got confused. I thought one could have
pointer arguments but it seems there are restrictions. This:
T operator+(T &x, T *y)
is rejected but it can't conflict with normal pointer arithmetic, can
it?
>> What does the remark
>> "References can be replaced by arrays of length 1." mean?
>
> It means that if you write
>
> void function(T s[]);
>
> T s[1];
>
> The structure is always passed by reference. A hack surely,
> but a valid one.
I don't follow. That look like plain C. Where do references come in?
What has this to do woth operator overloading? The comment comes from
the middle of a table about permitted argument types.
--
Ben.
|
