kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #40355
Re: 6.0 string proposal
Sure, but we’re going to be re-writing the parsers and formatters for s-expr so it’s going to be all different code anyway. (Granted the new code could have used the old infrastructure, but I think we need to wean ourselves from wxString either way.)
> On 30 Apr 2019, at 13:59, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
>
> Given that std::wstring is platform dependent, I would be opposed to
> using it. I'm not opposed to std::u32string but UTF8 is pretty well
> vetted so please keep that in mind. I think the possibility of breakage
> is low but I'm not naive enough to think that it's zero. You would have
> to do some serious testing to ensure the conversion of std::u32string to
> and from UTF8 isn't broken before I would be comfortable merging it into
> master.
>
> Wayne
>
> On 4/30/19 7:32 AM, Jeff Young wrote:
>> I suspect all our platforms use at least 32 bit ints, but even so
>> std::u32string does communicate the intent better.
>>
>> So change the proposal to that….
>>
>> Cheers,
>> Jeff.
>>
>>> On 30 Apr 2019, at 10:52, Andrew Lutsenko <anlutsenko@xxxxxxxxx <mailto:anlutsenko@xxxxxxxxx>
>>> <mailto:anlutsenko@xxxxxxxxx <mailto:anlutsenko@xxxxxxxxx>>> wrote:
>>>
>>> Hi,
>>> I have no opinion on the matter but would add a reminder that wchar_t
>>> is platform and compiler dependent.
>>> Consider using std::u32string instead of std::wstring if you want all
>>> code points to fit into one element.
>>>
>>> Regards,
>>> Andrew
>>>
>>> On Tue, Apr 30, 2019 at 2:36 AM Jeff Young <jeff@xxxxxxxxx <mailto:jeff@xxxxxxxxx>
>>> <mailto:jeff@xxxxxxxxx <mailto:jeff@xxxxxxxxx>>> wrote:
>>>
>>> We had talked earlier about throwing the wxWidgets UTF8 compile
>>> switch to get rid of our wxString re-entrancy problems. However,
>>> I noticed that the 6.0 work packages doc includes an item for
>>> std::string-ization of the BOARD. (While a lot more work, this is
>>> a better solution because it also increases our gui-toolkit-choice
>>> flexibility.)
>>>
>>> I’d like to propose that we use std::wstring for that. UTF8
>>> should *only* be an encoding format (similar to s-expr). It
>>> should never be used internally. That’s what unicode wchar_t’s
>>> are for.
>>>
>>> And I’d like to propose that we extend std::wstring-ization to
>>> SCH_ITEM and LIB_ITEM. (Then we can get rid of a bunch of our
>>> ugly mutex hacks.)
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
>>> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>
>>> Unsubscribe : https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
>>> More help : https://help.launchpad.net/ListHelp <https://help.launchpad.net/ListHelp>
>>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
>> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>> Unsubscribe : https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
>> More help : https://help.launchpad.net/ListHelp <https://help.launchpad.net/ListHelp>
>>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
> Unsubscribe : https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
> More help : https://help.launchpad.net/ListHelp <https://help.launchpad.net/ListHelp>
Follow ups
References