Am Thu, 20 Dec 2012 08:25:33 -0200 schrieb Gustavo Sverzut Barbieri: > On Thursday, December 20, 2012, Cedric BAIL wrote: > > > Hello, > > > > On Thu, Dec 20, 2012 at 6:24 AM, Andreas Volz > > <[email protected]<javascript:;>> wrote: > > > Times ago I wrote some Eflxx Evas Canvas wrapper. There are those > > > functions in Canvas.cpp/.h: > > > > > > Canvas *Canvas::wrap (Evas_Object *o) > > > { > > > return new Canvas (evas_object_evas_get (o)); > > > } > > > > > > Canvas *Canvas::wrap (Evas *evas) > > > { > > > return new Canvas (evas); > > > } > > > > > > One time it stopped compiling on Ubuntu Precise and as workaround > > > I just commented out the second wrap() function. > > > > > > Then I noticed the launchpad precise build job fails in ecorexx > > > with the > > same source it > > > local compiles: > > > > > > > > https://launchpadlibrarian.net/125311410/buildlog_ubuntu-precise-amd64.ecorexx_0.1-0~201212100108~precise1_FAILEDTOBUILD.txt.gz > > > > > > EvasWindowFB.cpp: In constructor > > 'Ecorexx::EvasWindowFB::EvasWindowFB(const Eflxx::Size&, const > > char*, int)': > > > EvasWindowFB.cpp:73:56: error: no matching function for call to > > 'Evasxx::Canvas::wrap(Evas*)' > > > EvasWindowFB.cpp:73:56: note: candidate is: > > > /usr/include/evasxx/Canvas.h:82:18: note: static Evasxx::Canvas* > > Evasxx::Canvas::wrap(Evas_Object*) > > > /usr/include/evasxx/Canvas.h:82:18: note: no known conversion > > > for > > argument 1 from 'Evas* {aka _Evas*}' to 'Evas_Object* {aka > > _Evas_Object*}' > > > > > > Strange! Then I uncomment the second wrap function and local get > > > this > > error: > > > > > > In file included from Canvas.cpp:6:0: > > > ../include/evasxx/Canvas.h:94:18: error: 'static Evasxx::Canvas* > > Evasxx::Canvas::wrap(Evas*)' cannot be overloaded > > > ../include/evasxx/Canvas.h:82:18: error: with 'static > > > Evasxx::Canvas* > > Evasxx::Canvas::wrap(Evas_Object*)' > > > Canvas.cpp:178:9: error: redefinition of 'static Evasxx::Canvas* > > Evasxx::Canvas::wrap(Evas*)' > > > Canvas.cpp:173:9: error: 'static Evasxx::Canvas* > > Evasxx::Canvas::wrap(Evas_Object*)' previously defined here > > > make[2]: *** [Canvas.lo] Fehler 1 > > > > > > Why does the compiler detect Evas* as redefinition of Evas_Object* > > parameter? Did something change? > > > > > > Why couldn't I overload it? I may simply change wrap() to > > > wrapEvas() or > > so, but I really like to understand it. > > > > That's because of the move to Eo and a conflict between how C++ and > > Eo see the world. It would be good to provide a class that handle Eo > > object smartly. In fact it should be doable to provide some smart > > pointer template that use Eo refcounting and weak refcounting to > > enable a better integration with C++ in general. If I have some > > time, one of this day, I may go at it or just write a mail about > > some of my idea on the subject. Will see that... > > > > Better to write some tests before the ideas. Many things that seem > nice are not that simple. Yesterday I was faced with 2 examples: > - ref widget of elm. Unleash hell if you shutdown with that ref > taken. > - evas_free() does not force deletion, just unref, can bring > problems if ref remains after shutdown
May this be the same topic as my email with title: "Edje/Elm External crash" from Wed, 12 Dec 2012 23:15:33 +0100 where I got no answer? :-) -- Technical Blog <http://andreasvolz.wordpress.com/> ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
