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


Groups > comp.lang.c++ > #70781

Re: Question on a C++ string

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>

Show all headers | View raw


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


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