New IDL C++ mapping using STL
Wil Evers
ORBs besides MICO, I'm posting this article to comp.object.corba,
suggesting this thread be continued in the newsgroup. ]
On the MICO development mailing list, Michi Henning wrote:
> On Mon, 19 Jul 1999, Cathy James wrote:
> > Perhaps there's some way that we could write efficient
> > wrappers that would allow developers to write code
> > against a standard STL-based API, while hiding the
> > "true" standard CORBA C++ mapping. Then any code written
> > against the wrappers could be ported to any compliant ORB
> > just by porting the wrapper code.
> This is the approach of "least resistance" and OK as an
> interim step. Longer-term, I would prefer a mapping
> that directly goes from C++ to the ORB native API, instead
> of via an intermediate layer, simply for
> efficiency reasons.
Well, your book seems to suggest otherwise :-). Here's a quote from the
introduction of chapter 6:
"It is possible to layer a slower but more convenient
mapping on top of a faster but less convenient one, but
we cannot layer a fast mapping on top of a slow one.
Favoring a mapping that is fast but less convenient lets
the OMG and ORB vendors add other options, such as code
generation wizards, later."
Seriously though, let's not forget how the current OMG-standard mapping
came about. Personally, I don't believe an alternative, easier-to-use
CORBA to C++ mapping using the STL should be a paper design.
IMHO the best thing is to have some working prototype implementation, which
would allow the new mapping to evolve based on true implementation
experience and user feedback. If such a prototype is designed to run on
top of the existing OMG-standard mapping, it will be far easier to make it
work with existing ORBs. With some care, it would even be possible to have
the old and new mappings coexist peacefully within the same program.
Once the dust settles, we can all see whether the alternative mapping has
gained enough acceptance to justify standardization by the OMG, perhaps not
as a replacement of the current one, but as a separate standard. If that
happens, I would expect ORB suppliers to start supporting it directly,
removing the need for an intermediate layer.
> > What are everyone else's thoughts on this? I think
> > that the choice of "char *" for IDL "string" was a
> > really terrible decision. Compliance of C++ code with
> > an old C mapping is much less
> > important than ease of implementation and cleanliness.
> Hmmm... I don't like the mapping to char * either.
> However, a mapping to string was not an option at the time.
> The C++ mapping was produced long before there was such a
> thing as an ANSI string class. All that was known was
> that there would likely be such a class in standard C++
> in the future, but not what it would look like.
However, the mapping from string to char * has one virtue: for 'in'
parameters, it can be implemented without any data copying, simply as a
pointer to a segment of the input message buffer. The same can be done for
'in' parameters that are sequences of basic types.
None of the C++ standard library containers can do that; they all use one
or more dynamically allocated memory buffers which are owned and ultimately
freed by the container object. Therefore, one of the fundamental decisions
any new mapping must fix is whether the zero-copying optimization must be
supported. If so, that mapping needs to define its own set of container
classes. Fortunately, these containers can be designed to meet the
container requirements specified in the C++ standard, and so they would
still fit in the STL framework.
- Wil
Wil Evers, DOOSYS IT Consultants, Maarssen, Holland
--
- Wil
Wil Evers, DOOSYS IT Consultants, Maarssen, Holland
[Wil underscore Evers at doosys dot com]
Michi Henning
> Well, your book seems to suggest otherwise :-). Here's a quote from the
> introduction of chapter 6:
>
> "It is possible to layer a slower but more convenient
> mapping on top of a faster but less convenient one, but
> we cannot layer a fast mapping on top of a slow one.
> Favoring a mapping that is fast but less convenient lets
> the OMG and ORB vendors add other options, such as code
> generation wizards, later."
Hey Wil, be careful at trying to beat me at my own game ;-) The above
is the rationale that won the day at the time. I am not sure whether we
wouldn't have been better off with a slower but more comfortable mapping.
However, it's easy to be smart with hindsight, and a lot harder to be
right without the benefit of hindsight. Besides, from what I hear (I wasn't
there myself), it apparently took a lot of diplomacy, political
maneuvring, a lot of self-restraint, and a large number of compromises
to get any C++ mapping at all. (I'm sure that Steve could tell a few stories
on this...) At the time this decision was made, it was most likely the
correct and most responsible one, given the state of C++ and CORBA at the
time.
> Seriously though, let's not forget how the current OMG-standard mapping
> came about. Personally, I don't believe an alternative, easier-to-use
> CORBA to C++ mapping using the STL should be a paper design.
>
> IMHO the best thing is to have some working prototype implementation, which
> would allow the new mapping to evolve based on true implementation
> experience and user feedback.
Strongly agree!
> If such a prototype is designed to run on
> top of the existing OMG-standard mapping, it will be far easier to make it
> work with existing ORBs. With some care, it would even be possible to have
> the old and new mappings coexist peacefully within the same program.
>
> Once the dust settles, we can all see whether the alternative mapping has
> gained enough acceptance to justify standardization by the OMG, perhaps not
> as a replacement of the current one, but as a separate standard. If that
> happens, I would expect ORB suppliers to start supporting it directly,
> removing the need for an intermediate layer.
That sounds like a feasible approach. Now that we have open source ORBs,
it's even possible for mere mortals to tinker with this without first
having to sign their soul to the devil (oops, I meant taking employment with
an ORB vendor ;-)
> > Hmmm... I don't like the mapping to char * either.
> > However, a mapping to string was not an option at the time.
> > The C++ mapping was produced long before there was such a
> > thing as an ANSI string class. All that was known was
> > that there would likely be such a class in standard C++
> > in the future, but not what it would look like.
>
> However, the mapping from string to char * has one virtue: for 'in'
> parameters, it can be implemented without any data copying, simply as a
> pointer to a segment of the input message buffer. The same can be done for
> 'in' parameters that are sequences of basic types.
Yes. However, with the right accessor functions, you could also do that
with a string class, I believe.
> None of the C++ standard library containers can do that; they all use one
> or more dynamically allocated memory buffers which are owned and ultimately
> freed by the container object. Therefore, one of the fundamental decisions
> any new mapping must fix is whether the zero-copying optimization must be
> supported. If so, that mapping needs to define its own set of container
> classes. Fortunately, these containers can be designed to meet the
> container requirements specified in the C++ standard, and so they would
> still fit in the STL framework.
Personally, I think whether a data copy happens or not seems like a
third-order issue to me right now. I would prefer to see a mapping that
makes life easy on the programmer. Given that, you can then think about
how to implement it efficiently. Compromising a mapping for efficiency's
sake should only happen when it's proven to be unavoidable, IMO.
Cheers,
Michi.
Copyright 1999 Michi Henning. All rights reserved.
--
Michi Henning +61 7 3236 1633
Triodia Technologies +61 4 1118 2700 (mobile)
PO Box 372 +61 7 3211 0047 (fax)
Annerley 4103 mi...@triodia.com
AUSTRALIA http://www.triodia.com/staff/michi-henning.html
Wil Evers
<Pine.HPX.4.05.99072...@bobo.triodia.com>...
> On 20 Jul 1999, Wil Evers wrote:
>
> > However, the mapping from string to char * has one virtue:
> > for 'in' parameters, it can be implemented without any data
> > copying, simply as a pointer to a segment of the input
> > message buffer. The same can be done for 'in' parameters
> > that are sequences of basic types.
>
> Yes. However, with the right accessor functions, you could also
> do that with a string class, I believe.
That's what I mean: some other string class, not std::string, could do
that.
The question is: can a string class be designed in such a way that it (1)
contributes to a more comfortable CORBA to C++ mapping, (2) works well with
std::string and the rest of the standard C++ library, (3) is as easy to use
as std::string and (4) has a performance that's close to the OMG standard
zero-copying char *? I believe it can be done.
> Personally, I think whether a data copy happens or not seems like a
> third-order issue to me right now. I would prefer to see a mapping
> that makes life easy on the programmer. Given that, you can then
> think about how to implement it efficiently.
> Compromising a mapping for efficiency's sake should only happen when
> it's proven to be unavoidable, IMO.
I agree, of course. Easy of use is why we need another C++ mapping.
However, I'm not convinced that a better C++ mapping would necessarily have
to be much slower than the official OMG one.
U. Art
> On the MICO development mailing list, Michi Henning wrote:
> > This is the approach of "least resistance" and OK as an
> > interim step. Longer-term, I would prefer a mapping
> > that directly goes from C++ to the ORB native API, instead
> > of via an intermediate layer, simply for
> > efficiency reasons.
>
> introduction of chapter 6:
>
> "It is possible to layer a slower but more convenient
> mapping on top of a faster but less convenient one, but
> we cannot layer a fast mapping on top of a slow one.
> Favoring a mapping that is fast but less convenient lets
> the OMG and ORB vendors add other options, such as code
> generation wizards, later."
for an efficient mapping.
--
len
if you must email, reply to:
len bel at world net dot att dot net (no spaces, ats2@, dots2.)
Gilbert W. Pilz Jr.
wrote:
>Personally, I think whether a data copy happens or not seems like a
>third-order issue to me right now. I would prefer to see a mapping that
>makes life easy on the programmer. Given that, you can then think about
>how to implement it efficiently. Compromising a mapping for efficiency's
>sake should only happen when it's proven to be unavoidable, IMO.
I am a veteran of the DCE world and IMHO one of the things that killed
DCE was the shortage of people who could actually write real world,
production scale applications using DCE as a platform.
If you don't make it simple than you won't build up the critical mass
of developers necessary to provide the momentum to carry the
technology forward. Instead you end up with an ever diminishing circle
of insiders protesting the fact that "our technology is better" while
the rest of the world passes them by.
Gilbert W. Pilz Jr.
Senior Consulting Engineer
SeaLion Software Inc.
www.clion.com
Michi Henning
> I am a veteran of the DCE world and IMHO one of the things that killed
> DCE was the shortage of people who could actually write real world,
> production scale applications using DCE as a platform.
Yes. Using DCE was hard.
> If you don't make it simple than you won't build up the critical mass
> of developers necessary to provide the momentum to carry the
> technology forward. Instead you end up with an ever diminishing circle
> of insiders protesting the fact that "our technology is better" while
> the rest of the world passes them by.
I'd say that CORBA with C++ has more than enough critical mass already,
so I'm not concerned on that point. However, that doesn't mean that there
couldn't be a C++ mapping that's easier to use.
Derek Thomson
>
> Seriously though, let's not forget how the current OMG-standard mapping
> came about. Personally, I don't believe an alternative, easier-to-use
> CORBA to C++ mapping using the STL should be a paper design.
>
> IMHO the best thing is to have some working prototype implementation, which
> would allow the new mapping to evolve based on true implementation
> top of the existing OMG-standard mapping, it will be far easier to make it
> work with existing ORBs. With some care, it would even be possible to have
> the old and new mappings coexist peacefully within the same program.
CiTR (www.citr.com) have a tool that produces a nice C++ mapping layered
on top of the standard mapping on both the server and client sides. It's
a little more OO than the standard mapping, and uses STL types wherever
possible.
I wrote it, but I have since moved on, so email ray...@citr.com.au if
you want more info. It's a pretty good first stab at an improved C++
mapping. I don't know what their licensing/evaluation policy is, so
you'll have to ask.
If you want to ask anything about the process of writing such a beast so
that the user is shielded from the "features" of different ORBs, or
about the details of the mapping itself, I'll try to answer as best I
can.
>
> Once the dust settles, we can all see whether the alternative mapping has
> gained enough acceptance to justify standardization by the OMG, perhaps not
> as a replacement of the current one, but as a separate standard. If that
> happens, I would expect ORB suppliers to start supporting it directly,
> removing the need for an intermediate layer.
Sounds like a sensible approach to me.
--
__________________________________________________________
Derek Thomson de...@dstc.com
DSTC Pty Ltd http://dstc.com
University of Qld, 4072 tel +61 7 3365 4310
AUSTRALIA fax +61 7 3365 4311
http://dstc.com/Fnorb
Duncan Grisby
Wil Evers <bou...@dev.null> wrote:
[...]
>The question is: can a string class be designed in such a way that it (1)
>contributes to a more comfortable CORBA to C++ mapping, (2) works well with
>std::string and the rest of the standard C++ library, (3) is as easy to use
>as std::string and (4) has a performance that's close to the OMG standard
>zero-copying char *? I believe it can be done.
The use of char* isn't quite as efficient as people are making out --
lots of code, both in the ORB and in the application, needs to know
the length of the string, which involves repeated calls to strlen(). A
decent string class would keep a record of the length, just like
sequences do.
Cheers,
Duncan.
--
-- Duncan Grisby \ Research Engineer --
-- AT&T Laboratories Cambridge --
-- http://www.uk.research.att.com/~dpg1 --
Steve Vinoski
> Besides, from what I hear (I wasn't
> there myself), it apparently took a lot of diplomacy, political
> maneuvring, a lot of self-restraint, and a large number of compromises
> to get any C++ mapping at all. (I'm sure that Steve could tell a few stories
> on this...)
How can I resist? :-)
In 1991 IONA was developing Orbix with its own C++ mapping. Around the same time
HyperDesk was also doing C++ ORB work. Later in 1992 HP (where I was at the time)
and Sun were doing joint CORBA development and, not knowing about these other
efforts, we independently developed our own C++ mapping. Meanwhile, IBM was
working on SOM and DSOM, but only with C mappings. When the OMG issued the C++
mapping RFP, the submissions eventually boiled down to two camps: the HP/IONA/Sun
camp (the HP/Sun submission and the IONA submission were very similar to begin
with, so they merged) and the HyperDesk camp. HP wanted some changes in their
submission but couldn't agree with Sun, so HP (me) dropped out and became a sort
of independent reviewer/negotiator. The HyperDesk mapping, written largely by Bob
Kukura (who later worked with me at HP and now works with me at IONA) made heavy
use of classes and hid all memory management issues, while the IONA/Sun mapping
was more like today's OMG C++ mapping. The OMG ORB Task Force actually voted to
adopt the HyperDesk mapping in December 1993, but Sun and IBM raised enough
concerns at the OMG Technical Committee level in the spring of 1994 to have the
proposed adoption voted down. (It actually never reached a vote because
HyperDesk, seeing the writing on the wall, pulled it before the vote finished.)
Sun was concerned about the suitability of the HyperDesk mapping for OS kernel
programming (because Sun was developing Spring at the time), and IBM didn't like
its heavy mismatch with C (which was the basis for SOM).
So, in the early summer of 1994, we had just spent a year in the OMG trying to
adopt a C++ mapping, and we ended up with nothing. Doug Lea, Mark Linton, and I
knew we needed a standard C++ mapping, and we went off on our own to create a
mapping that everyone could live with. We prototyped both mappings and measured
their performance, and we found the HyperDesk mapping to be generally four to
five times slower than the IONA/Sun approach. We felt that that overhead was too
much for systems like Fresco and Spring which used IDL for all interfaces, even
those in the same process (and I still feel the same way because as we say, you
can't layer a fast system over a slow one). We spent the next six months or so
meeting with Digital, Expersoft, HP, IBM, IONA, Sun, and others to make sure the
mapping we developed satisfied everyone. Lots of work, lots of negotiation, lots
of politics, and finally in the fall of 1994 the OMG adopted our new C++ mapping,
which is the one we have today.
> At the time this decision was made, it was most likely the
> correct and most responsible one, given the state of C++ and CORBA at the
> time.
Naturally, I personally like to think so. The need for the technical and
political balancing act was caused mainly by the fact that C++ is a multiparadigm
language that can be used very differently in different programming contexts.
> Personally, I think whether a data copy happens or not seems like a
> third-order issue to me right now. I would prefer to see a mapping that
> makes life easy on the programmer. Given that, you can then think about
> how to implement it efficiently. Compromising a mapping for efficiency's
> sake should only happen when it's proven to be unavoidable, IMO.
My opinion is that 1) people should not forget the C++ mapping history explained
above, 2) the difficulty of using the current C++ mapping is exaggerated, and 3)
the expense for a vendor to try to support a new C++ mapping not layered
seamlessly over the existing one would be *HUGE*. Let me expand on these points.
1) I don't tell the history lesson just to waste time writing lots of words.
Rather, the point is that those who don't know history are doomed to repeat it,
as the saying goes. Anyone who believes that they could get the OMG to issue an
RFP for a new C++ mapping and not encounter significant political and technical
battles during the submission and adoption process is being completely naive, or
to put it bluntly, stupid. As I said above, C++ is a multiparadigm language that
can be used well in multiple ways -- as a better C, as an object-based language,
as a generic programming language, or as an OO language. (You also still have to
deal with C++ dialects created by compilers that still don't support the
standard, but hopefully this will not be the case for too much longer.)
Significant differences in opinion of how best to map IDL to C++ -- which C++? --
are therefore bound to occur.
2) I have always been of the opinion that the current OMG C++ mapping is nowhere
near as difficult as people make it out to be. Sure, I helped write it originally
and have been working with it for years, but it's not like it took me years or
even months to learn. Rather, I think the problem that people have was that there
was no good explanation for how to use it (the OMG spec was not intended to be a
tutorial). Fortunately, Michi, I think our book fixes that issue. :-) Also, I
think that many people do not know C++ as well as they think they do; if they
really knew C and C++ like they should, nobody would be having this discussion.
3) IONA knows well that the cost of trying to support multiple language mappings
is very large. Orbix 1.x had a proprietary C++ mapping, while 2.x switched over
to the new one. For a time, we supported both. The cost of supporting a single
mapping -- engineering, documentation, customer service, etc. -- is very large.
The cost of supporting two is, well, prohibitive. The mapping has tremendous
effects on the internals of the ORB core and object services. (You might argue
that this can be prevented by encapsulation and layering, but I know from much
experience that such techniques have negative performance and code size impacts.)
The effects on code quality and maintenance of supporting two mappings
(especially if they are not layered), or switching from an old one to a new one,
cannot be understated. Hell, just supporting OMG C++ Revision Task Force changes
is hard enough when you have a huge installed base using multiple versions of
your systems in massive production deployments.
If you focus only on the technical arguments, a new C++ mapping might seem like a
great idea (but I'd even argue with that). But when you look at the bigger
picture, it's clear to me that it's just not worth it.
--steve
Thomas Langen
current mapping standard. It sounds very disencouraging, but I do not
find any point which forbids to develop something some people might
think is better in some way. Obviously the OMG is not the right place
for "playing around", but eventually a good proposisition which is
prooved to work might be taken into consideration. I believe that such a
thing could be develeped from within the "net community". Why not try
it?
--
Thomas Langen
mailto:lan...@bauinf.tu-cottbus.de
Phone: +49 355 69 3755
Bill Janssen
You also still have to
deal with C++ dialects created by compilers that still don't support the
standard, but hopefully this will not be the case for too much longer.
I remember you telling me this in 1994, Steve :-).
Bill
--
Bill Janssen <jan...@parc.xerox.com> (650) 812-4763 FAX: (650) 812-4777
Xerox Palo Alto Research Center, 3333 Coyote Hill Rd, Palo Alto, CA 94304
URL: ftp://ftp.parc.xerox.com/pub/ilu/misc/janssen.html
de...@viljoen.com
vin...@NOSPAM-iona.com wrote:
...
> My opinion is that 1) people should not forget the C++ mapping
history explained
> above, 2) the difficulty of using the current C++ mapping is
exaggerated, and 3)
> the expense for a vendor to try to support a new C++ mapping not
layered
> seamlessly over the existing one would be *HUGE*. Let me expand on
these points.
> --steve
Steve,
Thanks for this history lesson. When I was contracting for NEC
Systems, Mike Greenberg often told me that the original HP submission
for a C++ mapping was the technically superior one (his words) but that
a compromise was necessary for political reasons, and gave us a pretty
mediocre solution. Now, it seems to make more sense.
Derek
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Stefan Seefeld
let me jump in with a question:
I'm developing a windowing system (the berlin project)
which makes much use of Fresco's design. While studying
Fresco's sources I found strange uses of implementation
pointers. To make it CORBA conformant I had not only
to change that but introduce new interfaces to keep
track of the implementation instances.
I'd like to know whether there is a more elegant solution.
The situation is this:
You are given a set of factories ('Kits') which all
instantiate a number of objects for example to be put into
a scene graph or Pencils from a DrawingKit etc.
Fresco doesn't provide destruction methods in the kits
but I certainly need to let the kits take care of destructing
all the objects they once created (they have to have garbage
collectors inside).
So what I'd like to understand, is, how did that work
in the ORB used by Fresco (which was not standard CORBA)
and how am I supposed to implemented such a behavior in modern
terms ?
Thanks, Stefan
_______________________________________________________
Stefan Seefeld
Departement de Physique
Universite de Montreal
email: seef...@magellan.umontreal.ca
_______________________________________________________
...ich hab' noch einen Koffer in Berlin...
Steve Vinoski
> Thank you, Steve, for this very impressive lesson on the history of the
> current mapping standard. It sounds very disencouraging, but I do not
> find any point which forbids to develop something some people might
> think is better in some way.
Again, there is no *technical* barrier other than the C++ multiparadigm
programming language issue, but I see a huge economic barrier related to the
vast number of applications written against the current mapping. There is
also a huge political barrier because everyone and their brother will have
an opinion on how "best" to design a new mapping.
> Obviously the OMG is not the right place
> for "playing around",
We hope not -- CORBA is supposed to be about abstracting known working
technologies, not inventing stuff.
> but eventually a good proposisition which is
> prooved to work might be taken into consideration. I believe that such a
> thing could be develeped from within the "net community". Why not try
> it?
Of course, there's nothing I can do to stop you, but given my eight years of
experience with CORBA C++ mappings, I can certainly offer much advice and
guidance. Like I said before, I tell the C++ mapping history so that folks
who are thinking about new mappings and such things know what they're really
getting themselves into.
--steve
Douglas C. Schmidt
> Thank you, Steve, for this very impressive lesson on the history of
> the current mapping standard. It sounds very disencouraging, but I
> do not find any point which forbids to develop something some people
> might think is better in some way.
Right -- that's one reason why the open-source ORBs available today
play an important role in helping provide a basis for experimentation
(not unlike the role that BSD UNIX played in the OS community).
> Obviously the OMG is not the right place for "playing around", but
> eventually a good proposisition which is prooved to work might be
> taken into consideration. I believe that such a thing could be
> develeped from within the "net community". Why not try it?
Go for it, dude!
Doug
--
Dr. Douglas C. Schmidt, Associate Professor
Department of Computer Science, Washington University
St. Louis, MO 63130. Work #: (314) 935-4215; FAX #: (314) 935-7302
sch...@cs.wustl.edu, www.cs.wustl.edu/~schmidt/
Eric Eide
> I believe that such a thing [a new IDL to C++ mapping] could be
> develeped from within the "net community". Why not try it?
As Dr. Doug Schmidt already wrote, ``Go for it, dude!''
Now I'm going to plug the project that I work on :-).
Flick, the Flexible IDL Compiler Kit from the University of Utah, is a research
tool that one could use to explore alternate mappings from IDL to C++. Flick
divides separate aspects of IDL compilation into separate compiler passes,
implemented as individual programs.
A language mapping is implemented by what we call a ``presentation generator,''
which is separate from the front end IDL parser and the back end stub code
generator. To implement a new language mapping, one could start with Flick's
current CORBA C++ presentation generator and modify it as one likes.
Ideally, one would be able to use the existing Flick front ends and back ends
unmodified. (I say ``ideally'' because depending on what one does, one might
be required to extend Flick's internal representations, in which case one would
have to extend the other passes as well in order to deal with the new IR node
types.)
Flick is available at:
<http://www.cs.utah.edu/projects/flux/flick/>
Good luck!
Eric.
--
-------------------------------------------------------------------------------
Eric Eide <ee...@cs.utah.edu> . University of Utah Dept. of Computer Science
http://www.cs.utah.edu/~eeide . +1 (801) 585-5512 voice, +1 (801) 581-5843 FAX
Markus Kohler
> Even though this is not directly related to the thread
> let me jump in with a question:
>
> I'm developing a windowing system (the berlin project)
> which makes much use of Fresco's design. While studying
> Fresco's sources I found strange uses of implementation
> pointers. To make it CORBA conformant I had not only
> to change that but introduce new interfaces to keep
> track of the implementation instances.
> I'd like to know whether there is a more elegant solution.
> The situation is this:
>
> You are given a set of factories ('Kits') which all
> instantiate a number of objects for example to be put into
> a scene graph or Pencils from a DrawingKit etc.
> Fresco doesn't provide destruction methods in the kits
> but I certainly need to let the kits take care of destructing
> all the objects they once created (they have to have garbage
> collectors inside).
>
> So what I'd like to understand, is, how did that work
> in the ORB used by Fresco (which was not standard CORBA)
> and how am I supposed to implemented such a behavior in modern
> terms ?
>
I cannot tell you how it was done by Fresco.
But I can tell you that the typical C++ solution is reference counting
if you don't want to make the application responsible for destroying
the objects.
That's it.
If you want to allow arbitrary (cyclic) relationships you would
probably have to implement some kind of garbage collector. You could maybe
do that for your specific data structure, but I have not yet seen that
in practice.
Markus
--
Markus Kohler mailto:markus...@hp.com
pww19...@gmail.com
> ORBs besides MICO, I'm posting this article to comp.object.corba,
> suggesting this thread be continued in the newsgroup. ]
>
>
>
> > > Perhaps there's some way that we could write efficient
> > > wrappers that would allow developers to write code
> > > against a standard STL-based API, while hiding the
> > > "true" standard CORBA C++ mapping. Then any code written
> > > against the wrappers could be ported to any compliant ORB
> > > just by porting the wrapper code.
>
> > interim step. Longer-term, I would prefer a mapping
> > that directly goes from C++ to the ORB native API, instead
> > of via an intermediate layer, simply for
> > efficiency reasons.
>
> Well, your book seems to suggest otherwise :-). Here's a quote from the
> introduction of chapter 6:
>
> "It is possible to layer a slower but more convenient
> mapping on top of a faster but less convenient one, but
> we cannot layer a fast mapping on top of a slow one.
> Favoring a mapping that is fast but less convenient lets
> the OMG and ORB vendors add other options, such as code
> generation wizards, later."
>
> came about. Personally, I don't believe an alternative, easier-to-use
> CORBA to C++ mapping using the STL should be a paper design.
>
> IMHO the best thing is to have some working prototype implementation, which
> would allow the new mapping to evolve based on true implementation
> experience and user feedback. If such a prototype is designed to run on
> top of the existing OMG-standard mapping, it will be far easier to make it
> work with existing ORBs. With some care, it would even be possible to have
> the old and new mappings coexist peacefully within the same program.
>
> gained enough acceptance to justify standardization by the OMG, perhaps not
> as a replacement of the current one, but as a separate standard. If that
> happens, I would expect ORB suppliers to start supporting it directly,
> removing the need for an intermediate layer.
>
> > > that the choice of "char *" for IDL "string" was a
> > > really terrible decision. Compliance of C++ code with
> > > an old C mapping is much less
> > > important than ease of implementation and cleanliness.
>
> > However, a mapping to string was not an option at the time.
> > The C++ mapping was produced long before there was such a
> > thing as an ANSI string class. All that was known was
> > that there would likely be such a class in standard C++
> > in the future, but not what it would look like.
>
> parameters, it can be implemented without any data copying, simply as a
> pointer to a segment of the input message buffer. The same can be done for
> 'in' parameters that are sequences of basic types.
>
> or more dynamically allocated memory buffers which are owned and ultimately
> freed by the container object. Therefore, one of the fundamental decisions
> any new mapping must fix is whether the zero-copying optimization must be
> supported. If so, that mapping needs to define its own set of container
> classes. Fortunately, these containers can be designed to meet the
> container requirements specified in the C++ standard, and so they would
> still fit in the STL framework.
>
>
> Wil Evers, DOOSYS IT Consultants, Maarssen, Holland
>
>
> Wil Evers, DOOSYS IT Consultants, Maarssen, Holland
> [Wil underscore Evers at doosys dot com]
Author: pengwenwei
Email:
Language: c++
Platform: Windows, linux
Technology: Perfect hash algorithm
Level: Advanced
Description: Map algorithm with high performance
Section MFC c++ map stl
SubSection c++ algorithm
License: (GPLv3)
Download demo project - 1070 Kb
Download source - 1070 Kb
Introduction:
For the c++ program, map is used everywhere.And bottleneck of program performance is often the performance of map.Especially in the case of large data,and the business association closely and unable to realize the data distribution and parallel processing condition.So the performance of map becomes the key technology.
In the work experience with telecommunications industry and the information security industry, I was dealing with the big bottom data,especially the most complex information security industry data,all can’t do without map.
For example, IP table, MAC table, telephone number list, domain name resolution table, ID number table query, the Trojan horse virus characteristic code of cloud killing etc..
The map of STL library using binary chop, its has the worst performance.Google Hash map has the optimal performance and memory at present, but it has repeated collision probability.Now the big data rarely use a collision probability map,especially relating to fees, can’t be wrong.
Now I put my algorithms out here,there are three kinds of map,after the build is Hash map.We can test the comparison,my algorithm has the zero probability of collision,but its performance is also better than the hash algorithm, even its ordinary performance has no much difference with Google.
My algorithm is perfect hash algorithm,its key index and the principle of compression algorithm is out of the ordinary,the most important is a completely different structure,so the key index compression is fundamentally different.The most direct benefit for program is that for the original map need ten servers for solutions but now I only need one server.
Declare: the code can not be used for commercial purposes, if for commercial applications,you can contact me with QQ 75293192.
Download:
https://sourceforge.net/projects/pwwhashmap/files
Applications:
First,modern warfare can’t be without the mass of information query, if the query of enemy target information slows down a second, it could lead to the delaying fighter, leading to failure of the entire war. Information retrieval is inseparable from the map, if military products use pwwhashMap instead of the traditional map,you must be the winner.
Scond,the performance of the router determines the surfing speed, just replace open source router code map for pwwHashMap, its speed can increase ten times.
There are many tables to query and set in the router DHCP ptotocol,such as IP,Mac ,and all these are completed by map.But until now,all map are using STL liabrary,its performance is very low,and using the Hash map has error probability,so it can only use multi router packet dispersion treatment.If using pwwHashMap, you can save at least ten sets of equipment.
Third,Hadoop is recognized as the big data solutions at present,and its most fundamental thing is super heavy use of the map,instead of SQL and table.Hadoop assumes the huge amounts of data so that the data is completely unable to move, people must carry on the data analysis in the local.But as long as the open source Hadoop code of the map changes into pwwHashMap, the performance will increase hundredfold without any problems.
Background to this article that may be useful such as an introduction to the basic ideas presented:
http://blog.csdn.net/chixinmuzi/article/details/1727195