kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 2/28/2017 7:28 PM, Cirilo Bernardo wrote:
> On Wed, Mar 1, 2017 at 11:13 AM, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
>> On 2/28/2017 7:07 PM, Cirilo Bernardo wrote:
>>> On Wed, Mar 1, 2017 at 10:33 AM, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
>>>> On 2/28/2017 4:08 PM, Cirilo Bernardo wrote:
>>>>> On Wed, Mar 1, 2017 at 12:18 AM, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
>>>>>> On 2/27/2017 8:57 PM, Cirilo Bernardo wrote:
>>>>>>> On Tue, Feb 28, 2017 at 1:07 AM, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
>>>>>>>> On 2/26/2017 4:04 PM, Cirilo Bernardo wrote:
>>>>>>>>> There is one other way which I found after much digging
>>>>>>>>> and it involves a GCC extension. Since we use GCC on
>>>>>>>>> Windows this might be acceptable:
>>>>>>>>>
>>>>>>>>> a. create a derived class of std::ifstream/ofstream. On
>>>>>>>>> Windows the derived class will be used while on other
>>>>>>>>> OS it will simply be typedef to std::ifstream/ofstream
>>>>>>>>
>>>>>>>> This seems reasonable to me.
>>>>>>>>
>>>>>>>
>>>>>>>  I had a look at the GCC STL implementation and unfortunately
>>>>>>> is is impossible for me to implement (a) since I can't accomplish
>>>>>>> what I want by deriving std::ifstream/ofstream due to the access
>>>>>>> specifiers on the necessary member variables and the fact that
>>>>>>> the open() function is not declared virtual.
>>>>>>>
>>>>>>>>>
>>>>>>>>> b. overload open() to use the gcc extension like this:
>>>>>>>>> __gnu_cxx::stdio_filebuf buf( _wopen ( utf8_filename, _O_RDONLY ) );
>>>>>>>>> std::istream mystream ( &buf );
>>>>>>>>
>>>>>>>> If this is portable, than I'm file with this as well but on the surface
>>>>>>>> it looks gcc specific.  If that is the case, then I would rather got
>>>>>>>> with option a.
>>>>>>>>
>>>>>>>
>>>>>>> Even solution (a), which I now know is not possible, would have been
>>>>>>> a gcc-specific hack.
>>>>>>>
>>>>>>> The solution I'm working on at the moment requires the replacement of
>>>>>>>
>>>>>>> std::ifstream X;
>>>>>>> X.open( filename, ... );
>>>>>>> X.close();
>>>>>>>
>>>>>>> with
>>>>>>>
>>>>>>> OPEN_ISTREAM( X, filename );
>>>>>>> CLOSE_STREAM( X );
>>>>>>>
>>>>>>> On builds which are not MinGW the helper macros generate exactly
>>>>>>> the same code as before. On MinGW builds, the helper macros
>>>>>>> create an extra class which creates an i/ostream and cleans up
>>>>>>> where required on destruction. The only caveat in MinGW is that
>>>>>>> rather than an explicit ifstream/ofstream the object which is actually
>>>>>>> created is an istream/ostream, but this is not a difficult thing to handle.
>>>>>>> The good thing about preserving the use of std::iostream is that I
>>>>>>> can eliminate some of the locale switching code and simply use
>>>>>>> imbue() on the open streams to avoid unintended effects on other
>>>>>>> code.
>>>>>>
>>>>>> I'm not sure at this point why you wouldn't just use FILE_LINE_READER or
>>>>>> wxFFileInputStream which we know both work with utf8 file names.  It
>>>>>> seems a bit like reinventing the wheel.  I realize this doesn't solve
>>>>>> the oce issue but for KiCad's file parsing usage, I think it makes more
>>>>>> sense.  I'm not saying your solution isn't valid, it just seems like
>>>>>> unnecessary work.
>>>>>>
>>>>>
>>>>> The std::stream objects have modular localization support which we need
>>>>> to force "C" locale for VRML and IDF output and of course the '<<' and '>>'
>>>>> stream operators. The code which needs to be reworked already uses
>>>>> streams, so this gcc-specific hack is the easiest way to fix the UTF8
>>>>> issue within KiCad (but of course not for external libs like OCE). This
>>>>> change is already a 1600+ lines patch + a few hundred lines for the
>>>>> additional files. Changing the modules to use FILE_LINE_READER
>>>>> means that we need to perform app-wide locale changes just to input/
>>>>> output a file since wx does not implement stream locale settings, plus
>>>>> I would need to change the many hundreds (possibly a few thousand)
>>>>> lines with streaming ops.
>>>>
>>>> Please fix it this way.  I'm not sure I really like it but it sounds
>>>> like you've programmed yourself into a hole.  I try to avoid the stream
>>>> << and >> operators just because of these issues.
>>>>
>>>
>>> Hi Wayne,
>>>
>>>   Do you mean use the wxStreams instead of std::stream?
>>
>> Now I'm confused.  If you can fix it without resorting to a gcc-specific
>> hack, that would be my preference but I assumed that you were talking
>> about std::stream.
>>
> 
> At the moment the only not-gcc-hack means is to painfully convert everything
> to use the wxStream.  The gcc hack has already been implemented and tested
> and works fine.

Please post the patch when you get a chance so we can test it and merge
it if there are no issues.


> 

<<< snipped >>>