-
November 13th, 2011, 11:00 AM
#1
TMP and codebloat
How could we measured the relationship between types and binary files generated by
compilers?
Code:
template<typename T>
T Max(T const A, T const B)
{
return A > B ? A : B;
}
void testMax()
{
int a = 5, b = 10;
double c = 44.4, d = 33.23;
Max(a, b);
Max(c, d);
}
is same as
Code:
int Max(int const A, int const B)
{
return A > B ? A : B;
}
double Max(double const A, double const B)
{
return A > B ? A : B;
}
Ok, I know I could ask the compiler to generate the "Max" I need
and it is same as handcrafted codes
but what about this
Code:
typedef boost::mpl::vector<int, double, char, size_t, long double> complex_types;
would the complex_types consume more binary codes to save the types than
primitive types?
Besides, when we do something like TMP like this
Code:
class NullType;
template<typename T, typename U>
class Typelist
{
typedef T Head;
typedef U Tail;
};
template<typename TList>
class length;
template<>
class length<NullType>
{
public :
enum{ Value = 0 };
};
template<typename Head, typename Tail>
class length<Typelist<Head, Tail> >
{
public :
enum { Value = 1 + length<Tail>::Value };
};
what we really get is an enumerator constant "Value"
would those recursive steps generate binary codes too?
Or compiler would optimize it?
Thanks
-
November 13th, 2011, 12:42 PM
#2
Re: TMP and codebloat
Originally Posted by stereoMatching
but what about this
Code:
typedef boost::mpl::vector<int, double, char, size_t, long double> complex_types;
would the complex_types consume more binary codes to save the types than
primitive types?
Besides, when we do something like TMP like this
Code:
class NullType;
template<typename T, typename U>
class Typelist
{
typedef T Head;
typedef U Tail;
};
template<typename TList>
class length;
template<>
class length<NullType>
{
public :
enum{ Value = 0 };
};
template<typename Head, typename Tail>
class length<Typelist<Head, Tail> >
{
public :
enum { Value = 1 + length<Tail>::Value };
};
what we really get is an enumerator constant "Value"
would those recursive steps generate binary codes too?
Or compiler would optimize it?
Thanks
There is no executable code there, so there is no reason for it to end up in a binary. In typelists an enum is used exactly because it doesn't use any space. The alternative would be a static const int, which could use space in a binary.
Cheers, D Drmmr
Please put [code][/code] tags around your code to preserve indentation and make it more readable.
As long as man ascribes to himself what is merely a posibility, he will not work for the attainment of it. - P. D. Ouspensky
-
November 13th, 2011, 06:55 PM
#3
Re: TMP and codebloat
Originally Posted by D_Drmmr
There is no executable code there, so there is no reason for it to end up in a binary. In typelists an enum is used exactly because it doesn't use any space. The alternative would be a static const int, which could use space in a binary.
static const int in or outside of a class declaration or const int outside of a class declaration may or may not take up memory in the binary based on several reasons which include (but may not be limited to) how well the optimizer works or if an address is ever required for that integer.
A
-
November 13th, 2011, 08:37 PM
#4
Re: TMP and codebloat
There is no executable code there, so there is no reason for it to end up in a binary.
Thanks, it is reasonable to think that the compiler would not generate the binary for those
deduction steps within compile times.
But where is the data of enum save at?Even it don't need to consume register or ram, it still
need something to identify the value of it?The type of boost::mpl also, wouldn't type
Code:
boost::mpl::vector<int, double, char>
contains more information than "int"?
Thanks a lot
-
November 14th, 2011, 12:12 PM
#5
Re: TMP and codebloat
Originally Posted by stereoMatching
But where is the data of enum save at?Even it don't need to consume register or ram, it still
need something to identify the value of it?
Depending on the compiler optimization routine, the "data" is not saved. Since the value of an enum cannot change at runtime, the compiler can replace the enum identifier with it's value at compile time, and throw the identifier away.
Code:
#include <iostream>
enum
{
ONE = 1,
TWO,
THREE
}
int main()
{
std::cout << "2 + TWO is " << 2 + TWO << std::endl;
}
The compiler is able to make this substitution at compile time:
Code:
std::cout << "2 + TWO is " << 2 + 2 << std::endl;
If it wanted to, and the resulting executable wouldn't contain any inclination that the second operand in the equation was actually an enum.
Viggy
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|