According to Microsoft the /vd2 switch: Allows you to use dynamic_cast Operator <https://msdn.microsoft.com/en-us/library/cby9kycs.aspx> 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 */vd2*is 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 Tue, Dec 22, 2015 at 10:41 AM, John Emmas <[email protected]> wrote: > 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 > [email protected] > https://mail.gnome.org/mailman/listinfo/gtkmm-list > >
_______________________________________________ gtkmm-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gtkmm-list
