Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #70781
| From | T <T@invalid.invalid> |
|---|---|
| Newsgroups | comp.lang.c++ |
| Subject | Re: Question on a C++ string |
| Date | 2019-12-29 11:51 -0800 |
| Organization | A noiseless patient Spider |
| Message-ID | <qub04k$5t1$3@dont-email.me> (permalink) |
| References | <qu9hgc$nut$1@dont-email.me> <h6rbpeF9oi1U1@mid.individual.net> <qu9vdl$ibv$1@dont-email.me> <xH0OF.35843$Kj.20138@fx21.am4> |
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
Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
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
csiph-web