Initializing a struct while calling a function
Pages: 12
Remember, you must use the 'struct' keyword now as part of the type:
Annoying, isn't it?
vector <struct MyStruct> v;Annoying, isn't it?
BTW, for those still interested.
C++0x will lift the restriction that simple classes cannot be treated as POD's.
http://www.research.att.com/~bs/C++0xFAQ.html#PODs
Woot!
C++0x will lift the restriction that simple classes cannot be treated as POD's.
http://www.research.att.com/~bs/C++0xFAQ.html#PODs
Woot!
| C++0x S and SS are "standard layout types" (a.k.a. POD) because there is really nothing "magic" about SS: the constructor does not affect the layout (so memcpy() would be fine), only the initialization rules (memset() would be bad - not enforcing the invariant). |
The only problem is that by the time we get to actually write code in C++0x we will already have numerous coding standards and habits so lifting the restriction doesn't do anyone a whole lot of good at this point. Perhaps 5 years from now when people are starting to learn C++ for the first time and write code using the c++0x compilers they will not worry about the old rules but the rest of us have a tremendous amount of legacy code to maintain and many existing projects are not going to just switch over to a new compiler overnight. While this might matter for the next generation of programmers it doesn't do the rest of us much good.
On the other hand, why would you want to use memset or memcpy on a struct that has a constructor anyway? What would be the point of that? If a struct already has a constructor, copy constructor, and assignment operator why not just use those to build, copy construct, and assign the objects? Algorithms like std::copy and std::fill can be used for arrays of these objects.
EDIT: by the way, thanks for the post Duoas. I mean it is interesting. I'm just saying; it is odd that they are just now thinking of changing the newer std. At this point it doesn't seem like a very helpful change though. By the time we get to write code to that std we will have already founds many work arounds and better habits anyway.
On the other hand, why would you want to use memset or memcpy on a struct that has a constructor anyway? What would be the point of that? If a struct already has a constructor, copy constructor, and assignment operator why not just use those to build, copy construct, and assign the objects? Algorithms like std::copy and std::fill can be used for arrays of these objects.
EDIT: by the way, thanks for the post Duoas. I mean it is interesting. I'm just saying; it is odd that they are just now thinking of changing the newer std. At this point it doesn't seem like a very helpful change though. By the time we get to write code to that std we will have already founds many work arounds and better habits anyway.
Last edited on
Well, memcpy() is a single call. I'm not having those silly templates steal my megahurtz.
| Well, memcpy() is a single call. I'm not having those silly templates steal my megahurtz. |
Huh? What does that have to do anything? You don't need a template to simply assign one struct instance to another. For ranges, std::copy is also a single call from your program.
Ahh, but it has to iterate through the container and call constructors. While that's not bad if you need to do a deep copy, it's still an extra cost.
Topic archived. No new replies allowed.
Pages: 12