15 replies to this topic

[incertia]

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.

[SiCrane]

As long as the implementation is completely hidden and the interface contains only legal types, then it shouldn't be a problem.

[wqking]

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.

[incertia]

As long as the implementation is completely hidden and the interface contains only legal types, then it shouldn't be a problem.

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?

[wqking]

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?

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.

[incertia]

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?

[wqking]

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.

[incertia]

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.

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?

[wqking]

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?

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.

[Martins Mozeiko]

Read this: http://chadaustin.me/cppinterface.html

[Shannon Barber]

If you're willing to go as-far-as COM you may as well just switch to C#.

[RobTheBloke]

As long as the implementation is completely hidden and the interface contains only legal types, then it shouldn't be a problem.

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.

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()); }
};

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)

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;
};

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.

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).

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.... ;)

I'm not sure if COM is still as popular as before .Net was born.

It was never popular ;)

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.

[SiCrane]

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)

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.

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).

Again, size is only part of the problem. Standard library containers can have fundamentally different implementations with different compilers.

[wqking]

"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.... ;)

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.

"I'm not sure if COM is still as popular as before .Net was born."

It was never popular ;)

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"?

"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.

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.

[RobTheBloke]

Did you notice that the OP mentioned different compilers?

Yes, I did notice. Look again at my first solution. Find the flaw if you can..... I dare you!

[MichaBen]

Is DirectX popular? It's using COM interface.

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).