Aleksander,
I just differently interpreted the proposal for c_str() and extra byte at
the and of binary data seemed potentially problematic to me, inconvenient.
Certainly, zero bytes in middle are valid, and string is fine container
for multibyte encodings.
I surely agree w/ your point. In fact, I'll change the binary data support
to std::string too. Simpler.
Thanks!
--
Mateusz Loskot, http://mateusz.loskot.net
(Sent from mobile, apology for top-posting or broken quotes)
On Feb 4, 2013 1:12 AM, "Pawel Aleksander Fedorynski" <[email protected]>
wrote:
>
> On Sun, Feb 3, 2013 at 4:21 PM, Mateusz Loskot <[email protected]> wrote:
>
>> Aleksander, Vadim,
>>
>> Well caught points!
>>
>>
>> On 3 February 2013 22:35, Vadim Zeitlin <[email protected]> wrote:
>> > On Sun, 3 Feb 2013 14:31:06 -0800 Pawel Aleksander Fedorynski <
>> [email protected]> wrote:
>> > PAF> On Sun, Feb 3, 2013 at 2:26 PM, Vadim Zeitlin <
>> [email protected]> wrote:
>> > PAF> > On Sun, 3 Feb 2013 14:17:49 -0800 Pawel Aleksander Fedorynski <
>> > PAF> > [email protected]> wrote:
>> > PAF> >
>> > PAF> > PAF> It occurs to me that some other db engines (Oracle?)
>> probably send
>> > PAF> > values
>> > PAF> > PAF> in non-string format, what should into_as_raw_text() do
>> then?
>> > PAF> > PAF>
>> > PAF> > PAF> (a) signal an error?
>> > PAF> > PAF>
>> > PAF> > PAF> (b) put the raw value (which may be non-printable and may
>> be packed
>> > PAF> > in some
>> > PAF> > PAF> unobvious way) in the provided string, say the value is of
>> type INT32
>> > PAF> > and
>> > PAF> > PAF> some db sends four bytes over the wire, should we put these
>> exact four
>> > PAF> > PAF> bytes into the string?
>> > PAF> > PAF>
>> > PAF> > PAF> (c) convert to string?
>> > PAF> >
>> > PAF> > I'd say (b). "Raw" would seem to mean this, i.e. exactly the
>> bytes
>> > PAF> > received.
>> > PAF>
>> > PAF> Yes, I was thinking the same thing. But then it shouldn't be
>> raw_text,
>> > PAF> raw_string maybe or raw_bytes even?
>> >
>> > Yes, taking this into account, into_raw_bytes() or maybe
>> into_raw_buffer()
>> > (just because "buffer" is something you can put things into, while
>> > "bytes"... not so much IMHO) does seem better, thanks!
>>
>> One may argue 'raw' is not so meaningful either, so into_bytes_buffer()
>> with implicit assumption, bytes is a raw form of data (in software in
>> general).
>>
>> The std::string sink type for into_raw_buffer() might not be the best
>> choice
>> as it has different semantic. It is a (null-terminated, if [1] is
>> accepted)
>> character sequence.
>>
>
> std::string is a perfectly valid choice for binary data, it is a sequence
> of bytes not of characters. Your reference proposes that there is always
> an extra zero-byte stored after all the bytes in the string, which changes
> nothing from the point of view of using the string, it would be an
> implementation convenience for c_str(). It certainly does not propose that
> there are no zero bytes allowed in the middle of the string.
>
>
>> Wouldn't it be clearer to have into_raw_buffer(std::vector<byte>) ?
>>
>> The discussion about the into_as_raw_text() and later about
>> into_raw_buffer()
>> made me think if this idea potentially could share some common
>> elements with binary data support.
>>
>> Here I have a branch
>> https://github.com/mloskot/soci/tree/soci-type-binary
>> where I've been working on binary data support for SOCI
>> https://github.com/mloskot/soci/commit/8f5ea63f
>> The prototype is very basic:
>> 1) New into/use type indicated by x_binary_string
>> 2) Trivial, but SOCI-defined bytes buffer
>> namespace soci {
>> struct binary_string
>> {
>> std::vector<std::uint8_t> data_;
>> };
>> }
>>
>
> I see no upside to introducing any such type. std::string is perfectly
> sufficient from the practical point of view and is more convenient, not to
> mention standardized. And if any SOCI user wants a special type for
> whatever reason, chances are they will have their own custom type for
> storing binary strings and will convert or type-cast from your
> soci::binary_string to their own type, so they might as well convert from
> std::string.
>
> Best,
>
> Aleksander
>
> 3) The data exchange machinery updated to recognise the new
>> x_binary_string
>>
>> It seems to be, that the into_raw_buffer() and the binary support
>> require the same kind of data type - a container for sequence of bytes
>> of arbitrary length - a buffer.
>>
>> Would it be possible to have single container for raw byte sequence in
>> SOCI?
>>
>> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2534.html
>>
>> Best regards,
>> --
>> Mateusz Loskot, http://mateusz.loskot.net
>>
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_jan
>> _______________________________________________
>> soci-users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/soci-users
>>
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_jan
> _______________________________________________
> soci-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/soci-users
>
>
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
soci-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/soci-users
