Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Operator overloading in C

Reply
Thread Tools

Operator overloading in C

 
 
jacob navia
Guest
Posts: n/a
 
      08-09-2003

"Stefano Ghirlanda" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "jacob navia" <(E-Mail Removed)> writes:
>
> > C++ introduced an interesting feature (among others): operator
> > overloading.

>
> <explanation snipped>
>
> Just my 2c: operator (and function) overloading are about the only C++
> features I miss since I switched (back) to C.
>
> I think a number of replies to your post reflect the fear that, as
> soon as one starts to introduce new features, it will be impossible to
> stop and C will soon become as complex as C++. And I don't deny that
> there may be some truth in this claim.
>


Yes, and the experience of C++ should be a warning to all that start the same way:

KNOW WHEN TO STOP.

jacob


 
Reply With Quote
 
 
 
 
Serve La
Guest
Posts: n/a
 
      08-10-2003

"Zeljko Vrba" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> In article <bh2ohn$a1e$(E-Mail Removed)>, jacob navia wrote:
> >
> > I say operator overloading is useful.
> >

> I didn't say it isn't. But then use C++. Nobody forces you to use classes,
> inheritance, access levels and other C++ novelties. You can use it just as
> an "enhanced C" using only features that you like/need/feel comfortable

with.

wrong. If you work with people that use C++, you can be sure that at some
point you have to use class, inheritance, access levels and other C++
novelties. This is only true if you work alone.



 
Reply With Quote
 
 
 
 
Andre
Guest
Posts: n/a
 
      08-10-2003


Serve La wrote:
> "Zeljko Vrba" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>
>>In article <bh2ohn$a1e$(E-Mail Removed)>, jacob navia wrote:
>>
>>>I say operator overloading is useful.
>>>

>>
>>I didn't say it isn't. But then use C++. Nobody forces you to use classes,
>>inheritance, access levels and other C++ novelties. You can use it just as
>>an "enhanced C" using only features that you like/need/feel comfortable

>
> with.
>
> wrong. If you work with people that use C++, you can be sure that at some
> point you have to use class, inheritance, access levels and other C++
> novelties. This is only true if you work alone.


Exactly. If you're into component development and enjoy abstraction and
reusability, there's always going to be class, inheritance etc involved.
Also, what Zeljko said is also only true when you deliberately force an
application, that could benifit from Object orientation, to comply in a
non-OO fashion. Like Serve said, if you're working alone, you're the boss.

-Andre

 
Reply With Quote
 
Dan Pop
Guest
Posts: n/a
 
      08-11-2003
In <bh0vl6$nfk$(E-Mail Removed)> "jacob navia" <(E-Mail Removed)> writes:

>The syntax used is:
>
>TYPE operator+(TYPE a,TYPE b)
>{
>}
>
>When in your program you use
> TYPE a,b;
> ...
> a+b;
>Means that you call the operator function with those two numbers. This is similar to C++, but since
>there are no classes (C is not object oriented) everything is quite simple.
>
>Note that this is an extension compatible with C and it is important to know that the C standard
>doesn't forbid extensions. They should not introduce new keywords though.


The C standard requires a diagnostic for

TYPE operator+(TYPE a,TYPE b) {}

because it is syntactically invalid in C. The only extensions allowed
by the C standard are those based on undefined behaviour. So, to make
your extension compatible with standard C, replace "operator" by a an
identifier in the implementation name space, e.g. __operator__:

TYPE __operator__+(TYPE a,TYPE b) {}

invokes undefined behaviour (a reserved identifier not explicitly defined
by the C standard is used), therefore no diagnostic is needed, and your
compiler is free to silently overload the + operator as a result.

This technique of adding extensions is widely used by GNU C, so that
people can still use them if they invoke gcc in standard C mode. If your
compiler has also a non-standard C mode, you can use both "operator" and
"__operator__" in that mode. When invoked in standard C mode, "operator"
becomes an indentifier in the program namespace, though.

>In my implementation it means that
>
>int operator = 6;
>
>still works as it should. No new keywords.


It doesn't matter, TYPE operator+(TYPE a,TYPE b) {} still requires a
diagnostic, according to the C syntax.

>The operator symbol is recognized if (and only if):
>1) The level is global, i.e. not within a function definition.
>2) It is followed by one of the defined operator symbols (+, -, etc)
>3) This must be followed by a normal function definition. The name of this function is the sequence
>of types in the argument list, the "signature" in technical terms.


That's wrong, again. Such names are in the program name space, you can't
define them by magic. Use the __ prefix to fix the issue. But you have
an additional problem: if the function signature is the function name,
how do you distiguish between operators with identical signatures, e.g.

TYPE operator+(TYPE a,TYPE b) {...}
TYPE operator-(TYPE a,TYPE b) {...}

>Is this useful?


The answer is mostly an issue of religion. For better acceptance, don't
allow TYPE to be any of the C scalar types.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      08-11-2003

"Dan Pop" <(E-Mail Removed)> wrote in message news:bh88o1$qpj$(E-Mail Removed)...
> In <bh0vl6$nfk$(E-Mail Removed)> "jacob navia" <(E-Mail Removed)> writes:
>

[snip]
> But you have
> an additional problem: if the function signature is the function name,
> how do you distiguish between operators with identical signatures, e.g.
>
> TYPE operator+(TYPE a,TYPE b) {...}
> TYPE operator-(TYPE a,TYPE b) {...}
>


The name of the first operator is:

_operator_plus_TYPE_TYPE
the second is
_operator_minus_TYPE_TYPE


The biggest problem I had is the pointer problem.
The operator + can't be defined with types like

TYPE operator+(TYPE a,int b)

since the operation a+7

is used in the language already (means a + 7 *sizeof(a)) and would
clash with standard C. This restriction is applied to all operators.

In any way, the compiler has several flags that make it reject any
non-standard grammar like this (-ansic) or even go back to ansi 89.

jacob


 
Reply With Quote
 
Jun Woong
Guest
Posts: n/a
 
      08-12-2003

"Dan Pop" <(E-Mail Removed)> wrote in message news:bhasgl$dpg$(E-Mail Removed)...
> In <bh8h8c$ddb$(E-Mail Removed)> "jacob navia" <(E-Mail Removed)> writes:
>
>
> >"Dan Pop" <(E-Mail Removed)> wrote in message news:bh88o1$qpj$(E-Mail Removed)...
> >> In <bh0vl6$nfk$(E-Mail Removed)> "jacob navia" <(E-Mail Removed)> writes:
> >>

> >[snip]
> >> But you have
> >> an additional problem: if the function signature is the function name,
> >> how do you distiguish between operators with identical signatures, e.g.
> >>
> >> TYPE operator+(TYPE a,TYPE b) {...}
> >> TYPE operator-(TYPE a,TYPE b) {...}
> >>

> >
> >The name of the first operator is:
> >
> >_operator_plus_TYPE_TYPE
> >the second is
> >_operator_minus_TYPE_TYPE

>
> That's not good enough, you really need *two* preceding underscores.


One can think they are good enough. Those function names doesn't
pollute the users' valid name space.


--
Jun, Woong ((E-Mail Removed))
Dept. of Physics, Univ. of Seoul



 
Reply With Quote
 
Richard Bos
Guest
Posts: n/a
 
      08-12-2003
"Jun Woong" <(E-Mail Removed)> wrote:

> "Dan Pop" <(E-Mail Removed)> wrote in message news:bhasgl$dpg$(E-Mail Removed)...
> > In <bh8h8c$ddb$(E-Mail Removed)> "jacob navia" <(E-Mail Removed)> writes:
> >
> > >The name of the first operator is:
> > >
> > >_operator_plus_TYPE_TYPE
> > >the second is
> > >_operator_minus_TYPE_TYPE

> >
> > That's not good enough, you really need *two* preceding underscores.

>
> One can think they are good enough. Those function names doesn't
> pollute the users' valid name space.


Not on a file scope level, but they can be blocked within a block scope,
and then you're in trouble - you try debugging why just this operator
won't work for just these types in just this function, and no others.
You could, of course, reserve these names for yourself, but it's better
to make sure.

Richard
 
Reply With Quote
 
Jun Woong
Guest
Posts: n/a
 
      08-12-2003

"Richard Bos" <(E-Mail Removed)> wrote in message news:(E-Mail Removed)...
> "Jun Woong" <(E-Mail Removed)> wrote:
>
> > "Dan Pop" <(E-Mail Removed)> wrote in message news:bhasgl$dpg$(E-Mail Removed)...
> > > In <bh8h8c$ddb$(E-Mail Removed)> "jacob navia" <(E-Mail Removed)> writes:
> > >
> > > >The name of the first operator is:
> > > >
> > > >_operator_plus_TYPE_TYPE
> > > >the second is
> > > >_operator_minus_TYPE_TYPE
> > >
> > > That's not good enough, you really need *two* preceding underscores.

> >
> > One can think they are good enough. Those function names doesn't
> > pollute the users' valid name space.

>
> Not on a file scope level, but they can be blocked within a block scope,


Oh, I missed that those names can be inserted where the overloaded
operators are actually used in an expression.

Thanks.


--
Jun, Woong ((E-Mail Removed))
Dept. of Physics, Univ. of Seoul



 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      08-12-2003

"Dan Pop" <(E-Mail Removed)> wrote in message news:bhasgl$dpg$(E-Mail Removed)...
> In <bh8h8c$ddb$(E-Mail Removed)> "jacob navia" <(E-Mail Removed)> writes:
>
> >> TYPE operator+(TYPE a,TYPE b) {...}
> >> TYPE operator-(TYPE a,TYPE b) {...}
> >>

> >
> >The name of the first operator is:
> >
> >_operator_plus_TYPE_TYPE
> >the second is
> >_operator_minus_TYPE_TYPE

>
> That's not good enough, you really need *two* preceding underscores.
>


Of course, the compiler adds another underscore, as with any other function. The
resulting name in the object file (that can be dumped) is:

__operator_minus_TYPE_TYPE

> As I already said, operator overloading should not be implemented for
> scalar types.


This would be an enormous restriction Dan.

I see the usage of this mainly for defining new types of NUMBERS.
Then, it is paramount to have conversion features, and interaction with
native types. For instance when using the qfloat data type (350 bits
precision) you can write:

qfloat b = 67;
qfloat c = b+1;

This is because there is an operator defined like this:

qfloat operator+(qfloat,int);

In standard C it is not possible to add an integer to a structure, so
I STAY within UB (undefined behavior) and my implementation
can't clash with the C standard.

Am I correct?
Can you explain your motivations why this is incorrect?

Thanks

jacob


 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      08-13-2003

> I believe Dan is referring to int operator+(int, int); and similar - any
> operation that is already defined by the C standard.


Of course. One of the arguments *must* be a user defined type.

There are two kinds operators:
monadic (! for instance) and dyadic (+, -, etc)
At least one argument must be a user defined type, and there is a table
in the documentation indicating where pointers are possible. For instance
pointer multiplication or division is undefined in C, so you can safely
define operators to those functions that take pointers.

Addition and above all subtraction can't take plain pointers.

A simplification is done with the cast operator

typea operator()(typeb a) { }

This means that when you write:
typeb b;
typea a;

a = (typea)b;

the above conversion function is called.

If you do not add this, the code becomes messy, with too many ad hoc
operators that define the same thing.

A big problem with my schema is type aliasing.

When you write:
typedef unsigned long DWORD;

and later:
type operator+(type,DWORD);

should the operator accept unsigned ints?
Or only DWORDS?

Questions and questions. One of the reasons of this discussion is
to hear to opinion of other people more clever than me.

What do you think?

jacob

P.S. concerning your other remark:
> It's not the name in the object file, it's the name in the C namespace
> that matters. _operator_minus_TYPE_TYPE is a valid name for a user
> program to use for a block-scope identifier.


I thought that identifiers beginning with _ are reserved and should not be used.
Should I add a new underscore? (Not very difficult to do).


"Kevin Easton" <(E-Mail Removed)> wrote in message
news:newscache$2g5jjh$urc$(E-Mail Removed)...
> jacob navia <(E-Mail Removed)> wrote:
> >
> > "Dan Pop" <(E-Mail Removed)> wrote in message news:bhasgl$dpg$(E-Mail Removed)...
> >> In <bh8h8c$ddb$(E-Mail Removed)> "jacob navia" <(E-Mail Removed)> writes:
> >>
> >> >> TYPE operator+(TYPE a,TYPE b) {...}
> >> >> TYPE operator-(TYPE a,TYPE b) {...}
> >> >>
> >> >
> >> >The name of the first operator is:
> >> >
> >> >_operator_plus_TYPE_TYPE
> >> >the second is
> >> >_operator_minus_TYPE_TYPE
> >>
> >> That's not good enough, you really need *two* preceding underscores.
> >>

> >
> > Of course, the compiler adds another underscore, as with any other function. The
> > resulting name in the object file (that can be dumped) is:
> >
> > __operator_minus_TYPE_TYPE

>
> It's not the name in the object file, it's the name in the C namespace
> that matters. _operator_minus_TYPE_TYPE is a valid name for a user
> program to use for a block-scope identifier.
>
> >> As I already said, operator overloading should not be implemented for
> >> scalar types.

> >
> > This would be an enormous restriction Dan.
> >
> > I see the usage of this mainly for defining new types of NUMBERS.
> > Then, it is paramount to have conversion features, and interaction with
> > native types. For instance when using the qfloat data type (350 bits
> > precision) you can write:
> >
> > qfloat b = 67;
> > qfloat c = b+1;
> >
> > This is because there is an operator defined like this:
> >
> > qfloat operator+(qfloat,int);
> >
> > In standard C it is not possible to add an integer to a structure, so
> > I STAY within UB (undefined behavior) and my implementation
> > can't clash with the C standard.
> >
> > Am I correct?
> > Can you explain your motivations why this is incorrect?

>
> I believe Dan is referring to int operator+(int, int); and similar - any
> operation that is already defined by the C standard.
>
> - Kevin.
>



 
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
overloading operator->*() and operator->() gob00st@googlemail.com C++ 2 02-21-2009 04:26 AM
overloading operator->*() and operator->() gob00st@googlemail.com C++ 11 02-20-2009 08:52 PM
user defined conversion operator or operator overloading? hurcan solter C++ 3 08-29-2007 07:39 PM
Why is overloading operator. (member operator) forbidden? dascandy@gmail.com C++ 11 05-16-2007 07:54 PM
Operator overloading on "default" operator John Smith C++ 2 10-06-2004 10:22 AM



Advertisments