[omniORB] strange behavior of '_this()' method

[Michael Kilburn]

On Thu, Mar 26, 2009 at 11:58 AM, Michael <omniorb at bindone.de> wrote:

> I totally agree with Nigel, in six years of using CORBA I never wrote a
> server application that didn't create its own POAs. No offense, but
> quite frankly I think that argument is flawed ("we are the only ones
> writing complicated software and one day it will hit us"). This is
> exactly why you need coding guide lines. So, if you're concerned that
> people will break code by using _this in the wrong way, enforce the
> usage of a wrapper function that throws when _this is called on an
> inactive object. Make that an inline function and the performance
> penalty will be neglectable.


Oh, that is for sure... I'll try to invent some C++ mechanism that will make
it harder to break.


You can then include a check for "_this" in
> your QA process (e.g. grep "_this" *.C *.h).


Our "QA process" would surprise you :-D . Essentially it is absent. entire
product is single threaded, well divided in parts and people working on it
are experienced C++ developers, those that learn are under close supervision
(but most of them are not particlarly exposed to every intricacy of CORBA,
esp considering that we switched from Orbacus to omniORB quite recently --
it took ~six month of work, and I had to learn CORBA in a very short time).



> Quite simple. It's pretty
> much like every piece of code, people will make mistakes, as a project
> leader/manager it is your responsibility to define best practices and
> setup a QA process.


I disagree -- it turned out that _this()'s behaviour is quite twisted... One
thing when developer screws with nicely designed framework or library and
another one -- when he steps on rakes of something like _this(). (pun
intended :) )



> Especially in C++ it's all about your people not
> doing stupid things (like enforcing use of smart pointers, RAII
> principle etc.). Developers will always find ways to break code.


No, if they are experienced and tools they are using well-thought out and
well-designed.



> Did you
> ever consider using a different Middleware/RPC solution, because the
> CORBA C++ mapping is pretty complicated (once you master it it's simple,
> but from my experience training people is a nightmare)?


Agree, CORBA keeps surprising me... And after all I've learned I am not sure
that CORBA is a necessary a good thing -- it's complexity, myriad of
non-obvious details outweight many of it's benefits. I am sure those who
make decisions on that level considered other alternatives to CORBA, but
risks & costs of switching to something else are (probably) in CORBA's
favor.


I would never
> again setup a project based on CORBA if I knew that many developers will
> have to maintain the codebase.
>

:-) Sorry, it won't work here -- we have a very large in-house product that
is under constant development for last 10 (or maybe 15?) years. About every
month or two we have a new release. People come and go regularly, and I am
just one of them. We are saved by the fact that product is single-threaded
(on purpose) and not many want to touch communication layer (that uses
CORBA)...

-- 
Sincerely yours,
Michael.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20090331/b8ac1d43/attachment.htm