Quote:Original post by visitor
However do the compilers realize that the assignment is indeed trivial for user-defined types?
They should.
Using malloc and memcopy in C++
They should.
Author
So classes can be treated as POD by the compiler? That's good to hear.
Actually, I don't have any slowdowns currently, since my game is still at tech demo stage. I've just figured out that all those coping around could be a slowdown. And most of them are necessary...
Actually, I don't have any slowdowns currently, since my game is still at tech demo stage. I've just figured out that all those coping around could be a slowdown. And most of them are necessary...
Quote:Original post by someboddy
I've just figured out that all those coping around could be a slowdown.
If only there existed some way to know for sure. Like a tool. That would profile time spent in various parts of code.
Quote:Original post by someboddy
Well, I have a 2D vector class, and a polygon class that has an array of that vector class. The polygon class gets copied around alot during the calculations, so I figured that to speed things up, I can {do more work, and I don't know yet if it will make a difference}
Now, hold on. Who's in charge here, you, or the computer? Whose time is more valuable?
Quote:My vector class is a class, but there is nothing stopping me from making it a struct.
There is no difference in C++ between 'struct's and 'class'es, beyond the defaults for public/private member (and base) access.
Further, there is no reason that using any of memcopy, malloc, std::copy, new, etc. etc. etc. would require structs rather than classes, or vice-versa. Class instances can be POD.
Quote:Also, the only critique in the POD definition that my vector class doesn't mach is having a constructor, but I only use the constructor to set the x and y values, so I don't think it should be such a problem...
Practically, it will probably work, but the Standard says it's not guaranteed to work. I can write a compiler that would take your code and end up horribly mangling things at runtime, and the people who define the language would defend me.
Optimization at this level is for specialized experts (such as "our own" Jan Wassenburg), and for the people who provide the compiler. If there were really any way you could make this faster, there would be huge numbers of people interested in it, and thus you could easily have a high-paying job helping develop the next version of VC++ or whatever.
The short version is, there's no reason for any normal developer not to use std::copy for range-copying, std::fill for range-initialization, and std::vector for array-memory-management in C++.
Author
OK, so you all think I should leave those kind of optimizations to the compiler. but how does the compiler knows if a class is POD? The constructor is there for convenience, it doesn't initialize anything vital(ofcourse, not having rubbish data is quite vital, but you know what I mean...), but will the compiler realize this and treat it as a POD, or does it have a thumb rule - contructor==not POD? Is there a way to define to the compiler that a certain class is POD?
I tried to use the "is_pod" class to check if my vector class is POD, but it seems like I don't have the "type_traits" header. Where can I get that library?
I tried to use the "is_pod" class to check if my vector class is POD, but it seems like I don't have the "type_traits" header. Where can I get that library?
Quote:Original post by someboddy
OK, so you all think I should leave those kind of optimizations to the compiler. but how does the compiler knows if a class is POD? The constructor is there for convenience, it doesn't initialize anything vital(ofcourse, not having rubbish data is quite vital, but you know what I mean...), but will the compiler realize this and treat it as a POD, or does it have a thumb rule - contructor==not POD? Is there a way to define to the compiler that a certain class is POD?
There are precise rules in the standard as to what is a POD:
http://www.fnal.gov/docs/working-groups/fpcltf/Pkg/ISOcxx/doc/POD.html
Constructors are unfortunately not allowed.
I had checked earlier and thought trivial constructors were allowed, but I only have a copy of the draft c++0x standard handy and it turns out they are relaxing the rules for PODs:
c++0x: http://en.wikipedia.org/wiki/C++0x#Modification_to_the_definition_of_plain_old_data
Quote:I tried to use the "is_pod" class to check if my vector class is POD, but it seems like I don't have the "type_traits" header. Where can I get that library?
#include <type_traits> would only work with a c++0x compiler (in c++0x mode). But you can try #include <tr1/type_traits> (then access it in the tr1 namespace).
Alternatively boost have an implementation of that.
I highly recommend downloading the Loki library and trying out yasli_vector (stands for "Yet Another Standard Library Implementation"). It detects POD types and uses memcpy for those, and there is even a way of telling it that your structs are POD so that it can do it for those too. I think you could even define move constructors for your class and have it take advantage of those too if memory serves me well.
Either way, it's got some way cool stuff!
Either way, it's got some way cool stuff!
Quote:
Alternatively boost have an implementation of that.
It seems to me that boost only detects built-in types as POD (with MinGW 3.4.5)
I did find a "type_traits.h" file that is used internally, and it contains a struct like this with specializations for built-in types and pointers.
struct __type_traits { typedef __true_type this_dummy_member_must_be_first; typedef __false_type has_trivial_default_constructor; typedef __false_type has_trivial_copy_constructor; typedef __false_type has_trivial_assignment_operator; typedef __false_type has_trivial_destructor; typedef __false_type is_POD_type; };Now you could provide an specialization for your type, but that would be non-portable and fragile (the type might be changed so that the typedefs in the specialization don't hold).
I don't see how it is possible to implement is_pod (or typetraits generally) purely as a library. As I understand the compiler must help and automatically generate a specialization for your types using knowledge about the type that isn't available at code level.
Quote:Original post by visitor
It seems to me that boost only detects built-in types as POD (with MinGW 3.4.5)
Boost type traits such as is_pod will use compiler intrinsic support where available, VC++ 8.0 above has intrinsic support and if i remember correctly so does GCC for quite sometime.
If your compiler doesn't have intrinsic support for is_pod then you're are suppose to (partially) specialize your user-defined types to state that they are POD-struct types.
Author
Quote:Original post by snk_kid
If your compiler doesn't have intrinsic support for is_pod then you're are suppose to (partially) specialize your user-defined types to state that they are POD-struct types.
How can I do that?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
