kicad-developers team mailing list archive

["Carl Rash" <crash@xxxxxxxxxxxx>]

I would like to add one more comment to this particular discussion, for a
tool to recommend removing operator overloading, I think the developer and
all who heed this have had one swig too many.

-----Original Message-----
From: Carl Rash [mailto:crash@xxxxxxxxxxxx] 
Sent: Sunday, April 07, 2013 6:57 AM
To: 'jp charras'; 'kicad-developers@xxxxxxxxxxxxxxxxxxx'
Subject: RE: [Kicad-developers] About the NextColor function

I was becoming concerned that the focus of KiCad development was becoming
the focus of computer science and not electrical engineering and computer
graphics. But this, this is ridiculous. If any lint tool tells you to throw
out one of the best features of a programming language, in particular a
feature that contributes significantly to the development and understanding
of advanced algorithms, it's time to get a new tool.
C.Rash

-----Original Message-----
From: kicad-developers-bounces+crash=triad.rr.com@xxxxxxxxxxxxxxxxxxx
[mailto:kicad-developers-bounces+crash=triad.rr.com@xxxxxxxxxxxxxxxxxxx] On
Behalf Of jp charras
Sent: Saturday, April 06, 2013 10:54 AM
To: kicad-developers@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Kicad-developers] About the NextColor function

Le 06/04/2013 14:25, Lorenzo Marcantonio a écrit :
> I'm not too happy to discard the convenience of C++ operator 
> overloading only to fix a swig warning...
>
> Other than that, if we have to need a named function at least we 
> should have it in functional fashion like col = NextColor(col) or a 
> better name like Advance(col); actually Advance(&col), since we 
> decided not to use nonconst references... in my private branch I am 
> using ADTs even for LAYER_NUM and LAYER_MSK (implemented as enum but 
> ready for 'upgrade'); it would be a real mess to not being able to use 
> operators ++, & and
> | (for example).
>
> Do we really want to make without operator overloading? Being from a 
> LISP background I have no issue with that (since there are no 
> operators and everything is prefix, anyway) but in C++ this is... ugly.
>
> I'd like to discuss this (since I have a lot of ++, & and | done on 
> layers, now...)
I am not a swig specialist.
Certainly, we could ignore swig warnings (by disabling these warnings), but
ignoring warnings (unless we know exactly the consequence) is always a bit
annoying (generally speaking).
Perhaps a swig specialist could say if (or when) operator overload warnings
can be safely disabled.
Obviously, "col = NextColor(col)" can be replaced by a better function.

--
Jean-Pierre CHARRAS


_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp