← Back to team overview

kicad-developers team mailing list archive

Re: Locale fix in KiCAD is not working (breaks my build)


On 15/03/2013, at 19:32, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:

> On 03/15/2013 11:39 AM, Miguel Angel Ajo Pelayo wrote:
>> Ok, committed in 4008, cleanups included. 
>> Finally I used the LOCALE_IO implementation, because converting in
>> some situations didn't work, and my time was exhausting for today…
>> I think there are some locale manipulators in std:: c++ that would
>> let us do those conversions without switching system locale, but we will have to try.
> We don't have to try.  We could wait until there is a problem.
I feel like planting bombs around ;)

> If or when there is a problem, I would fight to protect the interfaces
> we have become dependent on, one of which is OUTPUTFORMATTER::Print().
> You shouldn't try to re-implement this without my help.

In vsnprintf (used in OUTPUTFORMATTER::vprint) is affected by locale too, right?,
You mean that on locale changes we should protect those call?

> Writing good C++ software is really about placing and using carefully
> crafted interfaces.   After that you can ad lib in between the
> interfaces, so long as you honour them.

Yes :)

> A C++ thread can be like the quirky guy who walks up the stairs of a
> skyscraper, travelling across each floor and then back into the
> stairwell to continue ascending.
> When he travels across each floor, he is wearing the proper attire and
> acting properly.  This is the interface. 
> But in the stairwell he very well may be acting quite differently,
> nobody knows, nobody cares.   Could be naked in there, could be
> walking on his hands, screaming, yelling.   This is the implementation.

Good simile, 

Yes, I know the problem, and the GIL python think made me remember that one
must not forget, reentrancy, and thread-safety are your friends!!

In pcbnew, I cannot imagine yet a situation when all this could happen, somebody printing a report somehow, while hits a key 
or writes a file?, sounds quite improbable. But yet I'm sure there are possibilities we didn't think of… or not.. :)

> It pays to know which part of the C++ thread you are dealing with.  
> Saves some embarrassment, and makes for better and more easily
> maintained code.  Because you can always smoke bomb the implementation.

Is OUTPUTFORMATTER to be used for tasks like the one I was dealing with above?,  printing a %lf to a string?,
For the name, it looks like a class to be used when dealing with file writing, didn't have enough time to look inside yet.

Follow ups