Alo Sarv
lead developer

Donate via
MoneyBookers

Latest Builds

version 0.3
tar.gz tar.bz2
Boost 1.33.1 Headers
MLDonkey Downloads Import Module Development
Payment completed
Development in progress.
Developer's Diary
irc.hydranode.com/#hydranode

Thursday, December 16, 2004

Some improvements in EHSv2

For quite a while I was cursing and fighting with MSVC, which didn't seem to perform too good at template functions overload resolution. It handles it correctly in simpler cases, but fails miserably when things get complex. The exact example:
template<typename Source, typename Event>
void postEvent(Source src, Event evt) { ... }
template<typename Source, typename Event>
void postEvent(Source *src, Event evt) { ... }
For pointer types, the second version is considered "more specialized" by the standard, and should be chosen - which is done correctly by both gcc and MSVC. However:
template<typename Source, typename Event>
void addHandler(Source src, T *obj, void (T::*ha)(Source src, Event evt) { ... }
template<typename Source, typename Event>
void addHandler(Source *src, T *obj, void (T::*ha)(Source *src, Event evt) {...}
Same situation, altough more complex - gcc 3.4 handles correctly, MSVC gets confused and gives ambigoutity error :(

However, after numerous attempts to get past that (and avoid explicit template argument specifications for those functions - which was the entire point of those methods - automatic parameter deduction), I rethought the engine, and came up with significently smaller solution. After throwing out roughly 150 lines of code from the api, it got simpler, and much cleaner. Here's the files:
event.h
test-event.cpp

It handles smart-ptr-wrapped objects automatically now, w/o template specializations this time (EHSv1 used full specialization for that, which created duplicate code and was errorprone).

Event handlers removal is still a rather grey area ... it can be done explicitly (as was done in old implementation), however that's very errorprone - forget to remove your handler in destructor, and you crash the app. Boost.Signals library offers a partial solution - boost::signals::trackable-derived objects automatically get disconnected from the signals they are connected to ...

Madcat, ZzZz




Comments:
tnks man, you do a very good work, the multi p2p its the future !

tnks a lot !
 
Post a Comment



<< Home

This page is powered by Blogger. Isn't yours?