Allows you to use dynamic_cast Operator on an object being constructed. For example, a dynamic_cast from a virtual base class to a derived class.
/vd2 adds a vtordisp field when you have a virtual base with virtual functions. /vd1 should be sufficient. The most common case where /vd2is necessary is when the only virtual function in your virtual base is a destructor.
https://msdn.microsoft.com/en-us/library/7sf3txa8.aspx?f=255&MSPPError=-2147217396
I'm not sure why does MS compiler require this /vd2 and or how does it make *MM libraries better with MSVC, but I will try to recompile all *MM libraries with /vd2 switch and see if test passes. for now it does not:
The output from test program (posted in my previous post) with modifications suggested by Kjell, is as follows:
this: 003EFC98 after cast: 003EFC9C check address: NOK end arrived: OK
The dinamic_cast returned non consistent address in constructor, so not using the cast in constructors is probably safe, but I'm not sure if *MM libraries them self use dinamic_cast in constructors, however my programs run just fine now. so I guess not.
Also from the above link MS says the /vd1 switch should be sufficient which is default, so why bother with /vd2 ?
I've collected from the net that your projects must also use /vd2 switch if libraries are compiled with /vd2.
Also I've read on the net there was a known bug with /vd2 in other usages, such as this link:
http://mcdougalljonathan.blogspot.hr/2011/12/visual-c-2010-stdistringstream-crash-in.html
And if you just google out the /vd2 and gtkmm there are a lot of other people who had the same problems. and their work around was to compile everything WITHOUT /vd2
I'll do the test's one day (ex: compile all with /vd2 and use /vd2 in testing programs) and post results here.
hopefully the bug will be destroyed or at least explained.
On 22/12/2015 00:36, codekiddy wrote:
Hey guys I solved all the issues and would like to share my findings!!
Recently I made several posts here on gtkmm-list having problems with GTKMM on Windows with msvc builds, so as if#define GTKMM_ATKMM_ENABLED is defined during compilation there will be a runtime crash and
destruction problem with Glib::RefPtr<Pango::Layout> layout;
The problem was that I compiled ATKMM and PANGOMM with /vd2 compiler switch, and that was causing program shutdown crash in Atk::~Implementor and Layout::~Layout
I recompiled these 2 without the /vd2 option and with GTKMM_ATKMM_ENABLED 1, now everything works just fine :D
Hi codekiddy,
This is a total guess - but if we think back to your problems with GTKMM_ATKMM_ENABLED you'll remember we concluded that it needs to be defined identically everywhere. You can't have it defined in some modules but undefined in others. If that happens, the size of Gtk::Widget will be different in different modules (that's what was causing your crash). In fact I suggested using a "Force Include" header file to make sure it'll always be the same everywhere.
Maybe there's a similar requirement for /vd2? I noticed that it's defined for all these VC projects:-
glibmm
giomm
atkmm
pangomm
gdkmm
gtkmm
but interestingly - not for cairomm. I've no idea if that's a possible explanation. Just flagging it up as a discrepancy.
And if /vd2 is enabled for the "mm" libraries, does that mean you must also enable it for your own application? Maybe someone here can tell us.
John
_______________________________________________
gtkmm-list mailing list
gtkmm-list gnome org
https://mail.gnome.org/mailman/listinfo/gtkmm-list