[WF-General] Atlas C++

Wolfgang Beutner wolfgang.beutner at gmx.de
Tue Jul 5 10:35:38 PDT 2005


I am doing some experiments with the AtlasC++ lib, using version 0.5.94 
and discovered some strange behavior. I have a class that is derived 
from Atlas::Message::DecoderBase. Within this class I have a private 
member Atlas::Codecs::Bach and a private member Atlas::Message::Encoder. 
I use the Bach-Codec because of the improved readability.

I want to use the class to exchange messages between processes using TCP 
Sockets (skstream-lib). I used some of the basic concepts of cyphesis to 
tie this all together, great stuff Al.

As soon as the second message arrives at the reading process, the 
process crashes due to some kind of stack underflow in the Bach-Codec. 
After I inserted the marked statement everything was ok.

void Bach::parseStream(char next)
     ATLAS_DEBUG(std::cout << "Bach::parseStream" << std::endl;)

     switch (next)
     case '{':

     case ']':
     /* NEW */
     /* NEW */


Maybe I misunderstood some of the Atlas stuff.

When I tried to send the value 0.0 as member of a list the receiving 
process crashed, when I tried to access this value as
Koord[ 2 ].asFloat(). I suppose this happened because the value of 0.0 
is coded as 0 on the sending side of the connection. The Codec starts to 
decode an integer once he detects a number in the inputstream and 
switches to float only after he encountered a '.' I could veriyfy this
by accessing the listElement in question as an integer. I do not have 
any idea how to solve this problem. I wrote a simple program that uses 
printf and << operator to output the value of 0.0. Printf
outputs 0.000000 and operator << 0.

The same problem arises, if you want to transmit a value of 0.000001. 
this is transmitted as 1e-06 and is not recognized as a float as well. I 
think this could be corrected in allowing characters 'e' and
'E' to switch from integer to float as well and removing them from the 
multiple case checking for digits and signs.

The packed and XML codecs do not seem to have this problem since there 
is an explicit indicator for each type allowing to decide how to 
interpret things.



More information about the General mailing list