Re: Proposed plugin API for GCC

[Romain Geissler <romain dot geissler at gmail dot com>]

Hi

Le 30 mars 2012 à 06:18, Ian Lance Taylor a écrit :

> I would recommend grouping functions by category, and making each
> category be a struct with a set of function pointers.  That will give
> you a namespace, and will greatly reduce the number of external names in
> the API.
> 
> Ian

Using structs with some sets of function pointers may break compatibility
between minor release.

Imagine i've got the following struct publicly exported in 4.7.1 :

struct GCC_plugin_tree_functions{
	GCC_plugin_tree_code (*get_code)(GCC_plugin_tree tree);
	bool (*is_used)(GCC_plugin_tree tree);
}

Now some plugin writer needs to know if a tree is a constant. We add it in 4.7.2 :

struct GCC_plugin_tree_functions{
	GCC_plugin_tree_code (*get_code)(GCC_plugin_tree tree);
	bool (*is_constant)(GCC_plugin_tree tree);
	bool (*is_used)(GCC_plugin_tree tree);
}

We insert is_constant between get_code and is_used to reflect the actual
flag order defined in tree_base. But if we proceed that way, a plugin will
have to be rebuild with every gcc release, even if the plugin API is fully
backward compatible (ie we only added new feature without changing the
old ones).

Anyway, you're suggestion to group functions in common names, that's just
C++ motto. May the eventual plugin API in C++ (independently from internals
being C++ or not) ?

Romain Geissler