[ace-users] Naming Service problem

Sowayan, Abdullah (N-DUA) abdullah.sowayan at lmco.com
Sat Sep 22 22:56:40 CDT 2007

Hi Dhanya,

I think you're confused by the purpose of the optional 'anticipated'
maximum you can provide to the constructor of a sequence. Below is an
excerpt from the book 'Advanced CORBA Programming with C++' by by Michi
Henning, and Steve Vinoski that explains this stuff. It can be found in
Chapter 6 secion 14.

If you're going to do any CORBA programming, I highly recommend you
invest in buying yourself a copy of the book. It has a detailed
explanation of the basic CORBA questions you have (such as the IDL to
C++ mapping issue you seem to be confused about).

"Controlling the Sequence Maximum
When you construct a sequence variable, you can supply an anticipated
maximum number of elements using the maximum constructor:

StrSeq myseq(10); // Expect to put ten elements on the sequence
myseq.length(20); // Maximum does *not* limit length of sequence
for (CORBA::ULong i = 0; i < myseq.length(); i++)
    // Initialize elements

As you can see, even though this code uses an anticipated maximum of 10
elements, it then proceeds to add 20 elements to the sequence. This is
perfectly all right. The sequence extends the maximum as necessary to
accommodate the additional elements.

Why bother with supplying an anticipated maximum? The answer has to do
with how a sequence manages its buffer space internally. If you use the
maximum constructor, the sequence sets an internal maximum to a value at
least as large as the one you supply (the actual maximum may be set to a
larger value than the one you supply). In addition, a sequence
guarantees that elements will not be relocated in memory while the
current length does not exceed the maximum.

Typically, you do not care about relocation of elements in memory unless
you are maintaining pointers to the sequence elements. In that case, you
must know when sequence elements may relocate in memory because
relocation will invalidate your pointers.

Another reason for supplying a maximum is efficiency. If the sequence
has some idea of the expected number of elements, it can chunk memory
allocations more efficiently. This approach reduces the number of calls
to the memory allocator and reduces the number of times elements need to
be copied as the sequence grows in length. (Memory allocation and data
copying are expensive.)"

After a few paragraphs it the book says the following:

"It should be clear that the maximum constructor is no more than a hint
to the implementation of the sequence. If you create a sequence and have
advance knowledge of the expected number of elements, then by all means,
use the maximum constructor. It may help to get better run-time
performance from the sequence. Otherwise, do not bother."

So as you see, the optional parameter to the constructor acts as a hint
to the implementation on how much buffer space to allocate, but does not
set the logical length of the sequence. You set the logical length of
the sequence yourself by calling the length() method.

If after this you're still confused, stop using the optional parameter
to the sequence constructor and just use the length() method and
everything will work fine.


> -----Original Message-----
> From: ace-users-bounces at cse.wustl.edu [mailto:ace-users-
> bounces at cse.wustl.edu] On Behalf Of Douglas C. Schmidt
> Sent: Saturday, September 22, 2007 12:46 PM
> To: vishnu.dhanya at gmail.com; ace-users at cse.wustl.edu
> Subject: Re: [ace-users] Naming Service problem
> Hi Dhanya,
> >> >Is CosNaming::Name name;
> >> >name.length(2);
> >>
> >> >is different from
> >> >CosNaming::Name name(2);
> >>
> >> Yes.
> >
> >I changed the code to
> >CosNaming::Name name (2);
> >
> >But still same exception
> >InvalidName (IDL:omg.org/CosNaming/NamingContext/InvalidName:1.0)
> Did you do this:
> CosNaming::Name name (2);
> name.length (2);
> Make sure you read the material I recommended before you go any
> further or ask any more questions.  There are also lots of examples of
> this stuff in the TAO tests and examples.
> Thanks,
>      Doug
> --
> Dr. Douglas C. Schmidt                       Professor and Associate
> Electrical Engineering and Computer Science  TEL: (615) 343-8197
> Vanderbilt University                        WEB:
> www.dre.vanderbilt.edu/~schmidt
> Nashville, TN 37203                          NET:
d.schmidt at vanderbilt.edu
> _______________________________________________
> ace-users mailing list
> ace-users at mail.cse.wustl.edu
> http://mail.cse.wustl.edu/mailman/listinfo/ace-users

More information about the Ace-users mailing list