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

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

C++ variable names

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

Contents

  C++ variable names T <T@invalid.invalid> - 2020-01-15 18:31 -0800
    Re: C++ variable names Daniel <danielaparker@gmail.com> - 2020-01-15 18:42 -0800
      Re: C++ variable names T <T@invalid.invalid> - 2020-01-15 18:46 -0800
        Re: C++ variable names Daniel <danielaparker@gmail.com> - 2020-01-15 21:30 -0800
          Re: C++ variable names T <T@invalid.invalid> - 2020-01-15 21:52 -0800
        Re: C++ variable names Louis Krupp <lkrupp@nospam.pssw.com.invalid> - 2020-01-15 23:44 -0700
          Re: C++ variable names T <T@invalid.invalid> - 2020-01-15 22:59 -0800
            Re: C++ variable names Bo Persson <bo@bo-persson.se> - 2020-01-16 08:44 +0100
              Re: C++ variable names T <T@invalid.invalid> - 2020-01-15 23:48 -0800
              Re: C++ variable names David Brown <david.brown@hesbynett.no> - 2020-01-16 10:08 +0100
            Re: C++ variable names Louis Krupp <lkrupp@nospam.pssw.com.invalid> - 2020-01-16 00:43 -0700
              Re: C++ variable names T <T@invalid.invalid> - 2020-01-15 23:51 -0800
                Re: C++ variable names Louis Krupp <lkrupp@nospam.pssw.com.invalid> - 2020-01-16 01:39 -0700
                  Re: C++ variable names T <T@invalid.invalid> - 2020-01-16 14:01 -0800
      Re: C++ variable names Lynn McGuire <lynnmcguire5@gmail.com> - 2020-01-16 15:48 -0600
        Re: C++ variable names Öö Tiib <ootiib@hot.ee> - 2020-01-16 14:11 -0800
          Re: C++ variable names Lynn McGuire <lynnmcguire5@gmail.com> - 2020-01-17 18:52 -0600
          Re: C++ variable names Manfred <noname@add.invalid> - 2020-01-18 16:22 +0100
            Re: C++ variable names Öö Tiib <ootiib@hot.ee> - 2020-01-18 10:41 -0800
            Re: C++ variable names Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-21 05:31 -0800
        Re: C++ variable names David Brown <david.brown@hesbynett.no> - 2020-01-16 23:32 +0100
        Re: C++ variable names legalize+jeeves@mail.xmission.com (Richard) - 2020-01-19 19:13 +0000
    Re: C++ variable names red floyd <no.spam@its.invalid> - 2020-01-15 18:45 -0800
      Re: C++ variable names T <T@invalid.invalid> - 2020-01-15 18:47 -0800
      Re: C++ variable names Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-15 21:51 -0800
        Re: C++ variable names red floyd <no.spam@its.invalid> - 2020-01-15 22:44 -0800
          Re: C++ variable names T <T@invalid.invalid> - 2020-01-15 23:00 -0800
    Re: C++ variable names "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-15 19:40 -0800
      Re: C++ variable names T <T@invalid.invalid> - 2020-01-15 19:58 -0800
        Re: C++ variable names "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-15 20:12 -0800
      Re: C++ variable names James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-15 23:18 -0500
        Re: C++ variable names T <T@invalid.invalid> - 2020-01-15 20:20 -0800
          Re: C++ variable names James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-16 12:06 -0800
            Re: C++ variable names T <T@invalid.invalid> - 2020-01-16 14:02 -0800
        Re: C++ variable names "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-15 20:31 -0800
          Re: C++ variable names David Brown <david.brown@hesbynett.no> - 2020-01-16 11:09 +0100
    Re: C++ variable names Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-16 03:52 +0000
      Re: C++ variable names T <T@invalid.invalid> - 2020-01-15 19:59 -0800
        Re: C++ variable names Bo Persson <bo@bo-persson.se> - 2020-01-16 06:33 +0100
          Re: C++ variable names T <T@invalid.invalid> - 2020-01-15 21:53 -0800
    Re: C++ variable names Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-16 06:18 +0100
      Re: C++ variable names T <T@invalid.invalid> - 2020-01-15 21:54 -0800
        Re: C++ variable names Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-16 06:59 +0100
          Re: C++ variable names T <T@invalid.invalid> - 2020-01-15 22:31 -0800
            Re: C++ variable names Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-16 00:15 -0800
            Re: C++ variable names Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-16 11:25 +0100
              Re: C++ variable names Mister2U@honorific.org - 2020-01-16 11:47 +0000
                Re: C++ variable names Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-16 13:31 +0100
                  Re: C++ variable names "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-16 15:51 -0800
                    Re: C++ variable names "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-16 15:51 -0800
                    Re: C++ variable names Manfred <invalid@add.invalid> - 2020-01-17 01:31 +0100
    Re: C++ variable names Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-15 21:48 -0800
      Re: C++ variable names T <T@invalid.invalid> - 2020-01-15 21:55 -0800
        Re: C++ variable names Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-16 00:01 -0800
      Re: C++ variable names "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-15 22:28 -0800
        Re: C++ variable names T <T@invalid.invalid> - 2020-01-15 22:31 -0800
    Re: C++ variable names "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-15 23:16 -0800
      Re: C++ variable names T <T@invalid.invalid> - 2020-01-15 23:26 -0800
        Re: C++ variable names "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-15 23:34 -0800
          Re: C++ variable names T <T@invalid.invalid> - 2020-01-15 23:53 -0800
            Re: C++ variable names Louis Krupp <lkrupp@nospam.pssw.com.invalid> - 2020-01-16 03:04 -0700
    C++ variable names James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-16 11:51 -0800
      Re: C++ variable names T <T@invalid.invalid> - 2020-01-16 13:58 -0800

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#71382

> Would some kind individual please fill in
> the C++ variables names that go with these
> C variable names?
> int8_t in C
> int16_t in C
> int32_t in C
> int64_t in C
> uint8_t in C
> uint16_t in C
> uint32_t in C
> uint64_t in C
> float in C

That are all no variable-names but type-names ! Hrhr. ;-)

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

#71389

On 2020-01-15 21:18, Bonita Montero wrote:
>> Would some kind individual please fill in
>> the C++ variables names that go with these
>> C variable names?
>> int8_t in C
>> int16_t in C
>> int32_t in C
>> int64_t in C
>> uint8_t in C
>> uint16_t in C
>> uint32_t in C
>> uint64_t in C
>> float in C
> 
> That are all no variable-names but type-names ! Hrhr. ;-)

oops.  I meant type names.

:'(

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

#71391

>>> Would some kind individual please fill in
>>> the C++ variables names that go with these
>>> C variable names?
>>> int8_t in C
>>> int16_t in C
>>> int32_t in C
>>> int64_t in C
>>> uint8_t in C
>>> uint16_t in C
>>> uint32_t in C
>>> uint64_t in C
>>> float in C

>> That are all no variable-names but type-names ! Hrhr. ;-)

> oops.  I meant type names.

Ok, except float all types are preceded with "std::" in C++.
float has the same typename.

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

#71393

On 2020-01-15 21:59, Bonita Montero wrote:
>>>> Would some kind individual please fill in
>>>> the C++ variables names that go with these
>>>> C variable names?
>>>> int8_t in C
>>>> int16_t in C
>>>> int32_t in C
>>>> int64_t in C
>>>> uint8_t in C
>>>> uint16_t in C
>>>> uint32_t in C
>>>> uint64_t in C
>>>> float in C
> 
>>> That are all no variable-names but type-names ! Hrhr. ;-)
> 
>> oops.  I meant type names.
> 
> Ok, except float all types are preceded with "std::" in C++.
> float has the same typename.
> 

Thank you!

This got it?

C           C++
float_t     std::float_t
double_t    std::double_t

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

#71410

T <T@invalid.invalid> writes:
[...]
> This got it?
>
> C           C++
> float_t     std::float_t
> double_t    std::double_t

float_t and double_t are fairly obscure types defined in <math.h>
in C, and in <cmath> or <math.h> in C++.  float_t is at least as
wide as float, and might be wider and faster; similarly for double_t.
(For example, float_t might be defined as double if double operations
are faster than float operations.)  See the C standard (I think
you have N1570) section 7.12.  I don't know that there would be
any reason to refer to them in Raku.

The predefined floating-point types in both C and C++ are float,
double, and long double.

I'm really not sure what this whole discussion is about.  The types
in the standard library have names defined by the standard library
as specified in the language standard.  You just use those names.
It doesn't make sense to talk about changing them.

If you weren't aware, most of the C standard library headers
are incorporated into the C++ standard library.  Each <foo.h>
C header is available in C++ as <cfoo>, with the declarations in
the std:: namespace.  With very few exceptions, they're the same.
Any decent C++ reference should explain all this.

No offense, but I get the feeling that you have some fundamental
misconception that led you to think that, for example, referring to
int32_t as int32 might make some kind of sense.

Hopefully this means you won't have to post a new question about
size_t and ptrdiff_t, since the answers will be exactly the same.

-- 
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]

#71415

> Thank you!
> This got it?
> C           C++
> float_t     std::float_t
> double_t    std::double_t

In another post in the Win32-newsgroup you said that you don't need to
learn C for your talss. Now you want to know how cerain types are mapped
from C to C++. That's even beyond C. I think you should get a copy of
"The C Programming Language" and learn C. C is a simple language which
someone can learn in a week. Just google for
    "The C Programming language" doctype:pdf
to find an older copy of the book. That's not up to date but there were
no revolutionary changes with C like in C++.

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

#71416

On Thu, 16 Jan 2020 11:25:45 +0100
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Thank you!
>> This got it?
>> C           C++
>> float_t     std::float_t
>> double_t    std::double_t
>
>In another post in the Win32-newsgroup you said that you don't need to
>learn C for your talss. Now you want to know how cerain types are mapped
>from C to C++. That's even beyond C. I think you should get a copy of
>"The C Programming Language" and learn C. C is a simple language which
>someone can learn in a week. Just google for

Someone familiar with programming can learn most of it in a week - but good 
luck getting them to understand pointer arithmetic and double/triple 
indirection and the relationship between pointers and arrays properly in that 
time however. The latter still trips up even seasoned C programmers occasionally
and yes, I am speaking from experience :)

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

#71417

> Someone familiar with programming can learn most of it in a week - but
> good luck getting them to understand pointer arithmetic and double/triple
> indirection and the relationship between pointers and arrays properly in
> that time however. ...

My first language was BASIC on my Sinclair ZX Spectrum, then GFA Basic
on my Atari ST. Then I learned Borland C on my Atari ST in a week with
all that topics in a week. And I was 14 then and if somesone so young
can learn C in a weel so comprehensive, a mature person can manage it
at least as good.

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

#71433

On 1/16/2020 4:31 AM, Bonita Montero wrote:
>> Someone familiar with programming can learn most of it in a week - but
>> good luck getting them to understand pointer arithmetic and double/triple
>> indirection and the relationship between pointers and arrays properly in
>> that time however. ...
> 
> My first language was BASIC on my Sinclair ZX Spectrum, then GFA Basic
> on my Atari ST. 

I learned BASIC first as well, back in 1984-85, was born in late 1977. 
Using the cartridge in my Atari 800XL. I was thinking, what the hell is 
BASIC!? I was a little kid. Then on Christmas, I received a spiral bound 
book that thought me the language. LOGO was fun as well.


Then I learned Borland C on my Atari ST in a week with
> all that topics in a week. And I was 14 then and if somesone so young
> can learn C in a weel so comprehensive, a mature person can manage it
> at least as good.
> 

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

#71434

On 1/16/2020 3:51 PM, Chris M. Thomasson wrote:
> On 1/16/2020 4:31 AM, Bonita Montero wrote:
>>> Someone familiar with programming can learn most of it in a week - but
>>> good luck getting them to understand pointer arithmetic and 
>>> double/triple
>>> indirection and the relationship between pointers and arrays properly in
>>> that time however. ...
>>
>> My first language was BASIC on my Sinclair ZX Spectrum, then GFA Basic
>> on my Atari ST. 
> 
> I learned BASIC first as well, back in 1984-85, was born in late 1977. 
> Using the cartridge in my Atari 800XL. I was thinking, what the hell is 
> BASIC!? I was a little kid. Then on Christmas, I received a spiral bound 
> book that thought me the language. LOGO was fun as well.

PILOT was really fun as well.

> 
> 
> Then I learned Borland C on my Atari ST in a week with
>> all that topics in a week. And I was 14 then and if somesone so young
>> can learn C in a weel so comprehensive, a mature person can manage it
>> at least as good.
>>
> 

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

#71436

On 1/17/20 12:51 AM, Chris M. Thomasson wrote:
> was born in late 1977. Using the cartridge in my Atari 800XL.

The Matrix is around us all.

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

#71385

T <T@invalid.invalid> writes:
> Sorry for the homework assignment.
>
> Would some kind individual please fill in
> the C++ variables names that go with these
> C variable names?
>
> int8_t in C
> int16_t in C
> int32_t in C
> int64_t in C
> uint8_t in C
> uint16_t in C
> uint32_t in C
> uint64_t in C
> float in C
>
> Do I just drop the "_t"?

Those are type names. not variable names.  The [u]int*_t names
are defined in the C standard header <stdint.h>, imported into
C++ as <cstdint>.  float is a reserved word and the name of a
floating-point type.

They're all exactly the same in C and in C++ (except that the *_t
type names might be in the std:: namespace in C++).

The "_t" suffix is simply part of the name.  I don't know why
you'd want to drop it.  (It's a convention indicating that it's a
type name, but it's not a convention that's universally followed.)
As mentioned later in the thread, POSIX reserves _t suffixes for some
purposes, but since POSIX is based on C and all these identifiers
are defined by the C standard, there is no conflict.

For example, dropping the "_t" from int8_t would give you int8, which is
not defined anywhere in C or C++.  You can certainly define something
called "int8" if you like, just as you can define something called
"foo42" if you like.

Since you mentioned "variables", it's possible that you're asking
for good names for variables of these types.  If so, each variable
should have a name that reflects the meaning of that variable.

It's possible that I've misunderstood what you're asking.

-- 
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]

#71390

On 2020-01-15 21:48, Keith Thompson wrote:
> T <T@invalid.invalid> writes:
>> Sorry for the homework assignment.
>>
>> Would some kind individual please fill in
>> the C++ variables names that go with these
>> C variable names?
>>
>> int8_t in C
>> int16_t in C
>> int32_t in C
>> int64_t in C
>> uint8_t in C
>> uint16_t in C
>> uint32_t in C
>> uint64_t in C
>> float in C
>>
>> Do I just drop the "_t"?
> 
> Those are type names. not variable names.  The [u]int*_t names
> are defined in the C standard header <stdint.h>, imported into
> C++ as <cstdint>.  float is a reserved word and the name of a
> floating-point type.
> 
> They're all exactly the same in C and in C++ (except that the *_t
> type names might be in the std:: namespace in C++).
> 
> The "_t" suffix is simply part of the name.  I don't know why
> you'd want to drop it.  (It's a convention indicating that it's a
> type name, but it's not a convention that's universally followed.)
> As mentioned later in the thread, POSIX reserves _t suffixes for some
> purposes, but since POSIX is based on C and all these identifiers
> are defined by the C standard, there is no conflict.
> 
> For example, dropping the "_t" from int8_t would give you int8, which is
> not defined anywhere in C or C++.  You can certainly define something
> called "int8" if you like, just as you can define something called
> "foo42" if you like.
> 
> Since you mentioned "variables", it's possible that you're asking
> for good names for variables of these types.  If so, each variable
> should have a name that reflects the meaning of that variable.
> 
> It's possible that I've misunderstood what you're asking.
> 

You hit it perfectly.  Thank you!

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

#71408

T <T@invalid.invalid> writes:
> On 2020-01-15 21:48, Keith Thompson wrote:
[45 lines deleted]
>
> You hit it perfectly.  Thank you!

You don't need to post multiple responses just to say "Thank you",
and if you do, you don't need to quote the entire parent article.
I appreciate the sentiment (and you're welcome), and in this
case letting me know that I had guessed correctly is valuable,
but multiple long posts are a lot to read through.

In the case of a long thread, a single reply thanking everyone is
more than sufficient.

-- 
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]

#71392

On 1/15/2020 9:48 PM, Keith Thompson wrote:
> T <T@invalid.invalid> writes:
>> Sorry for the homework assignment.
[...]
> The "_t" suffix is simply part of the name.  I don't know why
> you'd want to drop it.  (It's a convention indicating that it's a
> type name, but it's not a convention that's universally followed.)
> As mentioned later in the thread, POSIX reserves _t suffixes for some
> purposes, but since POSIX is based on C and all these identifiers
> are defined by the C standard, there is no conflict.
> 
> For example, dropping the "_t" from int8_t would give you int8, which is
> not defined anywhere in C or C++.  You can certainly define something
> called "int8" if you like, just as you can define something called
> "foo42" if you like.

Oh yes. We need the to use *_t when we need to use a standard type that 
has that suffix. We must use the right name. However, perhaps this is to 
dated, I was advised to stay away from adding _t to any new type I 
create. Therefore:

struct foo_t
{
    int bad;
};

struct foo
{
    int better;
};

I got into the habit. Especially typedefs and/or macros. No *_t when 
working with POSIX. using a std type, no problem. However, do not create 
a new type with *_t, damn it.

[...]

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

#71394

On 2020-01-15 22:28, Chris M. Thomasson wrote:
> On 1/15/2020 9:48 PM, Keith Thompson wrote:
>> T <T@invalid.invalid> writes:
>>> Sorry for the homework assignment.
> [...]
>> The "_t" suffix is simply part of the name.  I don't know why
>> you'd want to drop it.  (It's a convention indicating that it's a
>> type name, but it's not a convention that's universally followed.)
>> As mentioned later in the thread, POSIX reserves _t suffixes for some
>> purposes, but since POSIX is based on C and all these identifiers
>> are defined by the C standard, there is no conflict.
>>
>> For example, dropping the "_t" from int8_t would give you int8, which is
>> not defined anywhere in C or C++.  You can certainly define something
>> called "int8" if you like, just as you can define something called
>> "foo42" if you like.
> 
> Oh yes. We need the to use *_t when we need to use a standard type that 
> has that suffix. We must use the right name. However, perhaps this is to 
> dated, I was advised to stay away from adding _t to any new type I 
> create. Therefore:
> 
> struct foo_t
> {
>     int bad;
> };
> 
> struct foo
> {
>     int better;
> };
> 
> I got into the habit. Especially typedefs and/or macros. No *_t when 
> working with POSIX. using a std type, no problem. However, do not create 
> a new type with *_t, damn it.
> 
> [...]
> 

Thank you!

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

#71400

On 1/15/2020 6:31 PM, T wrote:
> Hi All,
> 
> Sorry for the homework assignment.
> 
> Would some kind individual please fill in
> the C++ variables names that go with these
> C variable names?
> 
> int8_t in C
> int16_t in C
> int32_t in C
> int64_t in C
> uint8_t in C
> uint16_t in C
> uint32_t in C
> uint64_t in C
> float in C
> 
> Do I just drop the "_t"?
> 
> Many thanks,
> -T


When creating a new type at this early stage is your learning process, 
use hyper-verbose names for things to get a feel. Try to name your types 
something nice and descriptive:

No struct rs, or struct r. Something more on par with:

struct room_settings
{
    int some_setting_ambient_light_0;
    int some_setting_1;
};

struct room
{
     struct room_settings settings;
};

Actually, think of programming a little text adventure game. Its great 
fun! Try to beat Beyond Zork... ;^)

Create a 5 room puzzle, with encounters, and all sorts of fun stuff.

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

#71401

On 2020-01-15 23:16, Chris M. Thomasson wrote:
> On 1/15/2020 6:31 PM, T wrote:
>> Hi All,
>>
>> Sorry for the homework assignment.
>>
>> Would some kind individual please fill in
>> the C++ variables names that go with these
>> C variable names?
>>
>> int8_t in C
>> int16_t in C
>> int32_t in C
>> int64_t in C
>> uint8_t in C
>> uint16_t in C
>> uint32_t in C
>> uint64_t in C
>> float in C
>>
>> Do I just drop the "_t"?
>>
>> Many thanks,
>> -T
> 
> 
> When creating a new type at this early stage is your learning process, 
> use hyper-verbose names for things to get a feel. Try to name your types 
> something nice and descriptive:
> 
> No struct rs, or struct r. Something more on par with:
> 
> struct room_settings
> {
>     int some_setting_ambient_light_0;
>     int some_setting_1;
> };
> 
> struct room
> {
>      struct room_settings settings;
> };
> 
> Actually, think of programming a little text adventure game. Its great 
> fun! Try to beat Beyond Zork... ;^)
> 
> Create a 5 room puzzle, with encounters, and all sorts of fun stuff.

Huh?  I just want the equivalent C++ name of some
C names for a paper I am writing for Raku's NativeCall

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

#71402

On 1/15/2020 11:26 PM, T wrote:
> On 2020-01-15 23:16, Chris M. Thomasson wrote:
>> On 1/15/2020 6:31 PM, T wrote:
>>> Hi All,
>>>
>>> Sorry for the homework assignment.
>>>
>>> Would some kind individual please fill in
>>> the C++ variables names that go with these
>>> C variable names?
>>>
>>> int8_t in C
>>> int16_t in C
>>> int32_t in C
>>> int64_t in C
>>> uint8_t in C
>>> uint16_t in C
>>> uint32_t in C
>>> uint64_t in C
>>> float in C
>>>
>>> Do I just drop the "_t"?
>>>
>>> Many thanks,
>>> -T
>>
>>
>> When creating a new type at this early stage is your learning process, 
>> use hyper-verbose names for things to get a feel. Try to name your 
>> types something nice and descriptive:
>>
>> No struct rs, or struct r. Something more on par with:
>>
>> struct room_settings
>> {
>>     int some_setting_ambient_light_0;
>>     int some_setting_1;
>> };
>>
>> struct room
>> {
>>      struct room_settings settings;
>> };
>>
>> Actually, think of programming a little text adventure game. Its great 
>> fun! Try to beat Beyond Zork... ;^)
>>
>> Create a 5 room puzzle, with encounters, and all sorts of fun stuff.
> 
> Huh?  I just want the equivalent C++ name of some
> C names for a paper I am writing for Raku's NativeCall

Oh shi%. Nevermind. For some reason, I thought you were learning C.

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

#71407

On 2020-01-15 23:34, Chris M. Thomasson wrote:
> On 1/15/2020 11:26 PM, T wrote:
>> On 2020-01-15 23:16, Chris M. Thomasson wrote:
>>> On 1/15/2020 6:31 PM, T wrote:
>>>> Hi All,
>>>>
>>>> Sorry for the homework assignment.
>>>>
>>>> Would some kind individual please fill in
>>>> the C++ variables names that go with these
>>>> C variable names?
>>>>
>>>> int8_t in C
>>>> int16_t in C
>>>> int32_t in C
>>>> int64_t in C
>>>> uint8_t in C
>>>> uint16_t in C
>>>> uint32_t in C
>>>> uint64_t in C
>>>> float in C
>>>>
>>>> Do I just drop the "_t"?
>>>>
>>>> Many thanks,
>>>> -T
>>>
>>>
>>> When creating a new type at this early stage is your learning 
>>> process, use hyper-verbose names for things to get a feel. Try to 
>>> name your types something nice and descriptive:
>>>
>>> No struct rs, or struct r. Something more on par with:
>>>
>>> struct room_settings
>>> {
>>>     int some_setting_ambient_light_0;
>>>     int some_setting_1;
>>> };
>>>
>>> struct room
>>> {
>>>      struct room_settings settings;
>>> };
>>>
>>> Actually, think of programming a little text adventure game. Its 
>>> great fun! Try to beat Beyond Zork... ;^)
>>>
>>> Create a 5 room puzzle, with encounters, and all sorts of fun stuff.
>>
>> Huh?  I just want the equivalent C++ name of some
>> C names for a paper I am writing for Raku's NativeCall
> 
> Oh shi%. Nevermind. For some reason, I thought you were learning C.
> 

Only as much as I need to run NativeCall.

C is for folks way smarter than me.  I don't
know how your guys do it without going insane.
My hat is off to you guys.

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

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

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

csiph-web