On Fri, Apr 9, 2010 at 5:46 PM, OvermindDL1 wrote:

First, it is best to give is a complete, but simplified example that

Supposed to be "First, it is best to give a complete, but simplified example that"

2010/4/13 Fábio 'Petrucio' Stange :

Ok, here's simpler code that demonstrates the same problem:

#include #include

void FooBar(boost::function0<void> callback) {  callback(); }

void CallbackImpl() {  cout << "Called back ok\n"; }

int main(int argc, char* argv[]) {  FooBar(CallbackImpl);  return 0; }

I'm stuck with Builder because we already have a major system built with it (don't look at me, it was coded by Mechanical and Automation Engeneers, I was hired later to deal with it, so you can guess the size of my problem). I plan on porting it to Visual Studio, but finding the time and resources to do that is probably years away. And I probably won't be here by then.

Well trying to compile that example verbatim results in: main.cpp(2) : fatal error C1083: Cannot open include file: 'iostream.h': No such file or directory Fixing that to be iostream and not iostream.h results in: main.cpp(9) : error C2065: 'cout' : undeclared identifier Fixing that to be qualified as it should be results in: main.cpp(12) : warning C4100: 'argv' : unreferenced formal parameter main.cpp(12) : warning C4100: 'argc' : unreferenced formal parameter But it otherwise works and runs just fine. Based on the error you posted in your first post, that is perfectly valid code, not sure what could be upsetting it, and not sure how it could be fixed without slowing down the code (which would be fine if you do not mind that), but there might still be further issues, especially if this compiler has issues with something as simple as boost::function. I do not see how this could easily be worked around, that compiler is unsupported by just about everything in existence due to how non-compliant it has always been (it even makes VC6 look intelligent by comparison), but perhaps just a plain function pointer would work fine if you do not need the enhanced capabilities of boost::function?

2010/4/13 Fábio 'Petrucio' Stange :

...

2010/4/13 Fábio 'Petrucio' Stange :  But it otherwise works and runs just fine.  Based on the error you posted in your first post, that is perfectly valid code, not sure what could be upsetting it, and not sure how it could be fixed without slowing down the code (which would be fine if you do not mind that),

I don't mind that.

Well the initial error appears to just be instancing problem. Might put a static bool set to false on init, test it after the fact, and if false set it to true and also set the struct above it, that incurs obvious overhead, and as stated, there might be more problems as well. 2010/4/13 Fábio 'Petrucio' Stange :

...

but there might still be further issues, especially if this compiler has issues with something as simple as boost::function.  I do not see how this could easily be worked around, that compiler is unsupported by just about everything in existence due to how non-compliant it has always been (it even makes VC6 look intelligent by comparison), but perhaps just a plain function pointer would work fine if you do not need the enhanced capabilities of boost::function?

Yes, I've been using function pointers for awhile, but boost::function does give me some extra leeway in defining callback functions inside classes which I very much would like to use.

If a function requires a void(*callback)() function pointer, is there any other way I can pass it a function declared void FooBar::Callback() {} without this function being a static member? That's what I was trying to get boost::bind and boost::function to do.

Then you could do something like: struct voidCallbackHandler0 : private boost::noncopyable { // do not need the boost::noncopyable part if you add a private copy constructor to prevent accidental copying virtual ~voidCallbackHandler0() {} virtual void operator()() = 0; } boost::shared_ptr<voidCallbackHandler0> voidCallbackHandler0Ptr; // if shared_ptr does not work for you either, handle your own reference counting in voidCallbackHandler0 itself and make *SURE* to only pass around pointers, or no reference counting but just be sure to not leak memory and so forth And use it like: #include #include void callThing(voidCallbackHandler0 callback) { (*callback)(); } class FooBar { public: void Callback(){std::cout << "Called back ok\n";} } struct myFooBarCallbackCaller : public voidCallbackHandler0 { FooBar *self; void operator()() {inst->Callback();) } // Or hey, make a callback inline struct myInlineCallbackCaller : public voidCallbackHandler0 { void operator()() {std::cout << "Inline called back ok\n";) } int main(int argc, char* argv[]) { voidCallbackHandler0Ptr callback1(new myFooBarCallbackCaller); FooBar fb; callback1.self = &fb; FooBar(callback1); // or many other ways: voidCallbackHandler0Ptr callback2(new myInlineCallbackCaller); FooBar(callback2); return 0; } Obviously need to customize them for each type of callback you will need, and there are *much* better ways to do this, more reusable, and faster, but that requires decent template support (unsure how well that compiler works), and you pretty much end up remaking boost function/bind anyway. This is not the fastest or cleanest way, but it should work, and you only need memory management if *any* of the subclasses can hold state (the 'self') and/or they need to be held longer then the scope of the function call.

2010/4/13 Fábio 'Petrucio' Stange :

...

Well the initial error appears to just be instancing problem.  Might put a static bool set to false on init, test it after the fact, and if false set it to true and also set the struct above it, that incurs obvious overhead, and as stated, there might be more problems as well.

Yes, that was the first thing that ocurred to me; the problem is, how the heck do I initialize vtable_type? I don't know what's really inside it, and I've taken a beating trying to follow up it's declarations, it's quite nasty.

    static bool _vtable_init = false;     static vtable_type stored_vtable;     if (!_vtable_init) {       stored_vtable // ????????? What now?       _vtable_init = true;     }

I am not sure what it contains off hand (not home), but if you poke me later to remind me then I can take a look and give you some real non-pseudo code. 2010/4/13 Fábio 'Petrucio' Stange :

...

Obviously need to customize them for each type of callback you will need, and there are *much* better ways to do this, more reusable, and faster, but that requires decent template support (unsure how well that compiler works), and you pretty much end up remaking boost function/bind anyway.

It has half-decent (hmmn) template support, I use it infrequently but I do use it, and boost::shared_ptr and the likes frequently, they work fine. But adding more code to maintain, specially templated, is the last thing I want to do now, so I'll stick with the static function pointers if I can't get function_template.hpp to compile.

Is there really not a newer version of that compiler that actually has decent support for the standard yet? 2010/4/13 Fábio 'Petrucio' Stange :

Anyway, thanks *a lot* for the time you've taken to answer me so far.

It is a nice distraction, been so busy with non-programming things lately (finally clearing up), it is good to delve back into it. :)