← Back to team overview

kicad-developers team mailing list archive

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