Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #70757 > unrolled thread

Question on a C++ string

Back to article view | Back to comp.lang.c++

Contents

  Question on a C++ string T <T@invalid.invalid> - 2019-12-28 22:35 -0800
    Re: Question on a C++ string Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-12-29 09:33 +0000
      Re: Question on a C++ string Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-29 01:45 -0800
        Re: Question on a C++ string T <T@invalid.invalid> - 2019-12-29 01:49 -0800
          Re: Question on a C++ string Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-12-29 11:04 +0000
          Re: Question on a C++ string Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-29 13:57 -0800
            Re: Question on a C++ string T <T@invalid.invalid> - 2019-12-29 14:57 -0800
      Re: Question on a C++ string T <T@invalid.invalid> - 2019-12-29 01:50 -0800
        Re: Question on a C++ string Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-12-29 11:08 +0000
          Re: Question on a C++ string T <T@invalid.invalid> - 2019-12-29 11:50 -0800
            Re: Question on a C++ string Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-29 13:57 -0800
              Re: Question on a C++ string T <T@invalid.invalid> - 2019-12-29 15:00 -0800
        Re: Question on a C++ string Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-29 13:57 -0800
          Re: Question on a C++ string T <T@invalid.invalid> - 2019-12-29 15:02 -0800
            Re: Question on a C++ string Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-30 01:28 +0200
        Re: Question on a C++ string Sam <sam@email-scan.com> - 2019-12-29 21:47 -0500
    Re: Question on a C++ string Bo Persson <bo@bo-persson.se> - 2019-12-29 11:00 +0100
      Re: Question on a C++ string T <T@invalid.invalid> - 2019-12-29 02:33 -0800
        Re: Question on a C++ string Bart <bc@freeuk.com> - 2019-12-29 12:09 +0000
          Re: Question on a C++ string T <T@invalid.invalid> - 2019-12-29 11:51 -0800
    Re: Question on a C++ string Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-29 12:17 +0200
      Re: Question on a C++ string Barry Schwarz <schwarzb@delq.com> - 2019-12-29 08:45 -0800
        Re: Question on a C++ string T <T@invalid.invalid> - 2019-12-29 11:54 -0800
    Re: Question on a C++ string Öö Tiib <ootiib@hot.ee> - 2019-12-29 02:56 -0800
      Re: Question on a C++ string T <T@invalid.invalid> - 2019-12-29 12:02 -0800
    Re: Question on a C++ string Barry Schwarz <schwarzb@delq.com> - 2019-12-29 08:39 -0800
      Re: Question on a C++ string T <T@invalid.invalid> - 2019-12-29 12:10 -0800

Page 2 of 2 — ← Prev page 1 [2]

#70764

On 29.12.2019 8:35, T wrote:
> Hi All,
>
> I have four different way of converting a Raku/Perl6 string
> into a C++ string to pass to native call.

In C++ a string means an object of class std::string. Its internal 
representation is not fixed and may depend on the compiler, its version 
and macro definitions. Suspecting you are talking about C strings instead.

In C, a string is commonly represented just as an array of characters. 
The length of the array may be indicated by a terminating zero 
character, or the length might be passed separately.

The type of the characters depends on the string encoding. Nowadays 
there are only a handful of encodings worth considering: ASCII, UTF-8, 
UTF-16 and UCS-4 (aka UTF-32). Note that ASCII is a proper subset of UTF-8.

> Three come out
> the same and one comes out with a 0x0000 (hex) at the end.
>
> The "say" functions shows me each byte in the converted
> string.  Which one is correct?

In principle this "say" may not show the terminating zero byte even if 
it is present. I'm not familiar with Perl internals.

Anyway, this depends on the SDK function you are passing this string to. 
If it does not take string length as a separate parameter, then it most 
likely expects it to be zero-terminated. I guess in Perl you can always 
add the zero terminator manually to the string before or after conversion.

>
> The following is "abcdefg" converted to a C string,
> "wstr", etc. is the method I used and is not part
> of the C string:
>
> 97 98 99 100 101 102 103       wstr
> 97 98 99 100 101 102 103 0     to-c-str
> 97 98 99 100 101 102 103       CArray[uint8].new
> 97 98 99 100 101 102 103       CArray[uint16].new
>
> And why do I care if I am using "uint8" or "uint16"
> to convert visable text?  What about the one
> with the 0 at the end?

It depends on the interface which string encoding it expects.

For example, in Windows, the SDK functions ending with "W" take string 
arguments in UTF-16 encoding, so for them I guess you need the last 
method, maybe with manually added zero terminator.

The Windows SDK functions ending with "A" are best avoided for anything 
else than fixed ASCII strings, as they use some random code page and 
call "W" variants internally anyway.

[toc] | [prev] | [next] | [standalone]

#70774

On Sun, 29 Dec 2019 12:17:08 +0200, Paavo Helde
<myfirstname@osa.pri.ee> wrote:

>In C, a string is commonly represented just as an array of characters. 
>The length of the array may be indicated by a terminating zero 
>character, or the length might be passed separately.

In order for the array to be a string, it must have a terminating
zero.  Non-string arrays can use other termination characters or have
the length specified separately but by definition they are not
strings.

-- 
Remove del for email

[toc] | [prev] | [next] | [standalone]

#70782

On 2019-12-29 08:45, Barry Schwarz wrote:
> On Sun, 29 Dec 2019 12:17:08 +0200, Paavo Helde
> <myfirstname@osa.pri.ee> wrote:
> 
>> In C, a string is commonly represented just as an array of characters.
>> The length of the array may be indicated by a terminating zero
>> character, or the length might be passed separately.
> 
> In order for the array to be a string, it must have a terminating
> zero.  Non-string arrays can use other termination characters or have
> the length specified separately but by definition they are not
> strings.
> 

Hi Barry,

I figured out through experimentation that Native Call
automatically adds the chr(0) on to the end of a CString.

And that sending Native Call a zero gets automatically
changed into a NULL.  Hmmm, I wonder what happens
if you really what a numerical zero.  That will be a
test for another day.

Trivia: I can stick all the chr(0) in a Raku/Perl6
string I want and in any position I want.  But
a Raku string is a "data structure", not an "array of
characters".  The end of the string is in the structure,
not the string itself.

Thank you all for all the wonderful help!

-T

[toc] | [prev] | [next] | [standalone]

#70768

On Sunday, 29 December 2019 08:36:08 UTC+2, T  wrote:
> Hi All,
> 
> I have four different way of converting a Raku/Perl6 string
> into a C++ string to pass to native call.  Three come out
> the same and one comes out with a 0x0000 (hex) at the end.

Why do not you ask your questions about Raku from its community? 
Seems that it exists? <https://raku.org/community/> 
Most of the people posting or reading this group do not really care
about it and the few that do can find the appropriate forums just
fine.

> The "say" functions shows me each byte in the converted
> string.  Which one is correct?
> 
> The following is "abcdefg" converted to a C string,
> "wstr", etc. is the method I used and is not part
> of the C string:
> 
> 97 98 99 100 101 102 103       wstr
> 97 98 99 100 101 102 103 0     to-c-str
> 97 98 99 100 101 102 103       CArray[uint8].new
> 97 98 99 100 101 102 103       CArray[uint16].new
> 
> And why do I care if I am using "uint8" or "uint16"
> to convert visable text?  What about the one
> with the 0 at the end?

Where Windows API has LPCWSTR there must be pointer that points
at buffer that contains zero-terminated UTF-16LE encoded text. 
Code points in UTF-16 are 16 bit. When someone wants to 
manipulate numeric values of those then it makes sense to use
8 bit or 16 bit integers for that.

[toc] | [prev] | [next] | [standalone]

#70783

On 2019-12-29 02:56, Öö Tiib wrote:
> Why do not you ask your questions about Raku from its community?
> Seems that it exists?<https://raku.org/community/>  
> Most of the people posting or reading this group do not really care
> about it and the few that do can find the appropriate forums just
> fine.

Hi Öö,

Well now, I am glad you asked!

I pound those guys with questions.  I even get on Raku's
chat line.

The reason I post here, is because those guys very
little knowledge of C and C++ and, well, you guys do.
Plus, there are a lot of mensches on this list.

And now that I ksow what is going on on he C and C+++
side, I understand much better how to use Raku's Native
Call.  Oh ya, and with you guys help and other help
from varoius places, I tracked down a bug in
RegQueryValueExW that I now know how to work around
(always send lpType a NULL despite what the documentation
says).

Thank you all for the wonderful help!

-T

By the way, I do not program in C or C++ for the simple
reason that I ADORE Raku and -- well to put it
bluntly -- I am not smart enough to program in C or C++.
My hat going off to your guys.

[toc] | [prev] | [next] | [standalone]

#70773

On Sat, 28 Dec 2019 22:35:54 -0800, T <T@invalid.invalid> wrote:

>Hi All,
>
>I have four different way of converting a Raku/Perl6 string
>into a C++ string to pass to native call.  Three come out

The word string has two defined meanings in the C++ language.  One is
the name of a type (std::string) defined in the Standard Template
Library.  The other is an array of characters terminated by a 0 value
as defined in the C standard which is included in C++ by reference.
Which one do you mean?

What does "native call" mean?  Is it to a C (or C++) function?  What
does that function expect?  Show us the prototype of the function.

>the same and one comes out with a 0x0000 (hex) at the end.

No they did not.  The last three are significantly different from each
other.

>The "say" functions shows me each byte in the converted
>string.  Which one is correct?

No, say did not show you that.  It showed you its interpretation of
the argument you gave it.  At the very least, it did not show you
seven bytes of data in the uint16 array.

Furthermore, none of the results is a std::string and only one of the
results is a C-style string.

>The following is "abcdefg" converted to a C string,
>"wstr", etc. is the method I used and is not part
>of the C string:

Something appears to be missing from this sentence.  What is the
method you used?  And what is not part of what?

>97 98 99 100 101 102 103       wstr
>97 98 99 100 101 102 103 0     to-c-str

This is a valid C-style string consisting of eight bytes/characters.

>97 98 99 100 101 102 103       CArray[uint8].new

This is an array of seven bytes/integers that may be considered
characters but it is not a string.

>97 98 99 100 101 102 103       CArray[uint16].new

This is an array of fourteen bytes (seven integers) that may be
considered wide characters but it is not a string.

>And why do I care if I am using "uint8" or "uint16"
>to convert visable text?  What about the one

You care because the function you are calling may expect one or the
other (or possibly have code to let it determine which you provided
but that is unlikely).

>with the 0 at the end?

This is the only one that is a string.  Whether that matters depends
on the function you are calling.

-- 
Remove del for email

[toc] | [prev] | [next] | [standalone]

#70784

On 2019-12-29 08:39, Barry Schwarz wrote:
> On Sat, 28 Dec 2019 22:35:54 -0800, T <T@invalid.invalid> wrote:
> 
>> Hi All,
>>
>> I have four different way of converting a Raku/Perl6 string
>> into a C++ string to pass to native call.  Three come out
> 
> The word string has two defined meanings in the C++ language.  One is
> the name of a type (std::string) defined in the Standard Template
> Library.  The other is an array of characters terminated by a 0 value
> as defined in the C standard which is included in C++ by reference.
> Which one do you mean?
> 
> What does "native call" mean?  Is it to a C (or C++) function?  What
> does that function expect?  Show us the prototype of the function.

Hi Barry,

Native Call is a module (documented by Satin himself)
in Raku/Perl6 that allows you to make system calls to .so
and .dll's.

> 
>> the same and one comes out with a 0x0000 (hex) at the end.
> 
> No they did not.  The last three are significantly different from each
> other.
> 
>> The "say" functions shows me each byte in the converted
>> string.  Which one is correct?
> 
> No, say did not show you that.  It showed you its interpretation of
> the argument you gave it.  At the very least, it did not show you
> seven bytes of data in the uint16 array.

Which was what I was after.

> Furthermore, none of the results is a std::string and only one of the
> results is a C-style string.

Native call converts this to a C string for you.  It is
not documented very well.


>> The following is "abcdefg" converted to a C string,
>> "wstr", etc. is the method I used and is not part
>> of the C string:
> 
> Something appears to be missing from this sentence.  What is the
> method you used?  And what is not part of what?
> 
>> 97 98 99 100 101 102 103       wstr
>> 97 98 99 100 101 102 103 0     to-c-str
> 
> This is a valid C-style string consisting of eight bytes/characters.
> 
>> 97 98 99 100 101 102 103       CArray[uint8].new
> 
> This is an array of seven bytes/integers that may be considered
> characters but it is not a string.
> 
>> 97 98 99 100 101 102 103       CArray[uint16].new
> 
> This is an array of fourteen bytes (seven integers) that may be
> considered wide characters but it is not a string.
> 
>> And why do I care if I am using "uint8" or "uint16"
>> to convert visable text?  What about the one
> 
> You care because the function you are calling may expect one or the
> other (or possibly have code to let it determine which you provided
> but that is unlikely).

Native Call adds the chr(0) to the end for you.  This
I had to find out through experimentation.

> 
>> with the 0 at the end?
> 
> This is the only one that is a string.  Whether that matters depends
> on the function you are calling.
> 

Since "W" calls use uint16, I settled on
     my $M = CArray[uint16].new("abcdefg".encode.list);
for simplicity.

Thank you for the wonderful help!  On my journey, I hit
a few curbs, ran over a fire hydrant, hit a squirrel
(that "might" have been on purpose, I ain't saying) but
I got there eventually!

-T

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c++

csiph-web