• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
harshman_chris

LNK2019:unresolved external symbol with my own dll

6 posts in this topic

So this is the error I am getting when using part of dll. There is quite a bit of code involved in this one.

 

 

I know this is a messy error mesage, sorry.

Error	175	error LNK2019: unresolved external symbol "__declspec(dllimport) public: void __thiscall ParticlesEngine::Event<class ParticlesEngine::EventData>::operator+=(class ParticlesEngine::Delegate<class ParticlesEngine::EventData> *)" (__imp_??Y?$Event@VEventData@ParticlesEngine@@@ParticlesEngine@@QAEXPAV?$Delegate@VEventData@ParticlesEngine@@@1@@Z) referenced in function "public: virtual void __thiscall TestScene::initialize(void)" (?initialize@TestScene@@UAEXXZ)	C:\Users\100312531\Desktop\Project-Seventeen\ParticleEngineProject\EngineTest\TestScene.obj	EngineTest

 

Here is all the code segements, if I am missing anything, or I need to answer a question let me know.


//TestScene.h #include <Delegate.h> #include <EventData.h> #include <Event.h> class TestScene : Scene { void OnButtonClick(EventData data); void OnButtonEnter(EventData data); void OnButtonLeave(EventData data); EventHandler(TestScene, OnButtonClick, EventData); EventHandler(TestScene, OnButtonEnter, EventData); EventHandler(TestScene, OnButtonLeave, EventData);

}

//TestScene.cpp

void TestScene::initialize()
{
button->OnClick += &EOnButtonClick;
button->OnEnter += &EOnButtonEnter;
button->OnLeave += &EOnButtonLeave;
}

void TestScene::OnButtonClick(EventData data)
{
}

void TestScene::OnButtonEnter(EventData data)
{
}

void TestScene::OnButtonLeave(EventData data)
{
}

 

 

The Code from the dll, the custom event system I am using, it is pretty straight forward.

#ifndef _EVENT_H
#define _EVENT_H

#include <vector>
#include <algorithm>
#include "Delegate.h"

#ifdef PARTICLESENGINE_DLL 
#define PARTICLESENGINE_API __declspec( dllexport )
#else
#define PARTICLESENGINE_API __declspec( dllimport )
#endif

namespace ParticlesEngine
{

	template <typename T>
	class PARTICLESENGINE_API Event
	{
		public:
			inline void operator+=(Delegate<T>* delegate)
			{
				// An object can only subscribe once
				if (find(_delegates.begin(), _delegates.end(), delegate) == _delegates.end())
				{
					_delegates.push_back(delegate);
				}
			}

			inline void operator-=(Delegate<T>* delegate)
			{
				typedef typename std::vector< Delegate<T>* >::iterator iter;
				iter i = _delegates.begin();
				while (i != _delegates.end())
				{
					if (*i == delegate)
					{
						i = _delegates.erase(i);
					}
					else
					{
						++i;
					}
				}
			}

			inline void operator()(T param)
			{
				typedef typename std::vector< Delegate<T>* >::iterator iter;
				for (iter i = _delegates.begin(); i != _delegates.end(); ++i)
				{
					(*i)->operator()(param);
				}
			}

		private:
			std::vector< Delegate<T>* > _delegates;
	};

}

#endif
#ifndef _EVENTDATA_H
#define _EVENTDATA_H

#ifdef PARTICLESENGINE_DLL 
#define PARTICLESENGINE_API __declspec( dllexport )
#else
#define PARTICLESENGINE_API __declspec( dllimport )
#endif

namespace ParticlesEngine
{

	class EventData
	{
	public:
		PARTICLESENGINE_API EventData()
		{
		}
	};

}

#endif
#ifndef _DELEGATE_H
#define _DELEGATE_H

#ifdef PARTICLESENGINE_DLL 
#define PARTICLESENGINE_API __declspec( dllexport )
#else
#define PARTICLESENGINE_API __declspec( dllimport )
#endif

namespace ParticlesEngine
{

	#define EventHandler(thisType, handler, type)\
		class __E##handler##__ : public Delegate< type >\
		{\
			public:\
				__E##handler##__ ( thisType * obj )\
				: _obj(obj) {}\
				inline void operator()( type param )\
				{\
					_obj-> handler (param);\
				}\
				thisType * _obj;\
		};\
		__E##handler##__ E##handler;

	template <typename T>
	class PARTICLESENGINE_API Delegate
	{
	public:
		virtual void operator()(T param) = 0;
	};

}

#endif
Edited by harshman_chris
0

Share this post


Link to post
Share on other sites

You are still exporting too much from the DLL.

 

The DLL boundary is well-defined.  It doesn't support templates well.  It doesn't support managed memory.

 

It is designed around a hybrid Pascal based and C based interface.

 

 

 

 

Export individual global functions, not functions from a class and definitely not templates, and only use raw memory blocks if they need to transfer memory.

1

Share this post


Link to post
Share on other sites

I am not sure I fully understand what you are saying. Are there any good tutorials that could walk me through this or is there a way I fix this problem.

 

When you say export only global functions how does that work in an OO structure? 

 

I come from a heavy C# background, I have not been using C++ for 8 months.

 

Edit:

 

I removed the PARTICLESENGINE_API from the Event class and that solved my linker issue, I know I have a long way to go with dll's any advice or tutorials would be great.

Edited by harshman_chris
0

Share this post


Link to post
Share on other sites

This article looks fairly in-depth.   There are a lot of nuanced details, so don't gloss over them.

 

The concepts behind a DLL come from the early 1980s.  You really need to understand how and why they did things back then in order to leverage DLL interfaces.

1

Share this post


Link to post
Share on other sites
This article looks fairly in-depth.   There are a lot of nuanced details, so don't gloss over them.

 

The concepts behind a DLL come from the early 1980s.  You really need to understand how and why they did things back then in order to leverage DLL interfaces.

 

Thanks

0

Share this post


Link to post
Share on other sites

Export the specialisation.....

 

[code]
template class PARTICLESENGINE_API Event<EventData>;[/code]

 

or export the specialised funcs manually,

 

[code]
template PARTICLESENGINE_API Event<EventData>::Event();
template PARTICLESENGINE_API Event<EventData>::operator () (EventData p);[/code]

 

.... but make sure you always export the ctor/copy ctor/dtor if you go down that route.

 

You probably don't want to be exporting template classes like this though. Those inline operators cannot be inline, they access internal data. Pure virtual classes do not need to be exported. Exporting an empty constructor is just plain silly. I somewhat suspect you may find your design to be a little bit annoying when it comes to using it with a DLL though. I'd probably be inclined to suggest nice simple, clean, fully encaspulated C++ objects at the core DLL layer, with templates as a way to quickly derive new classes from a concrete base type if needed.

 

frob is talking about using dlsym/GetProcAddress to extract the DLL symbols manually, which will need C (or C++ name mangling and some ASM). If you are using an import library (i.e. linking to a .lib), then the name unmangling is handled for you. Understanding the C aspects is vital to fully understanding the C++ nuances.

 

Generally templates are much easier to deal with if they're in a static library. As part of a DLL interface, they tend to cause lots of annoying linking problems (as you are finding out)

0

Share this post


Link to post
Share on other sites

Thanks, I may consider a static library, its just a little foreign to me from my C# background where all of this stuff was entirely handled for me.

 

I am not two worried about getting it perfect right now, next year in school I have a Game Engine course which should help clear up all this stuff.

 

A side question, how do I step into my dll in visual studio 2010, is there a way?

 

There is a pdb file generated, along with the dll, but my output says it cannot find it.

Edited by harshman_chris
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0