orbitcpp-list

[orbitcpp-list] STL-based IDL compiler frontend

[ERDI G. <ca...@ca...>]

Hi,

I'm looking for a non-standard, STL-based IDL compiler frontend. Is there
such a frontend available? Ideally, it would create both standard methods
and some forwarder methods using STL (that is, you would forward from STL
to standard in the stub class, and from standard to STL in the skeleton
class):
interface Foo
{
	void bar (in string str);
}

would create:

class Foo_Stub
{
	void bar (char* str) { /* Standard ORBit magic */ };
	void bar (string str) { bar (str.c_str ()); };
}

class Foo_Skel
{
	virtual void bar (char* str) { return bar (string (str)); };
	virtual void bar (string str) = 0;
}


-- 
   .--= ULLA! =----------------------------.  finger ca...@ca...
   \      http://cactus.rulez.org           \   for PGP public key
    `----------= ca...@ca... =--'
If this had been a real emergency, we would have all fled in terror, and you would not have been notified.

Re: [orbitcpp-list] STL-based IDL compiler frontend

[Andreas K. <ak...@ix...>]

On Sun, Oct 15, 2000 at 12:28:55PM +0200, ERDI Gergo wrote:
> Hi,
> 
> I'm looking for a non-standard, STL-based IDL compiler frontend. Is there
> such a frontend available? Ideally, it would create both standard methods
> and some forwarder methods using STL (that is, you would forward from STL
> to standard in the stub class, and from standard to STL in the skeleton
> class):
> interface Foo
> {
> 	void bar (in string str);
> }
> 
> would create:
> 
> class Foo_Stub
> {
> 	void bar (char* str) { /* Standard ORBit magic */ };
> 	void bar (string str) { bar (str.c_str ()); };
> }
> 
> class Foo_Skel
> {
> 	virtual void bar (char* str) { return bar (string (str)); };
> 	virtual void bar (string str) = 0;
> }

Implementing this for using "string" and "char *" alternatively would
be no problem with our IDL compiler, however I do not think this is
in any way a good idea.

Implementing the multi-signature approach is IMHO even less a good idea,
because
a) in the skeleton, bar(char *) cannot be implemented without
stubbing bar(string) --> no real compatibility.
b) imagine the following IDL: 
"baz(string,string,string,string,string,string)".
would you want 64 methods for implementing every conceivable
combination? *BLOAT*

Please think about just sticking with char *'s. Standards exist
for a reason, and in this particular case, the code overhead
on your side is really minimal.

bye
andy
-- 
Your mouse has moved. Windows needs to be restarted to reflect
this change. Reboot now?                                [ OK ]