c++ - Changing struct to class (and other type changes) and ABI/code generation -
it well-established , canonical reference question in c++ structs , classes pretty interchangeable, when writing code hand.
however, if want link existing code, can expect make difference (i.e. break, nasal demons etc.) if redeclare struct class, or vice versa, in header after original code has been generated?
so situation type compiled struct (or class), , i'm then changing header file other declaration before including in project.
the real-world use case i'm auto-generating code swig, generates different output depending on whether it's given structs or classes; need change 1 other output right interface.
the example here (irrlicht, svertexmanipulator.h) - given:
struct ivertexmanipulator { };
i redeclaring mechanically as:
/*struct*/class ivertexmanipulator {public: };
the original library compiles original headers, untouched. wrapper code generated using modified forms, , compiled using them. 2 linked same program work together. assume i'm using exact same compiler both libraries.
is sort of thing undefined? "undefined", expected work on real-world compilers? allowable?
other similar changes i'm making include removing default values parameters (to prevent ambiguity), , removing field declarations couple of classes type not visible swig (which changes structure of class, but reasoning generated code should need information, link member functions). again, how havoc cause?
e.g. igpuprogrammingservices.h:
s32 addhighlevelshadermaterial( const c8* vertexshaderprogram, const c8* vertexshaderentrypointname/*="main"*/, e_vertex_shader_type vscompiletarget/*=evst_vs_1_1*/, const c8* pixelshaderprogram=0, ...
public: //iindexlist *indices;
...and on that. other changes include replacing template parameter types typedefs , removing packed
attribute structs. again, seems there should no problem if altered struct declarations never used in machine code (just generate names link accessor functions in main library), reliably case? ever case?
this technically undefined behavior.
3.2/5:
there can more 1 definition of class type, [... or other things should defined in header files ...] in program provided each definition appears in different translation unit, , provided definitions satisfy following requirements. given such entity named
d
defined in more 1 translation unit, then
each definition of
d
shall consist of same sequence of tokens; and...
... if definitions of
d
satisfy these requirements, program shall behave if there single definition ofd
. if definitions ofd
not satisfy these requirements, behavior undefined.
essentially, changing first token struct
class
, , inserting tokens public
, :
appropriate. standard doesn't allow that.
but in compilers i'm familiar with, fine in practice.
other similar changes i'm making include removing default values parameters (to prevent ambiguity)
this formally allowed, if declaration doesn't happen within class definition. different translation units , different scopes within tu can define different default function arguments. you're fine there too.
other changes include replacing template parameter types typedefs
also formally allowed outside of class definition: 2 declarations of function use different ways of naming same type refer same function.
... removing field declarations ... , removing packed attribute structs
now you're in severe danger territory, though. i'm not familiar swig, if sort of thing, you'd better darn sure code using these "wrong" definitions never:
create or destroy object of class type
define type inherits or contains member of class type
use non-static data member of class
call inline or template function uses non-static data member of class
call
virtual
member function of class type or derived typetry find
sizeof
oralignof
class type
Comments
Post a Comment