On 2/28/2017 7:28 PM, Cirilo Bernardo wrote: > On Wed, Mar 1, 2017 at 11:13 AM, Wayne Stambaugh <stambau...@gmail.com> wrote: >> On 2/28/2017 7:07 PM, Cirilo Bernardo wrote: >>> On Wed, Mar 1, 2017 at 10:33 AM, Wayne Stambaugh <stambau...@gmail.com> >>> wrote: >>>> On 2/28/2017 4:08 PM, Cirilo Bernardo wrote: >>>>> On Wed, Mar 1, 2017 at 12:18 AM, Wayne Stambaugh <stambau...@gmail.com> >>>>> wrote: >>>>>> On 2/27/2017 8:57 PM, Cirilo Bernardo wrote: >>>>>>> On Tue, Feb 28, 2017 at 1:07 AM, Wayne Stambaugh <stambau...@gmail.com> >>>>>>> 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 >>> _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
