• 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
incertia

COM as a way to implement the use of STL containers across a DLL

15 posts in this topic

So using STL in a class that will be exported by a DLL is a big no-no due to problems with differently compilers packing data in different formats. With that in mind, would COM be a viable option for secretly using STL containers in an interface/class that you wish to share across a DLL? That way, the compiler only needs to know of the methods of the interface and not how the data is packed.
0

Share this post


Link to post
Share on other sites
As long as the implementation is completely hidden and the interface contains only legal types, then it shouldn't be a problem.
1

Share this post


Link to post
Share on other sites
I think COM style interface is the best (at least it's best to me) to work cross DLLs.
It has two dominant advantages,
1, Binary compatibility. There is only function pointers in the interface with fixed layout (one pointer after another).
2, Safe memory management. No explicitly free function, all resources are freed by calling "release". The object implementing the "release" function knows how to free itself safely.
1

Share this post


Link to post
Share on other sites
[quote name='SiCrane' timestamp='1331000113' post='4919652']
As long as the implementation is completely hidden and the interface contains only legal types, then it shouldn't be a problem.
[/quote]

Would something like std::string be a legal type? Or should I resort to C types only?

EDIT: I should be able to return COM interface pointers, correct?
-1

Share this post


Link to post
Share on other sites
[quote name='incertia' timestamp='1331004083' post='4919665']

Would something like std::string be a legal type? Or should I resort to C types only?

EDIT: I should be able to return COM interface pointers, correct?
[/quote]
Don't pass any STL classes across DLLs.
Different DLLs may be compiled with different STL.
Yes, you can return COM interface pointers, and it's the safe way.
0

Share this post


Link to post
Share on other sites
How about operator overloading within a COM interface?

EDIT: If a function is going to receive varying number of string arguments, I should be creating something like IArgumentList and passing that to a function instead of using std::vector<const char*> right?
0

Share this post


Link to post
Share on other sites
You are right on the argument list thing.

For operator overloading, in COM, forget any C++ specified features, such as operator overloading, template, etc.
I suggest you read some COM books such as "inside COM", "essential COM" to see how interface works.
-2

Share this post


Link to post
Share on other sites
[quote name='wqking' timestamp='1331007570' post='4919672']
You are right on the argument list thing.

For operator overloading, in COM, forget any C++ specified features, such as operator overloading, template, etc.
I suggest you read some COM books such as "inside COM", "essential COM" to see how interface works.
[/quote]

I would if I could. My dad just recently got me a few dx11 books, and he won't be too happy seeing me requesting other books when I haven't finished the dx11 ones yet. Oh the joys of high school. So what kind of free resource would be the best at instructing one the ways of COM?

As a final question for this post, when I return references to an interface via a get function, the get method should call AddRef right?
0

Share this post


Link to post
Share on other sites
[quote name='incertia' timestamp='1331009223' post='4919675']

I would if I could. My dad just recently got me a few dx11 books, and he won't be too happy seeing me requesting other books when I haven't finished the dx11 ones yet. Oh the joys of high school. So what kind of free resource would be the best at instructing one the ways of COM?

As a final question for this post, when I return references to an interface via a get function, the get method should call AddRef right?
[/quote]

http://en.wikipedia.org/wiki/Component_Object_Model
Also google "c++ Component Object Model", without quote marks.

Since you are only using the COM idea than COM itself, you don't need to go too deep in COM.
Just learn about the interface, object life management, that's enough.
I'm not sure if COM is still as popular as before .Net was born.
-1

Share this post


Link to post
Share on other sites
Read this: [url="http://chadaustin.me/cppinterface.html"]http://chadaustin.me/cppinterface.html[/url]
1

Share this post


Link to post
Share on other sites
[quote]
[left]As long as the implementation is completely hidden and the interface contains only legal types, then it shouldn't be a problem. [/quote]

There's nothing stopping you from using illegal types in your interface, you've just got to be careful about managing the types whose data size may change.[/left]

[code]
class Foo
{
public:

EXPORT Foo();
EXPORT virtual ~Foo();

EXPORT void func(const char* str);
inline void func(const std::string& str) { func(str.c_str()); }
};
[/code]

This will partially work (in that you can create and use the class, but you can't use it as a base class, and it will generate a warning)

[code]
class Foo
{
public:

EXPORT Foo();
EXPORT virtual ~Foo();

EXPORT void func(const char* str);
inline void func(const std::string& str) { func(str.c_str()); }

EXPORT const char* getStr() const;

private:
std::string m_str;
};
[/code]

[quote]
[left][font=helvetica, arial, verdana, tahoma, sans-serif][size=2][color=#282828]So using STL in a class that will be exported by a DLL is a big no-no due to problems with differently compilers packing data in different formats. [/quote][/color][/size][/font]
[font=helvetica, arial, verdana, tahoma, sans-serif][size=2][color=#282828]It's got nothing to do with compiler packing, it's simply the inability to guarantee the size of the CSL containers (due to additional debugging nonsense). [/color][/size][/font]

[quote][/left]
[left][color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif][size=3]I think COM style interface is the best (at least it's best to me) to work cross DLLs.[/quote][/size][/font][/color][/left]

[left]I can't say I agree with you.... ;)[/left]

[left][quote][/left]
[left][color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif][size=3]I'm not sure if COM is still as popular as before .Net was born. [/quote]
It was never popular ;)[/size][/font][/color][/left]


[quote]
[left][color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif][size=3]For operator overloading, in COM, forget any C++ specified features, such as operator overloading, template, etc.[/size][/font][/color][/left]
[/quote]
[left]Why do you say that? There's nothing stopping you using template specialisations and operator overloading with COM or dlls.[/left]
0

Share this post


Link to post
Share on other sites
[quote name='RobTheBloke' timestamp='1331318492' post='4920734']
This will partially work (in that you can create and use the class, but you can't use it as a base class, and it will generate a warning)
[/quote]
Did you notice that the OP mentioned different compilers? Standard library classes do not have a single implementation. std::string could be implemented with the small string optimization on one compiler and not with another. Try using a DLL with the first implementation with a different compiler is completely undefined.

[quote]
[left][font=helvetica, arial, verdana, tahoma, sans-serif][size=2][color=#282828]It's got nothing to do with compiler packing, it's simply the inability to guarantee the size of the CSL containers (due to additional debugging nonsense). [/color][/size][/font]
[/quote][/left]
[left]Again, size is only part of the problem. Standard library containers can have fundamentally different implementations with different compilers.[/left]
1

Share this post


Link to post
Share on other sites
[quote name='RobTheBloke' timestamp='1331318492' post='4920734']
"I think COM style interface is the best (at least it's best to me) to work cross DLLs."

I can't say I agree with you.... ;)

[/quote]
Please explain why you don't agree, what's the reason you don't agree.
It doesn't help to just say "I can't say I agree".
It will help if you say "I don't agree because point 1, point 2, point 3", etc.
If there is no any points, why you don't agree?

And I emphasized "at least it's best to me", why don't you agree that I think it's best to me?
I don't think I need your agree on what I can think of.

[quote name='RobTheBloke' timestamp='1331318492' post='4920734']
"I'm not sure if COM is still as popular as before .Net was born."

It was never popular ;)

[/quote]

Is DirectX popular? It's using COM interface.
Is Windows popular? It's full of COM components.
Please give data to support your opinion "it was never popular".
Or please give me your definition for "popular".
I thought it's popular is because it's in any copy of Windows since Win2000 (or maybe Win95, not sure), and Windows is the most popular OS in the planet.
What do you think about "popular"?

[quote name='RobTheBloke' timestamp='1331318492' post='4920734']
"For operator overloading, in COM, forget any C++ specified features, such as operator overloading, template, etc."

Why do you say that? There's nothing stopping you using template specialisations and operator overloading with COM or dlls.

[/quote]
OK, please give me an example you use template via COM interface.
COM is not only for C++. You can use COM in C, Delphi, etc.
I have much interesting if you can tell me how to use C++ template and operator overloading in COM interface by C and Delphi.

Finally, is it you down vote me that much? If it is, please give your reason, otherwise, you are offending me. Down voting others for no reason is always offending.
If you didn't down vote me, that's OK. I just want to know why I got that lot of down vote.
I down voted your that reply because it's full of misleading and offending. You are denying others' opinion without any reason, that's not fine in a public forum.
OK, I gave you the reason that why I down vote you, now it's your turn to give your reason if you really down voted me.

Thanks.
-2

Share this post


Link to post
Share on other sites
[quote='SiCrane' timestamp='1331326585' post='4920756]Did you notice that the OP mentioned different compilers?[/quote]

Yes, I did notice. Look again at my first solution. Find the flaw if you can..... I dare you! [img]http://public.gamedev.net//public/style_emoticons/default/tongue.png[/img]
0

Share this post


Link to post
Share on other sites
[quote name='wqking' timestamp='1331362050' post='4920845']
Is DirectX popular? It's using COM interface.[/quote]
Cars are popular. Cars emit exhaust gas. Exhaust gas is not popular. Just because component A, that is popular, uses component B internally doesn't mean B is popular. Also the word 'popular' can be used differently. Is something populair if many people use it, even if they still hate it? Lots of people visit the dentist just as often as they go on holiday, does that make going to the dentist popular? I don't think DirectX is popular, but many people choiced it as their API to build their game engine upon. That doesn't mean they admire it's quality OO principle though (at least I don't think many developers admire the C-with-classes type of OO that Microsoft has been using for way to long).
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