   C++, Lua userdata, and memory alignment
  I'm not sure if this would be better placed in Game Mods and Scripting Languages, but it's basically about memory alignment, I think.I'm embedding Lua in my game manually. Call it for learning purposes. I've been using Lua userdata objects to wrap certain objects that need to be owned by Lua entities. The main example is the class Elements, short for Elemental Properties, which is basically a wrapper for std::set<std::string> and represents a set of properties posessable by my game entities.class Elements{    std::set<std::string> elements;    public:    Elements(){}    Elements(const std::string& e){   add(e);    }    bool has(const std::string& e)const{   if(!hasany()) return false; //bail out early on an empty set.   return elements.find(e) != elements.end();    }    bool hasany()const{   return elements.size() != 0;    }    Elements& add(const std::string& e, bool value = true){   if(value){//if it should be set to true  elements.insert(e);   } else { //it should be unset  elements.erase(e);   }   return *this;    }};I figured that to make it work with Lua, I could just use placement new to construct it in the userdata memory provided to me by Lua, and then manually call the destructor on it when it gets GC'd. Like so, eliminating non-essentials://creates a new userdata Elements from C++//This is the important function I'm asking aboutElements* PushElements(lua_State* L, const Elements& e){    //allocate userdata. Lua hands me memory to work with.    void* userdata = lua_newuserdata(L, sizeof(Elements));    //construct with placement new    Elements* elem = new(userdata) Elements(e); //MAY NOT BE ALIGNED!!!! ???    //set its metatable, for authentication purposes    luaL_getmetatable(L, ElementsMetatableName);    if(lua_isnil(L, -1)){   throw std::runtime_error("PushElements: metatable not created");    }    lua_setmetatable(L, -2);    //return the elements we created, so the caller can work with it    return elem;}//get an Elements userdata from the stackElements* GetElements(lua_State* L, int i){    //checkudata throws out if there's a type error    Elements* elem = reinterpret_cast<Elements*>(luaL_checkudata(L, i, ElementsMetatableName));    return elem;}//this gets set as the __gc metamethodint LuaElementsDestroy(lua_State* L){    //userdata is (should be) only argument    Elements* elem = reinterpret_cast<Elements*>(luaL_checkudata(L, 1, ElementsMetatableName));    //call destructor    elem->~Elements();    return 0;}These two functions are what I use in the API functions I export to Lua. My question is, is this safe in regards to memory alignment? This FAQ at the C++ FAQ Lite is not encouraging:Quote:The C++ FAQ LiteDANGER: You are taking sole responsibility that the pointer you pass to the "placement new" operator points to a region of memory that is big enough and is properly aligned for the object type that you're creating. Neither the compiler nor the run-time system make any attempt to check whether you did this right. If your Fred class needs to be aligned on a 4 byte boundary but you supplied a location that isn't properly aligned, you can have a serious disaster on your hands (if you don't know what "alignment" means, please don't use the placement new syntax). You have been warned.I'm not completely ignorant about memory alignment, but nor do I have more than a vague idea of what I need to do about it. This code works on both Linux and Windows, including with -O2 on Linux (using GCC), and with several other classes. For what it's worth, Lua is being compiled as C++. Is this being taken care of by the compiler for me, or have I just been lucky? What do I need to do to do it right?   
  Ive looked around can't find anything which guarantee that the memory is aligned but i suspect the creators of Lua took that into account. They are always striving for performance and return un-align memory would be pretty bad for performance.I'll post if i find anything definitive.-ddn   ;  Thanks, ddn3.I stepped through the creation of a userdata, and it looks like it just uses C realloc.   