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 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#71431

On 16/01/2020 22:48, Lynn McGuire wrote:
> On 1/15/2020 8:42 PM, Daniel wrote:
>> On Wednesday, January 15, 2020 at 9:32:02 PM UTC-5, T wrote:
>>> Hi All,
>>>
>>> Would some kind individual please fill in
>>> the C++ variables names that go with these
>>> C variable names?
>>>
>>> int8_t in C
>>
>> ...
>>>
>>> Do I just drop the "_t"?
>>>
>> In general it's considered to be bad practice to adorn a variable name
>> with type information.
>>
>> Daniel
> 
> Huh ?  Don't tell that to Hungarian notation folks.
>     https://en.wikipedia.org/wiki/Hungarian_notation
> 

Did you read the link you posted?

The original idea of "Hungarian notation" is what Wikipedia labels "Apps 
Hungarian".  The variable naming prefix is about the way the variable 
should be used - like using "usName" for an "unsafe string" holding a 
name, and "ssName" for the "safe" version, after escaping to block SQL 
injection attacks and other unpleasantness.  The point is to give 
semantic information in addition to the name and the type, making it 
easier to spot mistakes.

What Wikipedia calls "Systems Hungarian", used regularly in the Windows 
world, was a misunderstanding of this that got out of hand, trying to 
use prefixes for the types of variables.  That might make a little sense 
in a language with no declaration of types, but is clearly absurd in a 
language where programs will have hundreds and thousands of types.

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

#71458

[Please do not mail me a copy of your followup]

Lynn McGuire <lynnmcguire5@gmail.com> spake the secret code
<qvqlni$ofi$2@dont-email.me> thusly:

>Huh ?  Don't tell that to Hungarian notation folks.
>    https://en.wikipedia.org/wiki/Hungarian_notation

It was always a bad idea.  Even MS has disavowed it at this point.
The C# coding style guidelines specifically tell you *not* to use
this.
-- 
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
            The Terminals Wiki <http://terminals-wiki.org>
     The Computer Graphics Museum <http://computergraphicsmuseum.org>
  Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

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

#71371

On 1/15/20 6:31 PM, T wrote:
> Hi All,
> 
> Sorry for the homework assignment.
> 
> <redacted>

Please see FAQ 5.2.   Do your own homework.

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

#71373

On 2020-01-15 18:45, red floyd wrote:
> On 1/15/20 6:31 PM, T wrote:
>> Hi All,
>>
>> Sorry for the homework assignment.
>>
>> <redacted>
> 
> Please see FAQ 5.2.   Do your own homework.
> 
> 

I have no idea where to find FAQ 5.2.  I am
completely at your mercy here.

Do you have a link for me?

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

#71386

red floyd <no.spam@its.invalid> writes:
> On 1/15/20 6:31 PM, T wrote:
>> Sorry for the homework assignment.
>>
>> <redacted>
>
> Please see FAQ 5.2.   Do your own homework.

I also don't know what you mean by "FAQ 5.2".  Question 5.2 in the
comp.lang.c FAQ <http://www.c-faq.com> is about null pointers and is
not relevant here.  The most current C++ FAQ <https://isocpp.org/faq>
doesn't number its questions.

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

#71396

On 1/15/20 9:51 PM, Keith Thompson wrote:
> red floyd <no.spam@its.invalid> writes:
>> On 1/15/20 6:31 PM, T wrote:
>>> Sorry for the homework assignment.
>>>
>>> <redacted>
>>
>> Please see FAQ 5.2.   Do your own homework.
> 
> I also don't know what you mean by "FAQ 5.2".  Question 5.2 in the
> comp.lang.c FAQ <http://www.c-faq.com> is about null pointers and is
> not relevant here.  The most current C++ FAQ <https://isocpp.org/faq>
> doesn't number its questions.
> 

I'm referring to the original C++ FAQ lite.

http://www.dietmar-kuehl.de/mirror/c++-faq/how-to-post.html#faq-5.2

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

#71399

On 2020-01-15 22:44, red floyd wrote:
> On 1/15/20 9:51 PM, Keith Thompson wrote:
>> red floyd <no.spam@its.invalid> writes:
>>> On 1/15/20 6:31 PM, T wrote:
>>>> Sorry for the homework assignment.
>>>>
>>>> <redacted>
>>>
>>> Please see FAQ 5.2.   Do your own homework.
>>
>> I also don't know what you mean by "FAQ 5.2".  Question 5.2 in the
>> comp.lang.c FAQ <http://www.c-faq.com> is about null pointers and is
>> not relevant here.  The most current C++ FAQ <https://isocpp.org/faq>
>> doesn't number its questions.
>>
> 
> I'm referring to the original C++ FAQ lite.
> 
> http://www.dietmar-kuehl.de/mirror/c++-faq/how-to-post.html#faq-5.2
> 


Very funny!

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

#71374

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"?
> 

Fwiw, *_t postfix conflicts with POSIX namespace.

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

#71376

On 2020-01-15 19:40, 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"?
>>
> 
> Fwiw, *_t postfix conflicts with POSIX namespace.
> 

Can I just drop them then?

And can you give me a reference to the POSIX namespace?
The folks I am dealing with won't take my word for it.

Are the names the same in C++ if I drop the _t?

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

#71378

On 1/15/2020 7:58 PM, T wrote:
> On 2020-01-15 19:40, 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"?
>>>
>>
>> Fwiw, *_t postfix conflicts with POSIX namespace.
>>
> 
> Can I just drop them then?

Take a deep look at:

http://www.cplusplus.com/reference/cstdint

When dealing with POSIX, the *_t can be an interesting thing indeed.

You need to use the correct type name to use any type.


> 
> And can you give me a reference to the POSIX namespace?

Take ptread_mutex_t:

https://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_mutex_lock.html

Well, the damn *_t is in the POSIX namespace. However, if not using 
POSIX, then this is mute.



> The folks I am dealing with won't take my word for it.
> 
> Are the names the same in C++ if I drop the _t?
> 

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

#71379

On 1/15/20 10:40 PM, 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"?
>>
> 
> Fwiw, *_t postfix conflicts with POSIX namespace.

POSIX reserves such postfixes for the purpose of identifying types.
These are types. POSIX mandates support for a compiler that conforms to
the C standard, so there is no such conflict.

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

#71380

On 2020-01-15 20:18, James Kuyper wrote:
> On 1/15/20 10:40 PM, 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"?
>>>
>>
>> Fwiw, *_t postfix conflicts with POSIX namespace.
> 
> POSIX reserves such postfixes for the purpose of identifying types.
> These are types. POSIX mandates support for a compiler that conforms to
> the C standard, so there is no such conflict.
> 

Any problem dropping the _t then?

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

#71423

T wrote:
> Any problem dropping the _t then?

Yes. It's the same problem that happens when you drop a
part of any other name. My name, for instance, is "James".
If you drop the 's', you get "Jame". The problem with
that? "Jame" isn't my name.
Similarly, if you drop the _t from int16_t, it's no longer
the name of a typedef declared in <stdint.h> for an
integer type with exactly 16 bits, 2's complement
representation, and no padding bits. Without the _t, it's
Just an identifier reserved for use by users, who might or
might not have already declared it as having some
particular meaning.

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

#71429

On 2020-01-16 12:06, James Kuyper wrote:
> T wrote:
>> Any problem dropping the _t then?
> 
> Yes. It's the same problem that happens when you drop a
> part of any other name. My name, for instance, is "James".
> If you drop the 's', you get "Jame". The problem with
> that? "Jame" isn't my name.
> Similarly, if you drop the _t from int16_t, it's no longer
> the name of a typedef declared in <stdint.h> for an
> integer type with exactly 16 bits, 2's complement
> representation, and no padding bits. Without the _t, it's
> Just an identifier reserved for use by users, who might or
> might not have already declared it as having some
> particular meaning.
> 

Got it!

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

#71381

On 1/15/2020 8:18 PM, James Kuyper wrote:
> On 1/15/20 10:40 PM, 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"?
>>>
>>
>> Fwiw, *_t postfix conflicts with POSIX namespace.
> 
> POSIX reserves such postfixes for the purpose of identifying types.

I was advised a long time ago to drop any *_t wrt keeping Kosher within 
the POSIX namespace.


> These are types. POSIX mandates support for a compiler that conforms to
> the C standard, so there is no such conflict.
> 

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

#71414

On 16/01/2020 05:31, Chris M. Thomasson wrote:
> On 1/15/2020 8:18 PM, James Kuyper wrote:
>> On 1/15/20 10:40 PM, 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"?
>>>>
>>>
>>> Fwiw, *_t postfix conflicts with POSIX namespace.
>>
>> POSIX reserves such postfixes for the purpose of identifying types.
> 
> I was advised a long time ago to drop any *_t wrt keeping Kosher within
> the POSIX namespace.
> 

I think there may be a bit of confusion here in what people mean by
"drop the _t".

When you define your own types, you are free to pick whatever names you
want - as long as you don't conflict with other standards or
requirements.  Unless you are writing POSIX code, you can freely use _t
names (except for those that conflict with the C or C++ standards).

But these types are /not/ personal types - they are defined in the C and
C++ standards.  You cannot "drop the _t".  They have defined names, and
you need to use those names if you use those types.

If you are not using C99 - perhaps because your compiler doesn't support
it - and you don't have <stdint.h> (many pre-C99 compilers have
<stdint.h>), then you should define these types yourself or use a
generic "stdint.h".  That way your code is understandable by all C
programmers, and portable to other compilers.  So you should still be
using the _t names.

> 
>> These are types. POSIX mandates support for a compiler that conforms to
>> the C standard, so there is no such conflict.
>>
> 

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

#71375

T <T@invalid.invalid> writes:

> 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"?

They have the same names in C++.  Depending on what header file you
include to get them, they may be in the std:: namespace, but the name
itself is the same.

-- 
Ben.

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

#71377

On 2020-01-15 19:52, Ben Bacarisse wrote:
> T <T@invalid.invalid> writes:
> 
>> 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"?
> 
> They have the same names in C++.  Depending on what header file you
> include to get them, they may be in the std:: namespace, but the name
> itself is the sam


Thank you!

Also, what is the _t and can I drop it?

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

#71384

On 2020-01-16 at 04:59, T wrote:
> On 2020-01-15 19:52, Ben Bacarisse wrote:
>> T <T@invalid.invalid> writes:
>>
>>> 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"?
>>
>> They have the same names in C++.  Depending on what header file you
>> include to get them, they may be in the std:: namespace, but the name
>> itself is the sam
> 
> 
> Thank you!
> 
> Also, what is the _t and can I drop it?
> 

There is no magic here.

An identifier can contain a-z, A-Z, 0-9, and underscores. A name like 
int64_t contains a combination of lowercase letters, digits, and 
underscore. Nothing special about that.



The _t is just a convention that (generally) indicates that the 
identifier is a typedef in the C library, like

typedef short   int16_t;
typedef unsigned int   uint32_t;



Variable names are also identifiers and have the same format as type 
names. You can just choose whatever name you want, like


int32_t   x;


or some better name than x, that tells us what the variable is supposed 
to be used for.

As the _t is used in some typedef-names, it is generally a good idea not 
to use it in other names.


    Bo Persson

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

#71388

On 2020-01-15 21:33, Bo Persson wrote:
> On 2020-01-16 at 04:59, T wrote:
>> On 2020-01-15 19:52, Ben Bacarisse wrote:
>>> T <T@invalid.invalid> writes:
>>>
>>>> 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"?
>>>
>>> They have the same names in C++.  Depending on what header file you
>>> include to get them, they may be in the std:: namespace, but the name
>>> itself is the sam
>>
>>
>> Thank you!
>>
>> Also, what is the _t and can I drop it?
>>
> 
> There is no magic here.
> 
> An identifier can contain a-z, A-Z, 0-9, and underscores. A name like 
> int64_t contains a combination of lowercase letters, digits, and 
> underscore. Nothing special about that.
> 
> 
> 
> The _t is just a convention that (generally) indicates that the 
> identifier is a typedef in the C library, like
> 
> typedef short   int16_t;
> typedef unsigned int   uint32_t;
> 
> 
> 
> Variable names are also identifiers and have the same format as type 
> names. You can just choose whatever name you want, like
> 
> 
> int32_t   x;
> 
> 
> or some better name than x, that tells us what the variable is supposed 
> to be used for.
> 
> As the _t is used in some typedef-names, it is generally a good idea not 
> to use it in other names.
> 
> 
>     Bo Persson

Hi Bo,

Thank you.  I will include the _t!

-T

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

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

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

csiph-web