 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Dhruv
Guest
|
 Posted: Wed Dec 24, 2003 10:55 pm Post subject: Quite a few questions. |
 |
|
The subject says it all!
1. Does an enum within an object contribute toward the sizeof the object.
Same question for static const? eg:
struct foo {
int z;
static const int x = 23;
enum { value = 34 };
};
So, when I instantiate objects of type foo like:
foo f1, f2, f3;
On the stack, or whatever, what will be the size allocated? (assume that
alignment issues are not present. likewise for statct, assume
sizeof(a_struct) == Summation (sizeof(i)) i = 0 -> number_of_members-1).
So, here do value and x contribute toward the sizeof foo?
2. I have read in many places that you need to provide the definition for
static consts also, while other places I have read that you do not. Which
one is right? eg:
struct X {
static const int x = 23;
};
Do I need this:
const int X: = 23; //?
3. It is recommended to use variables in unnamed namespaces compared to
declaring them static within the translation unit right?
So, is there anything that differs in terms of the time of iniialization
of the variable under question for the above 2 methods of creating
variables local to a translation unit?
4. Related to [3].
//File1.
static Max_val = 23;
//File2.
namespace { Max_val1 = 45; }
Now, given that you have a main.cpp including the above 2 files in any
order, which veriable will be initialized first? Or is there no guarantee?
---
The Elves are busy preparing the next version of the standard, so Santa
will be a bit late this year!
Merry Christmas!
-Dhruv.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
Joshua Lehrer
Guest
|
| Posted: Thu Dec 25, 2003 7:06 am Post subject: Re: Quite a few questions. |
|
|
"Dhruv" <dhruvbird (AT) gmx (DOT) net> wrote
| Quote: | The subject says it all!
1. Does an enum within an object contribute toward the sizeof the object.
Same question for static const? eg:
struct foo {
int z;
static const int x = 23;
enum { value = 34 };
};
|
No, it does not. Neither does a static variable add to the size of a
class. The size of your above class is sizeof(int). Static values,
and enums, are not specific to the instance, and thus are not
contained in a specific instance.
| Quote: |
2. I have read in many places that you need to provide the definition for
static consts also, while other places I have read that you do not. Which
one is right? eg:
struct X {
static const int x = 23;
};
|
That is fine. You may also leave out the definition, and then define
it outside the class.
| Quote: | 3. It is recommended to use variables in unnamed namespaces compared to
declaring them static within the translation unit right?
|
Correct. Using the keyword "static" to declare global variables is
deprecated.
| Quote: | So, is there anything that differs in terms of the time of iniialization
of the variable under question for the above 2 methods of creating
variables local to a translation unit?
|
Declaring a variable in an unnamed namespace and declaring them as
static are equivalent, but the latter is deprecated. The order of
initialization rules apply equally to both.
| Quote: |
4. Related to [3].
//File1.
static Max_val = 23;
//File2.
namespace { Max_val1 = 45; }
Now, given that you have a main.cpp including the above 2 files in any
order, which veriable will be initialized first? Or is there no guarantee?
|
Whichever is included first will be initliazed first. Remember that
one of the first things to be done is that the includes are removed
and a full translation unit is generated. Thus, you end up with a
file that has the two variables:
Unprocessed code:
file1.cxx:
static int Max_val = 23;
file2.cxx:
namespace { int Max_val1 = 45; }
main.cxx
#include "file1.cxx"
#include "file2.cxx"
int main() { }
Preprocessed code:
static int Max_val = 23;
namespace { int Max_val1 = 45; }
int main() { }
The order of initialization says that, for global variables, they are
constructed from top to bottom. Thus, "Max_val" is initialized before
"Max_val1".
joshua lehrer
factset research systems
NYSE:FDS
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Francis Glassborow
Guest
|
| Posted: Thu Dec 25, 2003 2:31 pm Post subject: Re: Quite a few questions. |
|
|
In message <pan.2003.12.24.18.00.07.12071 (AT) gmx (DOT) net>, Dhruv
<dhruvbird (AT) gmx (DOT) net> writes
| Quote: | The subject says it all!
1. Does an enum within an object contribute toward the sizeof the object.
|
No
| Quote: | Same question for static const? eg:
|
No
| Quote: | struct foo {
int z;
static const int x = 23;
enum { value = 34 };
};
So, when I instantiate objects of type foo like:
foo f1, f2, f3;
On the stack, or whatever, what will be the size allocated? (assume that
alignment issues are not present. likewise for statct, assume
sizeof(a_struct) == Summation (sizeof(i)) i = 0 -> number_of_members-1).
So, here do value and x contribute toward the sizeof foo?
|
The sizeof foo should be identical with the size of bar in
stract bar {
int z;
};
| Quote: | 2. I have read in many places that you need to provide the definition for
static consts also, while other places I have read that you do not. Which
one is right? eg:
struct X {
static const int x = 23;
|
That is in class initialisation, it is NOT a definition of x
| Quote: | };
Do I need this:
const int X: = 23; //?
|
Yes, in exactly one place in your program.
| Quote: | 3. It is recommended to use variables in unnamed namespaces compared to
declaring them static within the translation unit right?
|
Yes
| Quote: | So, is there anything that differs in terms of the time of iniialization
of the variable under question for the above 2 methods of creating
variables local to a translation unit?
|
No
| Quote: | 4. Related to [3].
//File1.
static Max_val = 23;
//File2.
namespace { Max_val1 = 45; }
Now, given that you have a main.cpp including the above 2 files in any
order, which veriable will be initialized first? Or is there no guarantee?
|
Any order as they are in different TUs. In both cases they will be what
is called 'static' initialisation because the code will be provided
directly by the compiler rather than code having to be executed
(dynamic) to do the initialisation. Contrast that with
double d = sin(1);
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
or http://www.robinton.demon.co.uk
Happy Xmas, Hanukkah, Yuletide, Winter/Summer Solstice to all.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Rajaram S. Gaunker
Guest
|
| Posted: Thu Dec 25, 2003 2:35 pm Post subject: Re: Quite a few questions. |
|
|
| Quote: | 1. Does an enum within an object contribute toward the sizeof the object.
Same question for static const? eg:
struct foo {
int z;
static const int x = 23;
enum { value = 34 };
};
|
enum wont contribute cause no member of type enum exist inside the
structure.
similarly static const also wont contribute.
| Quote: | So, when I instantiate objects of type foo like:
foo f1, f2, f3;
On the stack, or whatever, what will be the size allocated? (assume that
alignment issues are not present. likewise for statct, assume
sizeof(a_struct) == Summation (sizeof(i)) i = 0 -> number_of_members-1).
So, here do value and x contribute toward the sizeof foo?
|
foo: is not contributing
| Quote: | 2. I have read in many places that you need to provide the definition for
static consts also, while other places I have read that you do not. Which
one is right? eg:
struct X {
static const int x = 23;
};
Do I need this:
const int X: = 23; //?
|
Since it is static constant
struct X {
| Quote: | static const int x = 23;
};
|
this is according to standard VC++ gives error coz its not following
the statement in this case
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Francis Glassborow
Guest
|
| Posted: Thu Dec 25, 2003 2:38 pm Post subject: Re: Quite a few questions. |
|
|
In message <31c49f0d.0312241902.6a2661ed (AT) posting (DOT) google.com>, Joshua
Lehrer <usenet_cpp (AT) lehrerfamily (DOT) com> writes
| Quote: | 2. I have read in many places that you need to provide the definition for
static consts also, while other places I have read that you do not. Which
one is right? eg:
struct X {
static const int x = 23;
};
That is fine.
|
Strictly speaking it isn't because that is not a definition only an
in-class initialisation and declaration of x. In practice you will often
get away without the 'required' definition.
| Quote: | You may also leave out the definition, and then define
it outside the class.
snip
4. Related to [3].
//File1.
static Max_val = 23;
//File2.
namespace { Max_val1 = 45; }
Now, given that you have a main.cpp including the above 2 files in any
order, which veriable will be initialized first? Or is there no guarantee?
Whichever is included
|
I think you mean whichever the linker sees first.
| Quote: | first will be initliazed first. Remember that
one of the first things to be done is that the includes are removed
and a full translation unit is generated. Thus, you end up with a
file that has the two variables:
|
I find the above very confused. We normally refer to include to mean
items that are the result of the preprocessor handling #include. The
result of such processing is to create a translation unit which is then
compiled.
| Quote: | Unprocessed code:
file1.cxx:
static int Max_val = 23;
file2.cxx:
namespace { int Max_val1 = 45; }
|
If the programmer actually wrote the code below it would likely result
in errors. And the compiler certainly never does any such thing.
| Quote: | main.cxx
#include "file1.cxx"
#include "file2.cxx"
int main() { }
Preprocessed code:
static int Max_val = 23;
namespace { int Max_val1 = 45; }
|
Not unless the programmer has written the above #includes. You are
definitely confusing pre-processing with whatever process is used to
link object code into a program. The two processes are about as far
apart as is possible. Preprocessing happens right at the start of
compiling a .cpp file; linking happens after source code has been
converted to object code.
| Quote: | int main() { }
The order of initialization says that, for global variables, they are
constructed from top to bottom. Thus, "Max_val" is initialized before
"Max_val1".
|
Though linkers will often take the order of object files provided in the
link 'directive' they are not required to do so and we should not rely
on it.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
or http://www.robinton.demon.co.uk
Happy Xmas, Hanukkah, Yuletide, Winter/Summer Solstice to all.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Ron Natalie
Guest
|
| Posted: Fri Dec 26, 2003 12:57 pm Post subject: Re: Quite a few questions. |
|
|
"Dhruv" <dhruvbird (AT) gmx (DOT) net> wrote
| Quote: | The subject says it all!
1. Does an enum within an object contribute toward the sizeof the object.
Same question for static const? eg:
struct foo {
int z;
static const int x = 23;
enum { value = 34 };
};'
|
No, you haven't defined a enum member, only the type. It's just like you added a typedef
or some other type declaration without declaring a member.
Static's never count in the object size anyhow. They allocated seperately, once.
| Quote: | 2. I have read in many places that you need to provide the definition for
static consts also, while other places I have read that you do not. Which
one is right? eg:
|
Integral static consts can be defined inline. All others must be seperately defined.
| Quote: |
3. It is recommended to use variables in unnamed namespaces compared to
declaring them static within the translation unit right?
|
Static at namespace (GLOBAL) scope. Static inside a class isn't affected by that
recommendation.
| Quote: | Now, given that you have a main.cpp including the above 2 files in any
order, which veriable will be initialized first? Or is there no guarantee?
|
No guarantee, but since both are static initialization (I'm assuming you really wanted to
declare these as int type), they will be initialized before any dynamic code is run.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Joshua Lehrer
Guest
|
| Posted: Fri Dec 26, 2003 12:59 pm Post subject: Re: Quite a few questions. |
|
|
| Quote: | 4. Related to [3].
//File1.
static Max_val = 23;
//File2.
namespace { Max_val1 = 45; }
Now, given that you have a main.cpp including the above 2 files in any
order, which veriable will be initialized first? Or is there no guarantee?
Whichever is included
I think you mean whichever the linker sees first.
|
no, I did not. re-read the original post. "Now, given that you have
main.cpp including the above 2 files in any order, which variable will
be initialized first?" From that, I took that the programmer wrote a
main.cxx that included file1.cxx and file2.cxx. This, while not
advised, is perfectly legal c++.
| Quote: |
first will be initliazed first. Remember that
one of the first things to be done is that the includes are removed
and a full translation unit is generated. Thus, you end up with a
file that has the two variables:
I find the above very confused. We normally refer to include to mean
items that are the result of the preprocessor handling #include. The
result of such processing is to create a translation unit which is then
compiled.
|
Yes, and that is exactly what I meant as well.
| Quote: | Unprocessed code:
file1.cxx:
static int Max_val = 23;
file2.cxx:
namespace { int Max_val1 = 45; }
If the programmer actually wrote the code below it would likely result
in errors. And the compiler certainly never does any such thing.
|
why not? What is wrong with the above code? How does it not possibly
result in the post-preprocessed code as I posted it?
| Quote: | main.cxx
#include "file1.cxx"
#include "file2.cxx"
int main() { }
Preprocessed code:
static int Max_val = 23;
namespace { int Max_val1 = 45; }
Not unless the programmer has written the above #includes. You are
definitely confusing pre-processing with whatever process is used to
link object code into a program. The two processes are about as far
apart as is possible. Preprocessing happens right at the start of
compiling a .cpp file; linking happens after source code has been
converted to object code.
|
I'm not confusing them. The original poster said that his main.cxx
would include file1.cxx and file2.cxx. That is exactly what I posted.
The question was, which order would the variables be initialized, and
did it depend on which order main.cxx included file1.cxx and
file2.cxx.
You seem to be confusing liking with what the original poster was
asking about.
-joshua lehrer
factset research systems
NYSE:FDS
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Derek
Guest
|
| Posted: Fri Dec 26, 2003 7:44 pm Post subject: Re: Quite a few questions. |
|
|
"Francis Glassborow" wrote:
| Quote: | 2. I have read in many places that you need to provide the
definition for static consts also, while other places I have
read that you do not. Which one is right? eg:
struct X { satic const int x = 23;
That is in class initialisation, it is NOT a definition of x
};
Do I need this: const int X: = 23; //?
Yes, in exactly one place in your program.
|
So why can I get away without defining static integer constants? Why
does
// X.h
struct X
{
static const int x = 23;
};
usually suffice (at least with my compilers), without a definition?
Does X: get replaced by 23 by the compiler every time, so the linker
never realizes it has been swindled out of a definition (in most
cases, anyway)?
Also, if I add add a definition:
// X.cpp
const int X: = 23;
shouldn't the compiler complain about a duplicate initialization (as
GCC 3.2 does)?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Francis Glassborow
Guest
|
| Posted: Fri Dec 26, 2003 11:49 pm Post subject: Re: Quite a few questions. |
|
|
In message <bshkhc$d8bcg$1 (AT) ID-46268 (DOT) news.uni-berlin.de>, Derek
<none (AT) none (DOT) com> writes
| Quote: | So why can I get away without defining static integer constants? Why
does
// X.h
struct X
{
static const int x = 23;
};
usually suffice (at least with my compilers), without a definition?
Does X: get replaced by 23 by the compiler every time, so the linker
never realizes it has been swindled out of a definition (in most
cases, anyway)?
|
Exactly, if the compiler finds no reason to require that storage be
provided for x the resulting code does not need to ask the linker to
check that storage has been provided.
| Quote: |
Also, if I add add a definition:
// X.cpp
const int X: = 23;
|
NO, that should be:
const int X:;
as the initialiser has already been provided.
| Quote: |
shouldn't the compiler complain about a duplicate initialization (as
GCC 3.2 does)?
|
Yes it should because you have provided the initialiser twice.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
or http://www.robinton.demon.co.uk
Happy Xmas, Hanukkah, Yuletide, Winter/Summer Solstice to all.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Dhruv
Guest
|
| Posted: Sat Dec 27, 2003 11:10 am Post subject: Re: Quite a few questions. |
|
|
On Thu, 25 Dec 2003 09:38:22 -0500, Francis Glassborow wrote:
| Quote: | In message <31c49f0d.0312241902.6a2661ed (AT) posting (DOT) google.com>, Joshua
Lehrer <usenet_cpp (AT) lehrerfamily (DOT) com> writes
2. I have read in many places that you need to provide the definition for
static consts also, while other places I have read that you do not. Which
one is right? eg:
struct X {
static const int x = 23;
};
That is fine.
Strictly speaking it isn't because that is not a definition only an
in-class initialisation and declaration of x. In practice you will often
get away without the 'required' definition.
|
Now, I'm confused here. You mentioned in your previous post that a
definition is required, and now you are saying that it is not? Even
Authours like Stroustrup said that definitions are required, and other
experienced progrmmers on this newsgroup have said that it is not? Now I'm
confused!
| Quote: | You may also leave out the definition, and then define
it outside the class.
|
[...]
| Quote: | Unprocessed code:
file1.cxx:
static int Max_val = 23;
file2.cxx:
namespace { int Max_val1 = 45; }
If the programmer actually wrote the code below it would likely result
in errors. And the compiler certainly never does any such thing.
|
Why?
| Quote: | main.cxx
#include "file1.cxx"
#include "file2.cxx"
int main() { }
Preprocessed code:
static int Max_val = 23;
namespace { int Max_val1 = 45; }
|
Regards,
-Dhruv.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
James Kanze
Guest
|
| Posted: Sat Dec 27, 2003 11:12 am Post subject: Re: Quite a few questions. |
|
|
Francis Glassborow <francis (AT) robinton (DOT) demon.co.uk> writes:
| Quote: | In message <pan.2003.12.24.18.00.07.12071 (AT) gmx (DOT) net>, Dhruv
[email]dhruvbird (AT) gmx (DOT) net[/email]> writes
The subject says it all!
1. Does an enum within an object contribute toward the sizeof the
object.
No
Same question for static const? eg:
No
struct foo {
int z;
static const int x = 23;
enum { value = 34 };
};
So, when I instantiate objects of type foo like:
foo f1, f2, f3;
On the stack, or whatever, what will be the size allocated? (assume
that alignment issues are not present. likewise for statct, assume
sizeof(a_struct) == Summation (sizeof(i)) i = 0 -
number_of_members-1). So, here do value and x contribute toward the
sizeof foo?
The sizeof foo should be identical with the size of bar in
stract bar {
int z;
};
|
Just a nit, but is this actually guaranteed by the standard, or is it
just one of those things we can count on in practice, because any other
implementation would be completely silly? (And I insist on the fact
that it is a nit -- even if the standard doesn't guarantee it, I would
feel safe counting on it.)
--
James Kanze mailto:kanze (AT) gabi-soft (DOT) fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Francis Glassborow
Guest
|
| Posted: Sat Dec 27, 2003 3:45 pm Post subject: Re: Quite a few questions. |
|
|
In message <pan.2003.12.27.03.14.47.532919 (AT) gmx (DOT) net>, Dhruv
<dhruvbird (AT) gmx (DOT) net> writes
| Quote: | On Thu, 25 Dec 2003 09:38:22 -0500, Francis Glassborow wrote:
In message <31c49f0d.0312241902.6a2661ed (AT) posting (DOT) google.com>, Joshua
Lehrer <usenet_cpp (AT) lehrerfamily (DOT) com> writes
2. I have read in many places that you need to provide the definition for
static consts also, while other places I have read that you do not. Which
one is right? eg:
struct X {
static const int x = 23;
};
That is fine.
Strictly speaking it isn't because that is not a definition only an
in-class initialisation and declaration of x. In practice you will often
get away without the 'required' definition.
Now, I'm confused here. You mentioned in your previous post that a
definition is required, and now you are saying that it is not? Even
Authours like Stroustrup said that definitions are required, and other
experienced progrmmers on this newsgroup have said that it is not? Now I'm
confused!
|
Yes, but the Standard saying it is required does not mean that an
implementation will note that the programmer did not provide it. It is
an error with 'no diagnostic required'. I.e. the compiler is not
required to tell you that you broke the rules. If it actually does not
notice, this is one of the cases where it will just about certainly 'do
the right thing' (I.e. what the programmer expects)
| Quote: |
You may also leave out the definition, and then define
it outside the class.
[...]
Unprocessed code:
file1.cxx:
static int Max_val = 23;
file2.cxx:
namespace { int Max_val1 = 45; }
If the programmer actually wrote the code below it would likely result
in errors. And the compiler certainly never does any such thing.
Why?
main.cxx
#include "file1.cxx"
#include "file2.cxx"
|
If you start including implementation files in each other you are going
to get surprises. If those files have unnamed namespaces in them then
you are heading for more surprises because each TU will have its own
versions which will have nothing to do with any others. You may even
manage to get multiple versions in different namespaces in the same TU.
I must confess that I did not even realise that this is what you meant
in your original post because while many years ago some C programmers
did this (and it is not ill-formed to do so) it never crossed my mind
that a C++ programmer would do such a thing as there are just too many
things that can go wrong by doing it.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
or http://www.robinton.demon.co.uk
Happy Xmas, Hanukkah, Yuletide, Winter/Summer Solstice to all.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Carl Barron
Guest
|
| Posted: Sun Dec 28, 2003 10:12 am Post subject: Re: Quite a few questions. |
|
|
James Kanze <kanze (AT) alex (DOT) gabi-soft.fr> wrote:
| Quote: | Francis Glassborow <francis (AT) robinton (DOT) demon.co.uk> writes:
|> In message <pan.2003.12.24.18.00.07.12071 (AT) gmx (DOT) net>, Dhruv
|> <dhruvbird (AT) gmx (DOT) net> writes
|> >The subject says it all!
|> >1. Does an enum within an object contribute toward the sizeof the
|> >object.
|> No
|> >Same question for static const? eg:
|> No
|> >struct foo {
|> >int z;
|> >static const int x = 23;
|> >enum { value = 34 };
|> >};
|> >So, when I instantiate objects of type foo like:
|> >foo f1, f2, f3;
|> >On the stack, or whatever, what will be the size allocated? (assume
|> >that alignment issues are not present. likewise for statct, assume
|> >sizeof(a_struct) == Summation (sizeof(i)) i = 0 -
|> >number_of_members-1). So, here do value and x contribute toward the
|> >sizeof foo?
|> The sizeof foo should be identical with the size of bar in
|> stract bar {
|> int z;
|> };
Just a nit, but is this actually guaranteed by the standard, or is it
just one of those things we can count on in practice, because any other
implementation would be completely silly? (And I insist on the fact
that it is a nit -- even if the standard doesn't guarantee it, I would
feel safe counting on it.)
I do not believe the standard FORBIDS extra padding at the end of a |
struct for alignment purposes to a specific allignment. Safety is
relative :)
I would use a compile time assert which creates an error if the
assertion is false, such as:
template <bool B,typename T = void> struct restrict_to{};
template <typename T>struct restrict_to<true,T>
{
typedef T result;
};
void dosomething(typename restrict_to<sizeof(bar)==sizeof(int)>::result
* = 0);
....
void do_something(typename restrict_to<sizeof(bar)==sizeof(int)>::result
*)
{
// do your thing
}
there are other ways to do this, I think boost has a restrict_to
similiar to above.
template <bool B,typename T,typename F>
struct select {typedef T result;};
template <typename T,typename F>
struct select<false,T,F> {typename F result;};
allows compile time if statements
also
template <unsigned long N>
struct Ulong2Type {static const unsigned long value=N;};
can be used to create a new type for each intergral value required.
with these two templates and function overloading you can create as many
overloaded functions as needed.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
James Kanze
Guest
|
| Posted: Sun Dec 28, 2003 3:51 pm Post subject: Re: Quite a few questions. |
|
|
[email]cbarron3 (AT) ix (DOT) netcom.com[/email] (Carl Barron) writes:
| Quote: | Just a nit, but is this actually guaranteed by the standard, or
is it just one of those things we can count on in practice,
because any other implementation would be completely silly? (And
I insist on the fact that it is a nit -- even if the standard
doesn't guarantee it, I would feel safe counting on it.)
I do not believe the standard FORBIDS extra padding at the end of
a struct for alignment purposes to a specific allignment. Safety is
relative 
|
That was my point. I think a compiler could legally do:
struct C1 { char c ; } ; // Alignment 1, no padding
struct C2 { static int i ; char c ; } ;
// Alignment 4, 3 bytes padding
For that matter, I think a compiler could legally do:
struct A { char c ; } ; // Typename starts with A, no padding
struct Z { char c ; } ; // Typename starts with Z, alignment 4,
// 3 bytes padding...
I certainly don't expect to ever see the latter, even if it is legal,
and I think that I am rather safe is supposing that I'll not see the
former, either. (But as you say, a compile time check is perhaps a good
idea.)
--
James Kanze mailto:kanze (AT) gabi-soft (DOT) fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Francis Glassborow
Guest
|
| Posted: Sun Dec 28, 2003 3:59 pm Post subject: Re: Quite a few questions. |
|
|
In message <1g6mzxy.1s66nngzt38y5N%cbarron3 (AT) ix (DOT) netcom.com>, Carl Barron
<cbarron3 (AT) ix (DOT) netcom.com> writes
| Quote: | Just a nit, but is this actually guaranteed by the standard, or is it
just one of those things we can count on in practice, because any other
implementation would be completely silly? (And I insist on the fact
that it is a nit -- even if the standard doesn't guarantee it, I would
feel safe counting on it.)
I do not believe the standard FORBIDS extra padding at the end of a
struct for alignment purposes to a specific allignment. Safety is
relative
|
I doubt that alignment issues are relevant because we were discussing:
struct foo {
int z;
static const int x = 23;
enum { value = 34 };
};
struct bar {
int z;
};
And those will, IMO, have identical alignment requirements.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
or http://www.robinton.demon.co.uk
Happy Xmas, Hanukkah, Yuletide, Winter/Summer Solstice to all.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
