[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference pamsrc::objectbroker_development

Title:ObjectBroker Development - BEA Systems' CORBA
Notice:See note 2 for kit locations; note 4 for training
Moderator:RECV::GUMBELd
Created:Thu Dec 27 1990
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:2482
Total number of notes:13057

2462.0. "Ascii and Binary together using ANY" by CAMPY::ADEY (Is there a 'Life for Dummies'?) Thu Mar 27 1997 21:48

    We want to send ascii and binary data together in one parameter.
    Is this a reasonable thing to do, using the ANY data type?
    If so, how would you convert from/to the ANY data type?
    
    Thanks.
    
    Ken....
T.RTitleUserPersonal
Name
DateLines
2462.1REQUE::BOWERPeter Bower, ObjectBrokerFri Mar 28 1997 09:1913
    
    You can use the sequence<octet> data to send ascii and binary
    data together. However, you will have to pack and unpack the 
    sequence yourself. Also, if you store integers in the
    sequence of octet, OBB will not convert them when going
    between machines with different endian orders.
    
    There is no reason to use an ANY unless you want to send
    a string one invoke, and a long the next. 
    
    You may want to use a struct instead of trying to combine
    both ascii and binary data in one parameter.
    
2462.2CAMPY::ADEYIs there a 'Life for Dummies'?Fri Mar 28 1997 14:3617
    re: Note 2462.1 by REQUE::BOWER
    
    Peter, thanks for the quick response.
    
    It looks like sequence<octet> is probably the way I'll go, but I have
    some questions regarding the packing/unpacking I'll have to do:
    
    o What does a sequence map to, one byte? Or can I have a sequence of 1
      with my entire message in that 1 sequence?
    
    o Does OBB provide any routines I can use in C/C++ to convert to and
      from sequence<octet>?
    
    Thanks.
    
    Ken....
    
2462.3REQUE::BOWERPeter Bower, ObjectBrokerTue Apr 01 1997 10:3519
    
    > What does a sequence map to, one byte? Or can I have a sequence of 1
    > with my entire message in that 1 sequence?
    
    A sequence maps to the appropriate language binding. For C++ that
    is a class. For C that is a structure with a length, a max, and
    a data buffer. In either case, think of a sequence<octet> as
    an array of bytes.
    
    > o Does OBB provide any routines I can use in C/C++ to convert to and
    >  from sequence<octet>?
    
    No. You will have to write them yourself. 
    
    I strongly urge you to look into using user-defined types. With types
    suchs as struct, union, array, sequence, you may be able to represent
    the data you want to send and can eliminate the need for packing,
    unpacking data into a sequence of octet.
    
2462.4CAMPY::ADEYIs there a 'Life for Dummies'?Tue Apr 01 1997 21:0241
    re: Note 2462.3 by REQUE::BOWER
    
    >> What does a sequence map to, one byte? Or can I have a sequence of 1
    >> with my entire message in that 1 sequence?
    >
    > A sequence maps to the appropriate language binding. For C++ that
    > is a class. For C that is a structure with a length, a max, and
    > a data buffer. In either case, think of a sequence<octet> as
    > an array of bytes.
    
    I figured this out after looking at some Quickstart-generated code.
    
    
    >> o Does OBB provide any routines I can use in C/C++ to convert to and
    >>  from sequence<octet>?
    >
    > No. You will have to write them yourself.
    
    I hope I'm not asking for trouble here, but all I did to pack/unpack
    is to do a byte-by-byte transfer (send_message being the sequence<octet>
    parameter, and in_message being a char string):
    
    	    for (i = 0; i < send_message.length(); i++)
    		send_message[i] = *(in_message + i);
    
    This works just fine.
    
    
    > I strongly urge you to look into using user-defined types. With types
    > suchs as struct, union, array, sequence, you may be able to represent
    > the data you want to send and can eliminate the need for packing,
    > unpacking data into a sequence of octet.
    
    This wouldn't work in our case because our parameters are generic
    messages containing variable quantities of variable length items.
    
    
    BTW, what's the distinction between the 'maximum' and the 'length'
    elements?
    
    Ken....
2462.5max, if there is one, sets an upper bound on the lengthVAXCPU::michaudJeff Michaud - ObjectBrokerThu Apr 03 1997 00:3232
> BTW, what's the distinction between the 'maximum' and the 'length' elements?

	From http://www.omg.org/coriiop/idlsyn.htm#576

Sequences

OMG IDL defines the sequence type sequence. A sequence is a one-dimensional
array with two characteristics: a maximum size (which is fixed at compile
time) and a length (which is determined at run time).

The syntax is:

<sequence_type> ::= "sequence" "<" <simple_type_spec> ","
<positive_int_const> ">" | "sequence" "<" <simple_type_spec> ">"

The second parameter in a sequence declaration indicates the maximum size of
the sequence. If a positive integer constant is specified for the maximum
size, the sequence is termed a bounded sequence. Prior to passing a bounded
sequence as a function argument (or as a field in a structure or union), the
length of the sequence must be set in a language-mapping dependent manner.
After receiving a sequence result from an operation invocation, the length of
the returned sequence will have been set; this value may be obtained in a
language-mapping dependent manner.

If no maximum size is specified, size of the sequence is unspecified
(unbounded). Prior to passing such a sequence as a function argument (or as a
field in a structure or union), the length of the sequence, the maximum size
of the sequence, and the address of a buffer to hold the sequence must be set
in a language-mapping dependent manner. After receiving such a sequence
result from an operation invocation, the length of the returned sequence will
have been set; this value may be obtained in a language-mapping dependent
manner.