geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ernest Burghardt <eburgha...@pivotal.io>
Subject Re: [Discussion] Native - Should C++ client support wchar_t type?
Date Fri, 27 Oct 2017 17:32:32 GMT
+1 for removal

On Fri, Oct 27, 2017 at 10:03 AM, Michael William Dodge <mdodge@pivotal.io>
wrote:

> I think support for wchar_t adds unnecessary complexity and should be
> removed.
>
> Sarge
>
> > On 26 Oct, 2017, at 13:05, Jacob Barrett <jbarrett@pivotal.io> wrote:
> >
> > I think we should get rid of it. There are plenty of discussions out
> there around C++ strings and how they relate to Unicode. Wide string does
> not mean Unicode. The general consensus I have seen is to just use char and
> require UTF-8 encoding. We have lots of confusion in our code around
> whether a string is Unicode or ASCII. I say remove the confusion and all
> strings are Unicode in UTF-8 encoded 8 bit chars. Also convert all char* to
> std::string for which we already have a ticket.
> >
> > -Jake
> >
> >
> >> On Oct 26, 2017, at 12:15 PM, David Kimura <dkimura@pivotal.io> wrote:
> >>
> >> While working on removing out parameters, we noticed code that makes
> >> assumption that wchar_t is always 16 bits.
> >>
> >> virtual void PdxInstance::getField(const char* fieldName, wchar_t&
> value)
> >> const = 0;
> >>
> >> void PdxInstanceImpl::getField(const char* fieldname, wchar_t& value)
> const
> >> {
> >>   auto dataInput = getDataInputForField(fieldname);
> >>   uint16_t temp = dataInput->readInt16();
> >>   value = static_cast<wchar_t>(temp);
> >> }
> >>
> >>
> >>
> >> According to cppreference[1], this assumption is incorrect.  If that is
> the
> >> case, should this implementation be fixed or can it be deleted
> altogether?
> >>
> >> Thanks,
> >> David
> >>
> >> [1] http://en.cppreference.com/w/cpp/language/types
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message