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 1 of 2  [1] 2  Next page →

#70757 — Question on a C++ string

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.

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?

Many thanks,
-T

[toc] | [next] | [standalone]

#70759

On Sun, 2019-12-29, 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.
>
> 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?

You have "C++ string" in the subject line, but this question seems to
be as offtopic as the other recent ones from you.  I don't see how to
help you with this problem, from a comp.lang.c++ point of view.

From a C perspective, a string is a pointer to the first char in a
sequence, and the string ends with a char 0 marker.  That's probably
the one your Windows API wants, if it's a C API like someone wrote.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#70760

Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
[...]
> From a C perspective, a string is a pointer to the first char in a
> sequence, and the string ends with a char 0 marker.  That's probably
> the one your Windows API wants, if it's a C API like someone wrote.

No, from a C perspective "A string is a contiguous sequence of
characters terminated by and including the first null character."

What you're describing is a pointer to a string (which is what is
typically passed to functions).

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
    [Note updated email address]
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

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

#70761

On 2019-12-29 01:45, Keith Thompson wrote:
> Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
> [...]
>>  From a C perspective, a string is a pointer to the first char in a
>> sequence, and the string ends with a char 0 marker.  That's probably
>> the one your Windows API wants, if it's a C API like someone wrote.
> 
> No, from a C perspective "A string is a contiguous sequence of
> characters terminated by and including the first null character."

Do I need the chr(0) at the end?

> 
> What you're describing is a pointer to a string (which is what is
> typically passed to functions).
> 

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

#70769

On Sun, 2019-12-29, T wrote:
> On 2019-12-29 01:45, Keith Thompson wrote:
>> Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
>> [...]
>>>  From a C perspective, a string is a pointer to the first char in a
>>> sequence, and the string ends with a char 0 marker.  That's probably
>>> the one your Windows API wants, if it's a C API like someone wrote.
>> 
>> No, from a C perspective "A string is a contiguous sequence of
>> characters terminated by and including the first null character."
>
> Do I need the chr(0) at the end?

Didn't we both just say so?

Yes. Assuming the API function you're calling really expects a C
string.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#70788

T <T@invalid.invalid> writes:
> On 2019-12-29 01:45, Keith Thompson wrote:
>> Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
>> [...]
>>>  From a C perspective, a string is a pointer to the first char in a
>>> sequence, and the string ends with a char 0 marker.  That's probably
>>> the one your Windows API wants, if it's a C API like someone wrote.
>>
>> No, from a C perspective "A string is a contiguous sequence of
>> characters terminated by and including the first null character."
>
> Do I need the chr(0) at the end?

I presume that by "chr(0)" you mean the char value '\0', also known as
the null character.  Your meaning is reasonably clear, but there is no
"chr" function in C or C++.

Yes, by definition a "string" includes the terminating null character.
If there's no null character, it's not a string.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
    [Note updated email address]
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

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

#70791

On 2019-12-29 13:57, Keith Thompson wrote:
> I presume that by "chr(0)" you mean the char value '\0', also known as
> the null character.  Your meaning is reasonably clear, but there is no
> "chr" function in C or C++.
> 
> Yes, by definition a "string" includes the terminating null character.
> If there's no null character, it's not a string.

It soaked in.  Thank you!

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

#70762

On 2019-12-29 01:33, Jorgen Grahn wrote:
> You have "C++ string" in the subject line, but this question seems to
> be as offtopic as the other recent ones from you.  I don't see how to
> help you with this problem, from a comp.lang.c++ point of view.

What I need to know is the construction of a C++ string

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

#70770

On Sun, 2019-12-29, T wrote:
> On 2019-12-29 01:33, Jorgen Grahn wrote:
>> You have "C++ string" in the subject line, but this question seems to
>> be as offtopic as the other recent ones from you.  I don't see how to
>> help you with this problem, from a comp.lang.c++ point of view.
>
> What I need to know is the construction of a C++ string

Fine, here it is:

https://en.cppreference.com/w/cpp/string/basic_string/basic_string

Imagine the Allocator stuff isn't there and mentally replace CharT
with char, and you have your normal std::string.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#70780

On 2019-12-29 03:08, Jorgen Grahn wrote:
> On Sun, 2019-12-29, T wrote:
>> On 2019-12-29 01:33, Jorgen Grahn wrote:
>>> You have "C++ string" in the subject line, but this question seems to
>>> be as offtopic as the other recent ones from you.  I don't see how to
>>> help you with this problem, from a comp.lang.c++ point of view.
>>
>> What I need to know is the construction of a C++ string
> 
> Fine, here it is:
> 
> https://en.cppreference.com/w/cpp/string/basic_string/basic_string
> 
> Imagine the Allocator stuff isn't there and mentally replace CharT
> with char, and you have your normal std::string.
> 
> /Jorgen
> 

Hi Jorgen,

I figured out through experimentation that Native Call
automatically add 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.

Thank you all for all the wonderful help!

-T

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

#70789

T <T@invalid.invalid> writes:
[...]
> I figured out through experimentation that Native Call
> automatically add 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.
>
> Thank you all for all the wonderful help!

You're talking about Raku/Perl6, right?

Things you find out through experimentation aren't always reliable.
It's possible that the Raku native call interface (which I haven't
looked at) doesn't distinguish between a numerical zero and a null
pointer.  If that's the case, it could work with any C++ implementation
that represents a null pointer as all-bits-zero.  That's likely to be
all existing C++ implementations, or at least all C++ implementations
that Raku might interface with.  It's not guaranteed by the C++
standard, though.  A literal 0 is a *null pointer constant*, but that
doesn't imply that a *null pointer* is represented as all-bits-zero.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
    [Note updated email address]
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

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

#70792

On 2019-12-29 13:57, Keith Thompson wrote:
> T <T@invalid.invalid> writes:
> [...]
>> I figured out through experimentation that Native Call
>> automatically add 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.
>>
>> Thank you all for all the wonderful help!
> 
> You're talking about Raku/Perl6, right?

Yes.  Once I understood what was going on in C++,
I was able to get my code working.

> Things you find out through experimentation aren't always reliable.
> It's possible that the Raku native call interface (which I haven't
> looked at) doesn't distinguish between a numerical zero and a null
> pointer.  If that's the case, it could work with any C++ implementation
> that represents a null pointer as all-bits-zero.  That's likely to be
> all existing C++ implementations, or at least all C++ implementations
> that Raku might interface with.  It's not guaranteed by the C++
> standard, though.  A literal 0 is a *null pointer constant*, but that
> doesn't imply that a *null pointer* is represented as all-bits-zero.

The Raku Native Call documentation is so, so bad
your only choice is experimentation.

NULL was a nightmare for me to figure out.  Once I did,
it was so simple it made my head spin

That you again for the wonder teaching!
-T

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

#70790

T <T@invalid.invalid> writes:
> On 2019-12-29 01:33, Jorgen Grahn wrote:
>> You have "C++ string" in the subject line, but this question seems to
>> be as offtopic as the other recent ones from you.  I don't see how to
>> help you with this problem, from a comp.lang.c++ point of view.
>
> What I need to know is the construction of a C++ string

What exactly do you mean by a "C++ string"?  Are you asking about the
std::string class defined in the <string> header?

If so, what about the construction of a std::string object are you
asking about?  Most of the internal details are unspecified.

C++ also has C-style strings, referred to in the standard as
"null-terminated byte strings" (and often referred to as "C-strings"
or something similar).

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
    [Note updated email address]
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

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

#70793

On 2019-12-29 13:57, Keith Thompson wrote:
> T <T@invalid.invalid> writes:
>> On 2019-12-29 01:33, Jorgen Grahn wrote:
>>> You have "C++ string" in the subject line, but this question seems to
>>> be as offtopic as the other recent ones from you.  I don't see how to
>>> help you with this problem, from a comp.lang.c++ point of view.
>>
>> What I need to know is the construction of a C++ string
> 
> What exactly do you mean by a "C++ string"?  Are you asking about the
> std::string class defined in the <string> header?
> 
> If so, what about the construction of a std::string object are you
> asking about?  Most of the internal details are unspecified.
> 
> C++ also has C-style strings, referred to in the standard as
> "null-terminated byte strings" (and often referred to as "C-strings"
> or something similar).
> 

Hi Keith,

I figured it out.

Native call is converting to C anyway.  This is from my
Navice Call notes:

3) a “C” string is an array of characters terminated with chr(0)

4) Kernel32.dll calls with a “W” in them use UTF16 `uint16` values
    in their strings.  The rest you can use UTF8 `uint8`.  Most of
    the time they are interchangeable if you are using standard
    characters.

    Use the following to convert a Raku strings, `abcdefg` below,
    into a “C” string

       UTF8:  my $L =  CArray[uint8].new("abcdefg".encode.list);
       UTF16: my $M = CArray[uint16].new("abcdefg".encode.list);

    Native Call is tack the chr(0) at the end for you.



Thank you again for all the wonderful teaching!

-T

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

#70794

On 30.12.2019 1:02, T wrote:

> 4) Kernel32.dll calls with a “W” in them use UTF16 `uint16` values
>     in their strings.  The rest you can use UTF8 `uint8`.  Most of
>     the time they are interchangeable if you are using standard
>     characters.

UTF-8 and UTF-16 can represent the exact same set of characters - the 
whole Unicode repertoire.

Alas, Windows kernel32.dll SDK functions ending with "A" do NOT use 
UTF-8 (unless you have a very new Windows 10 build and have managed to 
set your process code page to UTF-8; see 
"https://docs.microsoft.com/en-us/windows/uwp/design/globalizing/use-utf8-code-page").

Of course, if ASCII is all what matters to you there would be no 
difference. Note however this might change the moment the important 
customer insists of his spelling of "naïve" or "coöperative".

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

#70797

[Multipart message — attachments visible in raw view] — view raw

T writes:

> On 2019-12-29 01:33, Jorgen Grahn wrote:
>> You have "C++ string" in the subject line, but this question seems to
>> be as offtopic as the other recent ones from you.  I don't see how to
>> help you with this problem, from a comp.lang.c++ point of view.
>
> What I need to know is the construction of a C++ string

Open your C++ book to the part that explain how to use the "std::string"  
class, and read it.

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

#70763

On 2019-12-29 at 07: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.  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?
> 
> 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?
> 

A C string is always null-terminated, that is what *makes* it a string. 
Without the terminator it is an array of chars, which is something 
different.

The C language string-functions use the null to find the end of the 
string. For example, strlen:

"Returns the length of the given null-terminated byte string, that is, 
the number of characters in a character array whose first element is 
pointed to by str up to and not including the first null character.

The behavior is undefined if str is not a pointer to a null-terminated 
byte string."

https://en.cppreference.com/w/c/string/byte/strlen


     Bo Persson

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

#70766

On 2019-12-29 02:00, Bo Persson wrote:
> On 2019-12-29 at 07: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.  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?
>>
>> 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?
>>
> 
> A C string is always null-terminated, that is what *makes* it a string. 
> Without the terminator it is an array of chars, which is something 
> different.
> 
> The C language string-functions use the null to find the end of the 
> string. For example, strlen:
> 
> "Returns the length of the given null-terminated byte string, that is, 
> the number of characters in a character array whose first element is 
> pointed to by str up to and not including the first null character.
> 
> The behavior is undefined if str is not a pointer to a null-terminated 
> byte string."
> 
> https://en.cppreference.com/w/c/string/byte/strlen
> 
> 
>      Bo Persson

Thank you.  Exactly the same as Modula2.

Is it the same for C++?

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

#70772

On 29/12/2019 10:33, T wrote:
> On 2019-12-29 02:00, Bo Persson wrote:
>> On 2019-12-29 at 07: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.  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?
>>>
>>> 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?
>>>
>>
>> A C string is always null-terminated, that is what *makes* it a 
>> string. Without the terminator it is an array of chars, which is 
>> something different.
>>
>> The C language string-functions use the null to find the end of the 
>> string. For example, strlen:
>>
>> "Returns the length of the given null-terminated byte string, that is, 
>> the number of characters in a character array whose first element is 
>> pointed to by str up to and not including the first null character.
>>
>> The behavior is undefined if str is not a pointer to a null-terminated 
>> byte string."
>>
>> https://en.cppreference.com/w/c/string/byte/strlen
>>
>>
>>      Bo Persson
> 
> Thank you.  Exactly the same as Modula2.
> 
> Is it the same for C++?
> 

These are the msdn ('msdn messagebox') docs for MessageBox:

   int MessageBox(
     HWND    hWnd,
     LPCTSTR lpText,
     LPCTSTR lpCaption,
     UINT    uType
   );

This is in a panel labelled 'C++', but has been around since it used to 
be C. Looking at those string types here:

   https://docs.microsoft.com/en-us/windows/win32/winprog/windows-data-types

LCPCSTR ends up (if you follow the chain of typedefs) as either a type 
that points to sequence to 8-bit bytes, terminated by a 0 byte, or a 
sequence of 16-bit words, terminated by a 0 word.

This latter depends on whether the macro UNICODE is defined inside 
windows.h. It will call MessageBoxW if defined, and MessageBoxA if not.
This is rather interesting, since when calling from another language, 
windows.h doesn't exist, so there is no such macro.

In fact, there is no actual function called "MessageBox", that's just an 
artefact of windows.h.

Now, when I call MessageBox from my own non-C code, I directly call 
MessageBoxA with normal 8-bit zero-terminated strings. I assume the 
declaration of this function is as follows:

    int MessageBoxA(
       int hWnd,
       char* Text,
       char* Caption,
       unsigned int Type
    );

(I don't even use 'const char*', as 'const' is an artefact of the C 
language; it has no meaning at the binary level. Here 'int' is assumed 
to be 32 bits.)

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

#70781

On 2019-12-29 04:09, Bart wrote:
> On 29/12/2019 10:33, T wrote:
>> On 2019-12-29 02:00, Bo Persson wrote:
>>> On 2019-12-29 at 07: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.  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?
>>>>
>>>> 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?
>>>>
>>>
>>> A C string is always null-terminated, that is what *makes* it a 
>>> string. Without the terminator it is an array of chars, which is 
>>> something different.
>>>
>>> The C language string-functions use the null to find the end of the 
>>> string. For example, strlen:
>>>
>>> "Returns the length of the given null-terminated byte string, that 
>>> is, the number of characters in a character array whose first element 
>>> is pointed to by str up to and not including the first null character.
>>>
>>> The behavior is undefined if str is not a pointer to a 
>>> null-terminated byte string."
>>>
>>> https://en.cppreference.com/w/c/string/byte/strlen
>>>
>>>
>>>      Bo Persson
>>
>> Thank you.  Exactly the same as Modula2.
>>
>> Is it the same for C++?
>>
> 
> These are the msdn ('msdn messagebox') docs for MessageBox:
> 
>    int MessageBox(
>      HWND    hWnd,
>      LPCTSTR lpText,
>      LPCTSTR lpCaption,
>      UINT    uType
>    );
> 
> This is in a panel labelled 'C++', but has been around since it used to 
> be C. Looking at those string types here:
> 
>    
> https://docs.microsoft.com/en-us/windows/win32/winprog/windows-data-types
> 
> LCPCSTR ends up (if you follow the chain of typedefs) as either a type 
> that points to sequence to 8-bit bytes, terminated by a 0 byte, or a 
> sequence of 16-bit words, terminated by a 0 word.
> 
> This latter depends on whether the macro UNICODE is defined inside 
> windows.h. It will call MessageBoxW if defined, and MessageBoxA if not.
> This is rather interesting, since when calling from another language, 
> windows.h doesn't exist, so there is no such macro.
> 
> In fact, there is no actual function called "MessageBox", that's just an 
> artefact of windows.h.
> 
> Now, when I call MessageBox from my own non-C code, I directly call 
> MessageBoxA with normal 8-bit zero-terminated strings. I assume the 
> declaration of this function is as follows:
> 
>     int MessageBoxA(
>        int hWnd,
>        char* Text,
>        char* Caption,
>        unsigned int Type
>     );
> 
> (I don't even use 'const char*', as 'const' is an artefact of the C 
> language; it has no meaning at the binary level. Here 'int' is assumed 
> to be 32 bits.)

Hi Bart,

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.

Thank you all for all the wonderful help!

-T

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web