Quote:Original post by Raghar
The best idea is either disalow plugin architecture completly, or run the plug in in sandbox mode, and NEVER allow plugin to allocate, or free memory directly.

Nope. The best idea is to make sure all plugins are linked with the same CRT. That's how all modern C++ based plugin systems work. Some do in fact wrap allocators (usually through global new/delete operators). But this is not so much to avoid the CRT problem (which doesn't exist if dynamically linking with the CRT), but more to be able to manage allocations internally through a custom allocator.

Quote:Original post by Raghar
Well it's not like a programer always have the choice. Companies could disappear, and recompilation of theirs plugins is impossible. Users could create theirs own plugins, and then...

And ? All major plugin based applications require a certain compiler to engineer their plugins. It's part of the SDKs system requirements. As long as everybody adheres to these requirements, everything will work out just fine. Of course, there won't be binary compatibility between an old plugin and a new version of your application/game. But since the slightest modification to your plugin interface in itself will require a recompile anyway, it doesn't make any difference at all.

Quote:Original post by Yann L
All major plugin based applications require a certain compiler to engineer their plugins. It's part of the SDKs system requirements. As long as everybody adheres to these requirements, everything will work out just fine. Of course, there won't be binary compatibility between an old plugin and a new version of your application/game. But since the slightest modification to your plugin interface in itself will require a recompile anyway, it doesn't make any difference at all.

That's not nessecarily true. For example, Firefox doesn't require a particular compiler/version for their plugins, and in fact all plugins are binary compatible for a given major release (i.e. 2.x, 3.x etc). That's because Firefox uses XPCOM as it's plugin-interface.

Windows explorer extensions are the same, too. Explorer uses COM for it's plugin architecture and so it doesn't require a particular compiler/version either (as long as the compiler you chose can compile COM components).

It depends on the host application. For a game, it's OK to require a particular compiler/version because a game doesn't last especially long on the market (not compared to Windows Explorer, for example). Also, with a game the host application itself doesn't typically get updated all that much. It was quite a pain when Firefox 3.x was first released and we had to wait for all the add-ons to get recompiled for them to work -- imagine if they broke with each minor release as well!

In my personal opinion, a component-based plugin architecture makes more sense than a OO-one anyway (i.e. implementing an interface rather than inheriting from a base class). You can provide a "default" implementation of the interface for your plugin authors to base their work, but I think that would be optional...

COM and its various ripoffs are things apart. They surely are an alternative to standard OO inheritance interfaces. Some people like them, others hate them. I'm part of the latter group, but YMMV of course. And FF certainly isn't the best example, if you consider the really bad compatibility problems they have from one version to the next...

Maybe I wasn't clear enough about my points being more about highly closed commercial systems that operate in a strictly controlled development environment, which I am a very strong proponent of. From personal experience, I grew really sick of the constant compatibility problems you run into when trying to make different compilers cooperate on large projects ("Your SDK doesn't work with my gcc 4.3.5 beta nightly build 8765 ! Why ?!"). You want to write plugins for my software ? Well, you'll use MSVC 2008, and period. This made development much easier and more consistent.

Games usually fit very well into the above category, as well as applications such as AutoCAD, 3DS Max, Photoshop, etc. Essentially, you (the developer) decide what kind of dev tools your plugin writers will have to use. This has a lot of advantages, especially when it comes to quality control, consistency, support and developer licensing / DRM. It also offers easy and clean ways to extend functionality through natural OO constructs, usually without major restrictions in complex data types you can throw around your modules (STL and Boost types come to mind). While you can do similar things with COM type interfaces, it can be much harder to achieve. And it's not as flexible, at least in my opinion.

Of course this means that you force a certain language (C++ in this case) on your plugin writers. Whether that is a disadvantage or not depends on your particular situation.

In the end, it's mostly individual preference.

Oh, and using a closed system as described above usually helps to keep the open source hippies out, which I find an invaluable advantage [wink]

Right, as I said it depends on the host application. I was just trying to counter the "all major plugin based applications" comment since obviously Firefox and Explorer are two notable plugin-based applications which don't require a particular compiler/version.

In any case, this is getting somewhat off-topic now, but I certainly agree with you that requiring the same compiler and CRT (and dynamically linking to it) make life a lot easier on a number of fronts...

Quote:Original post by Codeka
In any case, this is getting somewhat off-topic now, but I certainly agree with you that requiring the same compiler and CRT (and dynamically linking to it) make life a lot easier on a number of fronts...

Especially since the thread starter seems to be a hobbyist. I think both arguments apply to certain products that are used over the world and extended by alot of developers.
But when it comes to non-professional programs, I would really suggest dynamically linking to the runtime library, it's easier to work with the dynamic version...