kicad-developers team mailing list archive
Mailing list archive
Re: [PATCH] Reworking patchlets, first issue
On Fri, May 11, 2012 at 08:06:29AM -0500, Dick Hollenbeck wrote:
> On 05/11/2012 01:57 AM, Lorenzo Marcantonio wrote:
> > Keeping alterations separate is a lot of work, since refactoring tends
> > to be a recursive process
> Agreed, it is a lot of work now. (So is reading and approving a big patch.)
> One way to do this refactoring work, future-istically speaking, is to create a branch from
> a checkout, and then commit to the that branch at intermediate points.
More or less is what I'm doing here. Only at the end I have to collect
the patch from my version and hope it applies to the trunk (or IIRC
bzr call it 'tip').
> We had this conversation already. Again, const char* does not compile here.
Yes I remember. Still a strange thing since I see no reason for it to
fail... no idea (OTOH my compile fails on some wxDebug, so...)
> I said I would look at it when I got to 4.6 gcc, again. If the wx headers cannot provide
> a portable hashtable, we'll look elsewhere.
It's only a warning for me, but 'conceptually' the key should be const.
> > similarly I get ambiguous warning on the + '\n' + usage, which
> > is easily fixed with wxChar( '\n' ) (the message is funny, too)
> That's a good fix.
Rules on ambiguity and automatic conversion in C++ are soooo complicated
that they actually change from a release to the other. Also, regarding the
return value optimization of a while ago, the current standard allow to
the compiler to *not* call the copy constructor to build the return
value, to optimize it (so the 'as-if' rule for compiler is officially broken)
Wikipedia cites this article http://www.drdobbs.com/cpp/184403855; it's
I like C++ even less each day... at least C is self consistent XD
> > 004 The various flags in EDA_ITEM (m_status and m_Flags... why two
> > sets?) became and enum in EDA_ITEM
Here lies my bug :P operator & uses | with atrocious consequences. I'll
post the corrected version