473,225 Members | 1,318 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,225 software developers and data experts.

Types defined in std::

I am looking for some validation against a dubious coding practice
that prevails where I work. C types defined in types.h (Linux) or
stdint.h (Windows, C99?) are used as if they belong to the C++
standard namespace.

std::uint8_t instead of uint8_t
std::uint32_t instead of uint32_t
....

I don't think the use of std:: is correct. Nowhere are these types
explicitly added to the std namespace. In fact GCC 3.3 fails on them.
Neither are they among the types defined in the C++ standard language
support files listed on page 433 in Stroustrup (2nd Ed.)

std::size_t
std::ptrdiff_t
std::NULL

defined in <cstddef> are ok. I am wrong about this?
Jul 22 '05 #1
5 3420
On 4 Dec 2003 07:09:30 -0800, as******@earthlink.net (Andy Skypeck)
wrote:
I am looking for some validation against a dubious coding practice
that prevails where I work. C types defined in types.h (Linux) or
stdint.h (Windows, C99?) are used as if they belong to the C++
standard namespace.

std::uint8_t instead of uint8_t
std::uint32_t instead of uint32_t
...

I don't think the use of std:: is correct. Nowhere are these types
explicitly added to the std namespace. In fact GCC 3.3 fails on them.
Neither are they among the types defined in the C++ standard language
support files listed on page 433 in Stroustrup (2nd Ed.)

std::size_t
std::ptrdiff_t
std::NULL

defined in <cstddef> are ok. I am wrong about this?


No, they aren't standard types in C++. They are standard in C99
though. But since C99 doesn't have namespaces, std::uint8_t has never
existed. std::uint8_t will probably become part of C++0x, whenever
that is ratified (around 2007-8 I suspect), and it may be part of the
standard library extension before that. Some compilers may be
pre-empting that by providing the standard types, but it isn't yet
standard.

Tom

C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
Jul 22 '05 #2
"Andy Skypeck" <as******@earthlink.net> wrote...
I am looking for some validation against a dubious coding practice
that prevails where I work.
Take my word for it: it's better to go with the flow than against
it. Whether your coding practice is dubious or not, it's accepted
in the organisation, and you should do the same if you want to keep
your job.
C types defined in types.h (Linux) or
stdint.h (Windows, C99?) are used as if they belong to the C++
standard namespace.

std::uint8_t instead of uint8_t
std::uint32_t instead of uint32_t
...

I don't think the use of std:: is correct. Nowhere are these types
explicitly added to the std namespace.
What do you mean by that?
In fact GCC 3.3 fails on them.
So? How is that proof of anything?
Neither are they among the types defined in the C++ standard language
support files listed on page 433 in Stroustrup (2nd Ed.)

std::size_t
std::ptrdiff_t
std::NULL

defined in <cstddef> are ok. I am wrong about this?


NULL is a macro, it cannot be defined in a namespace. The Standard
says (17.4.1.1):

"1 The C++ Standard Library provides definitions for the following
types of entities: Macros, Values, Types, Templates, Classes,
Functions, Objects.

2 All library entities except macros, operator new and operator
delete are defined within the namespace std or namespaces nested
within namespace std."

Now, there is a subclause that says "It is undefined for a C++
program to add declarations or definitions to namespace std [...]"
but it could be argued that types you listed (uint8_t, etc.) are
part of the library implementation and as such belong to std...

Why don't you ask your development supervisor where they get those
types? They will probably be able to explain why 'std::' is used
there.

Victor
Jul 22 '05 #3
On 4 Dec 2003 07:09:30 -0800, as******@earthlink.net (Andy Skypeck)
I don't think the use of std:: is correct. Nowhere are these types
explicitly added to the std namespace. In fact GCC 3.3 fails on them.


I don't think that use of the ::std namespace is an official stamp of
approval. Take std::hashmap, for example: This is a container that's
been living in ::std for quite a while, even though it is not yet part
of the standard.
Jul 22 '05 #4
"Victor Bazarov" <v.********@comAcast.net> wrote in message news:<KuJzb.418968$HS4.3341510@attbi_s01>...
"Andy Skypeck" <as******@earthlink.net> wrote...
I am looking for some validation against a dubious coding practice
that prevails where I work.
Take my word for it: it's better to go with the flow than against
it. Whether your coding practice is dubious or not, it's accepted
in the organisation, and you should do the same if you want to keep
your job.


The organisation touts itself as a quality driven "six sigma"
environment. It seeks to write portable, robust, correct C++
code. Questioning what to me seems to be an incorrect
practice is very much in the spirit of the organisation.
Correctness should win out.
C types defined in types.h (Linux) or
stdint.h (Windows, C99?) are used as if they belong to the C++
standard namespace.

std::uint8_t instead of uint8_t
std::uint32_t instead of uint32_t
...

I don't think the use of std:: is correct. Nowhere are these types
explicitly added to the std namespace.


What do you mean by that?
In fact GCC 3.3 fails on them.

So? How is that proof of anything?


The release notes for GCC-3.3 discuss types included in std::
Neither are they among the types defined in the C++ standard language
support files listed on page 433 in Stroustrup (2nd Ed.)

std::size_t
std::ptrdiff_t
std::NULL

defined in <cstddef> are ok. I am wrong about this?


NULL is a macro, it cannot be defined in a namespace. The Standard
says (17.4.1.1):


I stand corrected on NULL.
Now, there is a subclause that says "It is undefined for a C++
program to add declarations or definitions to namespace std [...]"
but it could be argued that types you listed (uint8_t, etc.) are
part of the library implementation and as such belong to std...
I would accept that but, as I said above, the types are defined in a
file that is not part of the library implementation.
Why don't you ask your development supervisor where they get those
types? They will probably be able to explain why 'std::' is used
there.


I have. They have an external file stdint.h defining these types.
It is not part of any of the compilers we use. It is hand made to
imitate the types defined for C99. Some definitions init it even
collide with those in types.h in gcc-3.3. I have brought up this point
repeatedly with the leads to no avail. For my own satisfaction I'd
like to get to the bottom of this, which is why I posted.
Jul 22 '05 #5
"Andy Skypeck" <as******@earthlink.net> wrote...
"Victor Bazarov" <v.********@comAcast.net> wrote in message

news:<KuJzb.418968$HS4.3341510@attbi_s01>...
"Andy Skypeck" <as******@earthlink.net> wrote...
I am looking for some validation against a dubious coding practice
that prevails where I work.


Take my word for it: it's better to go with the flow than against
it. Whether your coding practice is dubious or not, it's accepted
in the organisation, and you should do the same if you want to keep
your job.


The organisation touts itself as a quality driven "six sigma"
environment. It seeks to write portable, robust, correct C++
code. Questioning what to me seems to be an incorrect
practice is very much in the spirit of the organisation.
Correctness should win out.
C types defined in types.h (Linux) or
stdint.h (Windows, C99?) are used as if they belong to the C++
standard namespace.

std::uint8_t instead of uint8_t
std::uint32_t instead of uint32_t
...

I don't think the use of std:: is correct. Nowhere are these types
explicitly added to the std namespace.


What do you mean by that?
In fact GCC 3.3 fails on them.

So? How is that proof of anything?


The release notes for GCC-3.3 discuss types included in std::
Neither are they among the types defined in the C++ standard language
support files listed on page 433 in Stroustrup (2nd Ed.)

std::size_t
std::ptrdiff_t
std::NULL

defined in <cstddef> are ok. I am wrong about this?


NULL is a macro, it cannot be defined in a namespace. The Standard
says (17.4.1.1):


I stand corrected on NULL.
Now, there is a subclause that says "It is undefined for a C++
program to add declarations or definitions to namespace std [...]"
but it could be argued that types you listed (uint8_t, etc.) are
part of the library implementation and as such belong to std...


I would accept that but, as I said above, the types are defined in a
file that is not part of the library implementation.
Why don't you ask your development supervisor where they get those
types? They will probably be able to explain why 'std::' is used
there.


I have. They have an external file stdint.h defining these types.
It is not part of any of the compilers we use. It is hand made to
imitate the types defined for C99. Some definitions init it even
collide with those in types.h in gcc-3.3. I have brought up this point
repeatedly with the leads to no avail. For my own satisfaction I'd
like to get to the bottom of this, which is why I posted.


Andy,

If you're trying to figure out why such thing has been done, you need
to keep talking to your colleagues and leads. There must not be "to no
avail" there. You are simply not supposed to give up. They are YOUR
colleagues, you're supposed to work TOGETHER, not against each other.

If you're looking for a justification to pick up a fight with them,
it is quite possible that you'll lose. They will tell you "we needed
those C99 types, since they are likely to be included in C++0x, so we
put them where our compiler can find them, and we put them in the 'std'
namespace because that's where they'll end up when added to C++0x".
The header <stdint.h> is standard in C99 and contains the "exact-width
integer types". A conflict with a GCC's non-standard header <types.h>
does NOT matter and has to be dealt with in a routine manner, not argued
about in public.

Just MHO.

Victor
Jul 22 '05 #6

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

1
by: J. Campbell | last post by:
I have a feeling that I'm doing things all ass-backwards (again ;-), and would like some advice. What I want to do is: put some data to memory and then access that memory space as an array of...
9
by: Anon Email | last post by:
Hi people, I'm learning about header files in C++. The following is code from Bartosz Milewski: // Code const int maxStack = 16; class IStack
4
by: grahamo | last post by:
Hi, I am trying to use STL copy routine to stream the my user defined type to std out. I am using a standard ostream_iterator object in conjunction with my type (called employee) which has ...
2
by: Thomas Matthews | last post by:
Hi, I'm working with Borland C++ Builder 6.2. My project uses the std::string class. However, Borland in its infinite wisdom has its own string class, AnsiString. To make my life easier, I...
8
by: Kyle Kolander | last post by:
Sorry, I sent this to comp.std.c++ and meant to send it here as well... Why are the minimum size guarantees for fundamental types intentionally omitted from section 3.9.1 Fundamental types of...
1
by: robinsand | last post by:
I am a new C++ programmer. I am still having trouble with certain data types and constructors, among other things. I'm not sure if I've used "std::string" properly throughout this program. I need...
6
by: Rennie deGraaf | last post by:
Hello, I would like to write a function that reads a sequence of unsigned shorts from /any/ container, converts them to pairs of unsigned chars, and writes them to /any/ container. In other...
5
by: alan | last post by:
Hello world, I'm wondering if it's possible to implement some sort of class/object that can perform mapping from class types to strings? I will know the class type at compile time, like so:...
11
by: john | last post by:
Hi, at first the code doesn't seem to work. Any ideas?: #include <iostream> #include <cstdlib> int main() { using namespace std;
1
isladogs
by: isladogs | last post by:
The next online meeting of the Access Europe User Group will be on Wednesday 6 Dec 2023 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, Mike...
0
by: VivesProcSPL | last post by:
Obviously, one of the original purposes of SQL is to make data query processing easy. The language uses many English-like terms and syntax in an effort to make it easy to learn, particularly for...
3
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 3 Jan 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). For other local times, please check World Time Buddy In...
0
by: jianzs | last post by:
Introduction Cloud-native applications are conventionally identified as those designed and nurtured on cloud infrastructure. Such applications, rooted in cloud technologies, skillfully benefit from...
2
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 7 Feb 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:30 (7.30PM). In this month's session, the creator of the excellent VBE...
0
by: fareedcanada | last post by:
Hello I am trying to split number on their count. suppose i have 121314151617 (12cnt) then number should be split like 12,13,14,15,16,17 and if 11314151617 (11cnt) then should be split like...
0
by: stefan129 | last post by:
Hey forum members, I'm exploring options for SSL certificates for multiple domains. Has anyone had experience with multi-domain SSL certificates? Any recommendations on reliable providers or specific...
1
by: davi5007 | last post by:
Hi, Basically, I am trying to automate a field named TraceabilityNo into a web page from an access form. I've got the serial held in the variable strSearchString. How can I get this into the...
0
by: MeoLessi9 | last post by:
I have VirtualBox installed on Windows 11 and now I would like to install Kali on a virtual machine. However, on the official website, I see two options: "Installer images" and "Virtual machines"....

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.