Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 12 May 2007
Offline Last Active Mar 08 2013 03:06 AM

Topics I've Started

Exporting template instantiations to DLL

07 September 2011 - 09:18 PM

I have the following code:

template <class T>
class __declspec(dllexport) MyTemplate1


template <class T>
class MyTemplate2


template MyTemplate1<int>;
template __declspec(dllexport) MyTemplate2<int>;

In dependency walker, I can see that this exports the symbol "??4?MyTemplate1..." There is no export for MyTemplate2.

In my case, I have multiple projects that can be built as a single monolithic .exe or into a small .exe with a collection of DLLs. I want multiple projects to be able to export different instantiations of the template. I have no need to "hide" the templates implementation code from downstream projects.

I cannot use the syntax in MyTemplate1 because each project has its own define for __declspec(...) (i.e. RENDERER_API, FRAMEWORK_API, etc.). If I used the syntax of MyTemplate1, only one of the DLLs could ever export the template. I was really hoping the syntax I am using in MyTemplate2 would work, but this sample demonstrates that it does not.

I understand that DLLs and templates do not play well together. I also understand that __declspec(...) needs to be a define, and that downstream projects will need to extern the template instantiation. In my actual project, I have done this.

What I'm asking specifically is this: Is there a way to write MyTemplate2 such that it is declared once but can have different instantiations exported by different DLLs?

Thanks in advance!

Implementing a pure virtual function by inheriting it from a base class

29 April 2011 - 08:35 AM

I'm writing a library that is exposed as a DLL, so I am using the standard pImpl method with exposed factory functions to create the Impl objects. I'd like for some of the common "Impl" functionality to be in a base class, and have those implementation satisfy the exposed interface. So, I have some code that's like this:

struct InterfaceA
  virtual void fn() = 0;

class ClassA
  void fn() { }

class ClassB : 
  public ClassA,
  public InterfaceA


I expected that this would work, however, I get the following:

1>****(38) : error C2259: 'ClassB' : cannot instantiate abstract class
1>        due to following members:
1>        'void InterfaceA::fn(void)' : is abstract
1>        ****(19) : see declaration of 'InterfaceA::fn'

I know that I could include something in class B like

void fn() { ClassA::fn(); }

but at that point I might as well just use composition rather than inheritance. While in general I'm a huge fan of composition, I wanted to use inheritance so that the "ClassB" classes have only the unique code in them (would make the code pleasant to read.) Is there a way to make ClassB automatically use the method in ClassA to satisfy InterfaceA?

My question is exactly the same as http://stackoverflow...-abstract-inter, but I didn't see a real "solution" to my question of not having to add a proxy function. Also, if there is a good reason why this is not possible for a compiler to figure out, or why you wouldn't want this behavior, I'd love to know.

[C++] RTTI Issues

15 May 2008 - 06:26 AM

I have read about many issues associated with RTTI. People go back and forth on it as far as performance, but as I already use exceptions, I don't much care since I'm already eating most of the performance/memory penalty for it. What I'm very concerned about is the behavior across DLLs. I understand that if I use typeid(T) on two different types that live in different DLLs, I can get matching type_info pointers when the types are not the same. This issue I only know about because I was lucky enough to stumble across it in another post, and even when actively looking for these sorts of RTTI shortcomings I don't get very relevant results. So I have some questions: - Can typeid(T) return non-matching type_info* structs if the types are the same but in two DLLs? - Is there a way to tell what module (i.e. dll/so) a type_info* is coming from at runtime based on the pointer address? - Before the compile, can I tell by looking at the code what module a type will belong to? Is it possible to have the type belong to multiple modules? - Are there other issues I should be aware of similar to these? And are there ways to mitigate them? I read about the fallback to string comparisons that can be used: http://lists.boost.org/Archives/boost/2006/10/111781.php Thanks

Linker cannot find vftable for class

30 January 2008 - 11:02 AM

I am trying to compile the LuaScriptModule class into my current project. LuaScriptModule comes with CEGUI but is optional and therefore not compiled in with the CEGUI binaries. I am using Ogre 1.4.5 which includes CEGUI (but again not the LuaScriptModule). I have Lua 5.1 in my project. Everything is compiling ok, but when I try to link I get one single error: CEGUILua.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) const CEGUI::LuaScriptModule::`vftable'" (__imp_??_7LuaScriptModule@CEGUI@@6B@) This error comes up whether I try to instantiate the class or not. The CEGUI binaries included with ogre require me to both link a .lib file and have a DLL present. To my understanding, vftable indicates the virtual function table, which is something that should be getting generated by my compiler. I am using visual studio 2005 with options: Multithreaded DLL, with RTTI and exceptions on. Does anyone have any suggestions? I am sure there is some information that I'm not including that is necessary to solve this, so please ask and I'll respond as quickly as possible.

[PhysX] Syncing PhysX/Novodex scenes over network

12 January 2008 - 04:31 AM

I have a rough version of my network code working. Every so often I spam position and orientation data to the client. The client applies this information with setGlobalPosition and setGlobalOrientationQuat. Unfortunately, my prototype immediately crashes somewhere deep in the PhysX dll. If I comment out both of the set lines, the program runs fine (Albeit with no network synchronization) The PhysX docs say: "One should exercise restraint in making use of these (the setGlobal* ) methods." ... "When briefly moving dynamic actors, one should not: - Move actors into other actors, thus causing interpenetration (an invalid physical state) - Move an actor that is connected by a joint to another away from the other (thus causing joint error) - When moving jointed actors the joints' cached transform information is destroyed and recreated next frame; thus this call is expensive for jointed actors. " With my current solution, this cannot be guaranteed. Does anyone know if there's another way to manually correct object positions in PhysX? Kinematic actors look like they would work, but they don't look like what I need. Am I wrong on that? Also I know for client side prediction, rewinding time is important - is there a simple way to concisely store PhysX object state so I can rewind to them and apply them later? Thanks!