From boris at codesynthesis.com  Sat Jun  4 19:35:07 2011
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sat Jun  4 17:18:38 2011
Subject: [xsde-users] Segmentation fault for choice in large project
In-Reply-To: <BANLkTim_61SoaVbLf3Q2+_a9Z24pakjLOA@mail.gmail.com>
References: <BANLkTin+CG8hU_RzBkt6P6wB_pXifoPf+w@mail.gmail.com>
	<boris.20110530212552@codesynthesis.com>
	<boris.20110604031300@codesynthesis.com>
	<BANLkTim_61SoaVbLf3Q2+_a9Z24pakjLOA@mail.gmail.com>
Message-ID: <boris.20110605012001@codesynthesis.com>

Hi Adrian,

I am CC'ing the xsde-users mailing list back to our discussion in
case someone else runs into this problem.

Adrian Garcea <adrian.garcea@googlemail.com> writes:

> I tried further to debug it. Unfortunately I didn't get very far.
> I'm sending you the problematic schema with a c++ program, that tries to
> parse an xml file "Test.xml".
> 
> Please read the README.txt file for further details.
 
Thanks for the test case. I tried it on my GNU/Linux box and it ran
without any problems. I also tried it under valgrind to see if there
are any invalid memory accesses (which may not always lead to a seg
fault) but everything runs cleanly.

Then I tried on QNX. I don't have your exact configuration. Rather,
I have QNX 6.4.0 with the gcc 4.2.4 toolchain. I also couldn't use
qcc at this time (had something to do with a copied VM). So I used
gcc/g++ instead and had to modify these three lines in your 
config.make:
  
CC       := qcc
CXX      := qcc
CXXFLAGS := -W -Wall -O3 -Y_gpp -lang-c++

To read:

CC       := gcc
CXX      := g++
CXXFLAGS := -W -Wall -O3

Otherwise I used your config.make unchanged. I am also pretty sure
that qcc underneath runs gcc/g++ command lines that are very similar.
With all this the test runs on QNX without any issues as well.

In this light I suggest that you try the above changes and see if this
makes any difference in your setup.

If it doesn't then this seems to be an issue with the toolchain. You
may wan to try to progressively lower the optimization level (O2, O1,
O0) to see if it makes any difference. If that doesn't help either,
you may want to check if an older version of gcc is available for
your target that you may try.

Boris

From Sebastian.Friebe at xfab.com  Fri Jun 24 02:18:58 2011
From: Sebastian.Friebe at xfab.com (Sebastian Friebe)
Date: Fri Jun 24 02:19:06 2011
Subject: [xsde-users] memory management of variable-length elements?
Message-ID: <7A65A58A4AF8474CA49D69E8044702C2CB57E9@DRS-EX01.xfab.ads>

Hi all,

I got a lot of variable length elements in my schema. 
Code generation works fine with following flags:
cxx-hybrid --generate-parser --generate-serializer --no-long-long --generate-aggregate --generate-clone

Is there any flag to generate delete functionality into the destructors of such elements? Is there a better way to safely free the memory allocated for the pointers, without using custom allocators?

The hybrid manual just says 'the object model expects you to allocate such an object with operator new and will <eventually> delete it with operator delete.

What means eventually in this case?

Thanks a lot for your help.
Best regards,
Sebastian

SPAM and Virus prevention by Barracuda Network Solutions

From ivan.lelann at free.fr  Fri Jun 24 04:13:52 2011
From: ivan.lelann at free.fr (Ivan Le Lann)
Date: Fri Jun 24 04:14:00 2011
Subject: [xsde-users] memory management of variable-length elements?
In-Reply-To: <661811418.665501308900673483.JavaMail.root@zimbra36-e6.priv.proxad.net>
Message-ID: <1379352101.670181308903232318.JavaMail.root@zimbra36-e6.priv.proxad.net>


----- "Sebastian Friebe" <Sebastian.Friebe@xfab.com> a ?crit :

> Hi all,
> 
> I got a lot of variable length elements in my schema. 
> Code generation works fine with following flags:
> cxx-hybrid --generate-parser --generate-serializer --no-long-long
> --generate-aggregate --generate-clone
> 
> Is there any flag to generate delete functionality into the
> destructors of such elements? Is there a better way to safely free the
> memory allocated for the pointers, without using custom allocators?
> 

There is no such flag because this is already what the generated code does.
Just check generated destructors to see that they delete child elements.

> The hybrid manual just says 'the object model expects you to allocate
> such an object with operator new and will <eventually> delete it with
> operator delete.
> 
> What means eventually in this case?
> 

When parent is deleted.

Ivan

From Sebastian.Friebe at xfab.com  Fri Jun 24 04:28:40 2011
From: Sebastian.Friebe at xfab.com (Sebastian Friebe)
Date: Fri Jun 24 04:28:46 2011
Subject: AW: [xsde-users] memory management of variable-length elements?
In-Reply-To: <1379352101.670181308903232318.JavaMail.root@zimbra36-e6.priv.proxad.net>
References: <661811418.665501308900673483.JavaMail.root@zimbra36-e6.priv.proxad.net>
	<1379352101.670181308903232318.JavaMail.root@zimbra36-e6.priv.proxad.net>
Message-ID: <7A65A58A4AF8474CA49D69E8044702C2CB5819@DRS-EX01.xfab.ads>

Hi Ivan,


>> Is there any flag to generate delete functionality into the
>> destructors of such elements? Is there a better way to safely free the
>> memory allocated for the pointers, without using custom allocators?
>> 

>There is no such flag because this is already what the generated code does.
>Just check generated destructors to see that they delete child elements.

That was, what I was expecting. But the destructors are empty. There is nothing done there.

  // XtdsTestBlock (variable-length)
  //
  class XtdsTestBlock ....

  XtdsTestBlock::
  ~XtdsTestBlock ()
  {
  }

Do you have any suggestions?

Thanks and best regards,
Sebastian

SPAM and Virus prevention by Barracuda Network Solutions

From boris at codesynthesis.com  Fri Jun 24 04:48:15 2011
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Fri Jun 24 04:50:54 2011
Subject: [xsde-users] memory management of variable-length elements?
In-Reply-To: <7A65A58A4AF8474CA49D69E8044702C2CB5819@DRS-EX01.xfab.ads>
References: <661811418.665501308900673483.JavaMail.root@zimbra36-e6.priv.proxad.net>
	<1379352101.670181308903232318.JavaMail.root@zimbra36-e6.priv.proxad.net>
	<7A65A58A4AF8474CA49D69E8044702C2CB5819@DRS-EX01.xfab.ads>
Message-ID: <boris.20110624104056@codesynthesis.com>

Hi Sebastian,

Sebastian Friebe <Sebastian.Friebe@xfab.com> writes:

> That was, what I was expecting. But the destructors are empty. 
> There is nothing done there.
> 
>   // XtdsTestBlock (variable-length)
>   //
>   class XtdsTestBlock ....
> 
>   XtdsTestBlock::
>   ~XtdsTestBlock ()
>   {
>   }

It is not the destructor of the class itself that will free the
memory. Rather, it is the destructor of the "holding" class that
will do the job. Here is an example. Suppose you have two classes,
Foo and Bar, both variable-length and Bar contains Foo (in the
schema terms, for example, the Bar complex type has the element
foo of type Foo). Here is the code that illustrates how this
works:

Bar* b = new Bar;

Foo* f = new Foo;
b->foo (f); // Now b is responsible for cleaning up f.

delete b; // Bar's destructor frees f.

If your environment allows you to use smart pointers, then the
better version of this code would be:

auto_ptr<Bar> b (new Bar);

Foo* f = new Foo;
b->foo (f); // Now b is responsible for cleaning up f.

// When b goes out of scope, Bar's destructor will free f.

To put all this in other words, the containing objects in the object
model assume ownership of the objects that they contain. The "eventually"
word in the documentation means that the contained objects will be
freed when their container is freed.

Boris

From klaus.cinibulk at siemens.com  Tue Jun 28 07:55:08 2011
From: klaus.cinibulk at siemens.com (Cinibulk, Klaus)
Date: Tue Jun 28 07:55:14 2011
Subject: [xsde-users] Default notation for float
Message-ID: <BFC33AAF34C06F4BBCF1345977D95450E16C093A10@ATVIES9917VMSX.ww300.siemens.net>

Hi,

I'm using XSD/e and I have noticed that the default notiation for float types is "%.6g".

My question is how to change the default notation to %.6f globally for my generated code.

I have seen that the FLT_DIG macro could basically be used to modify the width of the representation,
but nevertheless %g is not what we want ...

Any hints?

Thanks,
Klaus

From boris at codesynthesis.com  Tue Jun 28 09:56:52 2011
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Tue Jun 28 09:59:33 2011
Subject: [xsde-users] Default notation for float
In-Reply-To: <BFC33AAF34C06F4BBCF1345977D95450E16C093A10@ATVIES9917VMSX.ww300.siemens.net>
References: <BFC33AAF34C06F4BBCF1345977D95450E16C093A10@ATVIES9917VMSX.ww300.siemens.net>
Message-ID: <boris.20110628154727@codesynthesis.com>

Hi Klaus,

Cinibulk, Klaus <klaus.cinibulk@siemens.com> writes:

> I'm using XSD/e and I have noticed that the default notiation for 
> float types is "%.6g".
> 
> My question is how to change the default notation to %.6f globally 
> for my generated code.

There is a way to do this but in XSD/e 3.2.0 it can only be done during 
the construction of the serializer. This makes it difficult if you are 
using aggregates in the C++/Hybrid mapping.

To fix this I have added modifiers to the float, double, and decimal
serializers so that this can be changed after the aggregate has been
constructed. This fix will appear in XSD/e 3.3.0 and I also prepared
a patch for XSD/e 3.2.0 (simply override the file in your XSD/e 3.2.0
with the ones in the archive):

http://www.codesynthesis.com/~boris/tmp/xsde-3.2.0-fp-format.tar.gz

With this fix you can change the notation and precision of the float
serializer in the aggregate, for example:

root_saggr root_s;

root_s.float_s_.format (xml_schema::float_simpl::notation_fixed, 6);

You can also create a custom aggregate class which will encapsulate
this customization:

struct my_root_saggr: root_saggr
{
  my_root_saggr ()
  {
    float_s_.format (xml_schema::float_simpl::notation_fixed, 6);
  }
};

Boris