Basically you'll want to use asOBJ_POD for any C++ type that is a plain-old-data type, i.e. doesn't have any virtual function table, and doesn't have any members that require explicit initialization and/or clean-up (e.g. pointers, file handle ids, etc).

There is no problem in providing constructors for objects registered with asOBJ_POD. The flag just says they are not required, not that they are not allowed. Without the asOBJ_POD flag, AngelScript would require the application to register both constructor (at least one) and destructor for the object.

The use of asOBJ_POD also allows AngelScript to make some optimizations, as it can safely inline POD objects within script classes without worrying about invalid memory access due to uninitialized objects while executing the script class constructor.

The existance of a user defined constructor doesn't imply that that the object is not a POD type. If the members can be safely accessed even before the constructor is called without causing any harm, then it can still be considered a POD type.

For example:

class Vec2
{
public:
   Vec2() : x(0), y() {}
   Vec2(float _x, float _y) : x(_x), y(_y) {}
   float x,y;
}

The above class is an ordinary POD type even though it has user defined constructors. Think of it like this. Can any harm be done if you interpret a random address into uninitialized memory as the type and then access the members? If no harm can be done then the type is a POD type, but if some harm can be done then it is not a POD type.

asOBJ_POD and the various asOBJ_APP_CLASS_ flags are not directly related to each other. The first tells AngelScript that it is safe to access the unitialized memory and thus it can allow direct bitwise copies of the objects, and the second is used to allow AngelScript to properly passed values of the type to the application registered functions in native calling conventions.

Ideally you would use the templated GetTypeTraits<T>() helper add-on function to determine the correct combination of the asOBJ_APP_CLASS_ flags automatically. This function is only available for compilers that support C++11 though, so if you use an older compiler you'll need to determine the flags manually.

gcc is c++11 capable (from 4.7+) if you compile with -std=c++11 so I suggest you use the GetTypeTraits, this way you don't have to worry about informing the wrong flags by mistake.

Example:

#include <add_on/scripthelper/scripthelper.h>
 
engine->RegisterObjectType("vector3", sizeof(vector3), asOBJ_VALUE | asOBJ_POD | GetTypeTraits<vector3>());

Otherwise, the guidelines for determining the correct flags, are those written in the manual.

On 32bit Linux only the existance of the class destructor or the class copy constructor influences the native calling convention, but on other platforms other properties of the class influences it, so if you're planning on porting your code to other platforms in the future try to set the flags correctly to avoid head-aches later on.

Perhaps a couple of examples will help.

class vector2
{
public:
   vector2();  // explicit default constructor
   vector2(const vector2 &); // explicit copy constructor
 
   float x,y;
};
 
class data
{
public:
   data();
 
   std::string name;
}

The vector2 class should be registered with the flags asOBJ_APP_CLASS_CK because it has a default constructor and a copy constructor.

The data class should be registered with the flags asOBJ_APP_CLASS_CD because it has a default constructor and an implicit destructor due to the string member.

Ideally you would also make a controlled test with the type after registering it. Try for example to call an application registered function that takes or returns the type by value and see if the object is correctly passed between AngelScript and the application. If it is not correct the result may either be a segfault or simply garbage in the members.