Re: [tao-users] Copying corba data to STL types.

[Adam Mitz]

On 1/19/2012 5:57 AM, Nick.A...@generaldynamics.uk.com wrote:

{
  // create a std vector and populate it.
  std::vector < char > srcvec( 5 );
  srcvec[0] = 'h';
  srcvec[1] = 'e';
  srcvec[2] = 'l';
  srcvec[3] = 'l';
  srcvec[4] = 'o';

 

  std::cout << "srcvec = ";
  unsigned long nIndex;
  for (nIndex = 0; nIndex < srcvec.size(); nIndex++)
  {
    std::cout << srcvec[ nIndex ];
  }
  std::cout << std::endl;

 

  // translate it in to a corba type.
  // idl code for the databody is:
  // typedef sequence<octet> DataBody;
  MDSB::ClientInterface::DataBody corbadata;

 

  corbadata.length( srcvec.size() );
  std::copy( srcvec.begin(),
    srcvec.end(),
    &corbadata[0] );

 

This code is invalid with any version of any C++ CORBA implementation.  It may have worked by chance with older versions of TAO.  &corbdata[0] is not guaranteed to be a model of OutputIterator for the C++ STL.

  std::cout << "corbadata = ";
  for (nIndex = 0; nIndex < corbadata.length(); nIndex++)
  {
    std::cout << corbadata[ nIndex ];
  }
  std::cout << std::endl;

 

  // translate it back.
  // using the std::vector constructor which takes in the begining and end iterators.
  // below line works with TAO 5.8.6 but not with tao 6.0.5
  std::vector < char > destvec( &corbadata[0], &corbadata[ corbadata.length() ] );

Same problem here.  &corbadata[x] is not an STL InputIterator.

If you want raw access to the sequence buffer, there are sequence methods for that.

Thanks,
Adam Mitz
Senior Software Engineer
Object Computing, Inc.

[Nick.A...@generaldynamics.uk.com]

Hi Jeff.
Sorry, blame the fact its Thursday.
I meant TAO 1.6.8.

Anyway, I guess the answer is the memcpy.

Thanks.
Nick.



Nick Adamson
Software Engineer

C4I Systems

General Dynamics United Kingdom Limited
Bryn Brithdir, Oakdale Business Park, Blackwood, South Wales, NP12 4AA

Telephone: +44 (0) 1495 236467
Email: Nick.A...@generaldynamics.uk.com
Website: www.generaldynamics.uk.com

Please consider the environment before printing this email


-----Original Message-----
From: Jeff Parsons [mailto:j.pa...@vanderbilt.edu]
Sent: Thursday, 19 January 2012 15:24
To: Nick Adamson; tao-...@list.isis.vanderbilt.edu
Cc: jwill...@remedy.nl
Subject: RE: [tao-users] Copying corba data to STL types.

Hi Nick,



I'm looking through our Subversion repository tags and I don't see a TAO
1.8.6. It seems to go from 1.8.3 to 2.0.0. In any case, the lastest
modification to the octet sequence file was just before 1.8.1.



That said, it's entirely appropriate that the exception should be
thrown, since the 2nd parameter passed to the vector constructor from
TAO sequence is past the end of the sequence's buffer. The amazing thing
is that it works on Linux. There is some preprocessor stuff around some
of the range checking code, one of which is ACE_NDEBUG - could the
definition of this be different on the 2 platforms?



thanks,



Jeff



From: tao-user...@list.isis.vanderbilt.edu
[mailto:tao-user...@list.isis.vanderbilt.edu] On Behalf Of
Nick.A...@generaldynamics.uk.com
Sent: Thursday, January 19, 2012 5:57 AM
To: tao-...@list.isis.vanderbilt.edu
Subject: [tao-users] Copying corba data to STL types.



Hi All.



We've recently upgraded to version 2.0.5 of TAO and I'm developing some
code on windows XP using visual studio 2005.

I've come across a problem when copying from a corba sequence of octets
to a std::vector <char>.

This is something we do quite often and on previous versions of TAO, v
1.8.6 was the last we tried it on, works fine but version 2.0.5 throws a
corba bad param exception. We think this is because the way the
std::vector constructor uses iteraters which conflicts with what appears
to be some sort of bounds checking introduced in to TAO recently.



Below I've listed a program that shows this.

If you compile and run it with TAO 1.8.6 it works fine. but throws an
exception with 2.0.5.



Have we guessed correctly what's causing this? what is the intended
behaviour?

If version 2.0.5 is correct then there are inconsistencies between Linux
based platforms, which this code works on irrespective of which version
of TAO we use, and windows.

If 2.0.5 is correct what is the recommended way of doing this? We've
found that memcpy works.



Thanks.

Nick.



Example program:

{

// create a std vector and populate it.
std::vector < char > srcvec( 5 );
srcvec[0] = 'h';
srcvec[1] = 'e';
srcvec[2] = 'l';
srcvec[3] = 'l';
srcvec[4] = 'o';



std::cout << "srcvec = ";
unsigned long nIndex;
for (nIndex = 0; nIndex < srcvec.size(); nIndex++)
{
std::cout << srcvec[ nIndex ];
}
std::cout << std::endl;



// translate it in to a corba type.
// idl code for the databody is:
// typedef sequence<octet> DataBody;
MDSB::ClientInterface::DataBody corbadata;



corbadata.length( srcvec.size() );
std::copy( srcvec.begin(),
srcvec.end(),
&corbadata[0] );

std::cout << "corbadata = ";
for (nIndex = 0; nIndex < corbadata.length(); nIndex++)
{
std::cout << corbadata[ nIndex ];
}
std::cout << std::endl;



// translate it back.
// using the std::vector constructor which takes in the begining and
end iterators.
// below line works with TAO 5.8.6 but not with tao 6.0.5
std::vector < char > destvec( &corbadata[0], &corbadata[
corbadata.length() ] );

std::cout << "destvec = ";
for (nIndex = 0; nIndex < destvec.size(); nIndex++)
{
std::cout << destvec[ nIndex ];
}
std::cout << std::endl;

}







Nick Adamson
Software Engineer

C4I Systems

General Dynamics United Kingdom Limited
Bryn Brithdir, Oakdale Business Park, Blackwood, South Wales, NP12 4AA

Telephone: +44 (0) 1495 236467
Email: Nick.A...@generaldynamics.uk.com
<mailto:Nick.A...@generaldynamics.uk.com>
Website: www.generaldynamics.uk.com <http://www.generaldynamics.uk.com/>


Please consider the environment before printing this email





________________________________

This email and any files attached are intended for the addressee and may
contain information of a confidential nature. If you are not the
intended recipient, be aware that this email was sent to you in error
and you should not disclose, distribute, print, copy or make other use
of this email or its attachments. Such actions, in fact, may be
unlawful. In compliance with the various Regulations and Acts, General
Dynamics United Kingdom Limited reserves the right to monitor (and
examine for viruses) all emails and email attachments, both inbound and
outbound. Email communications and their attachments may not be secure
or error- or virus-free and the company does not accept liability or
responsibility for such matters or the consequences thereof. General
Dynamics United Kingdom Limited, Registered Office: 21 Holborn Viaduct,
London EC1A 2DY. Registered in England and Wales No: 1911653.



This email and any files attached are intended for the addressee and may contain information of a confidential nature. If you are not the intended recipient, be aware that this email was sent to you in error and you should not disclose, distribute, print, copy or make other use of this email or its attachments. Such actions, in fact, may be unlawful. In compliance with the various Regulations and Acts, General Dynamics United Kingdom Limited reserves the right to monitor (and examine for viruses) all emails and email attachments, both inbound and outbound. Email communications and their attachments may not be secure or error- or virus-free and the company does not accept liability or responsibility for such matters or the consequences thereof. General Dynamics United Kingdom Limited, Registered Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and Wales No: 1911653.

[Nick.A...@generaldynamics.uk.com]

Hi Adam.

Thanks for that.
We'll move to a less stl way of doing it and use the memcpy.

Thanks.
Nick.



Nick Adamson
Software Engineer

C4I Systems

General Dynamics United Kingdom Limited
Bryn Brithdir, Oakdale Business Park, Blackwood, South Wales, NP12 4AA

Telephone: +44 (0) 1495 236467
Email: Nick.A...@generaldynamics.uk.com
Website: www.generaldynamics.uk.com

Please consider the environment before printing this email


-----Original Message-----
From: tao-user...@list.isis.vanderbilt.edu

[mailto:tao-user...@list.isis.vanderbilt.edu] On Behalf Of Adam
Mitz
Sent: Thursday, 19 January 2012 15:59
To: tao-...@list.isis.vanderbilt.edu
Subject: Re: [tao-users] Copying corba data to STL types.

On 1/19/2012 5:57 AM, Nick.A...@generaldynamics.uk.com wrote:

{

// create a std vector and populate it.
std::vector < char > srcvec( 5 );
srcvec[0] = 'h';
srcvec[1] = 'e';
srcvec[2] = 'l';
srcvec[3] = 'l';
srcvec[4] = 'o';

std::cout << "srcvec = ";
unsigned long nIndex;
for (nIndex = 0; nIndex < srcvec.size(); nIndex++)
{
std::cout << srcvec[ nIndex ];
}
std::cout << std::endl;

// translate it in to a corba type.
// idl code for the databody is:
// typedef sequence<octet> DataBody;
MDSB::ClientInterface::DataBody corbadata;

corbadata.length( srcvec.size() );
std::copy( srcvec.begin(),
srcvec.end(),
&corbadata[0] );

This code is invalid with any version of any C++ CORBA implementation.
It may have worked by chance with older versions of TAO. &corbdata[0]
is not guaranteed to be a model of OutputIterator for the C++ STL.

std::cout << "corbadata = ";
for (nIndex = 0; nIndex < corbadata.length(); nIndex++)
{
std::cout << corbadata[ nIndex ];
}
std::cout << std::endl;

// translate it back.
// using the std::vector constructor which takes in the
begining and end iterators.
// below line works with TAO 5.8.6 but not with tao 6.0.5
std::vector < char > destvec( &corbadata[0], &corbadata[
corbadata.length() ] );

Same problem here. &corbadata[x] is not an STL InputIterator.

If you want raw access to the sequence buffer, there are sequence
methods for that.

Thanks,
Adam Mitz
Senior Software Engineer
Object Computing, Inc.

[Adam Mitz]

On 1/19/2012 10:48 AM, Nick.A...@generaldynamics.uk.com wrote:
> Hi Adam.
>
> Thanks for that.
> We'll move to a less stl way of doing it and use the memcpy.
>

I think you may have missed the point of my previous post. I'm not sure
how memcpy() will behave differently than std::copy() here. When you
access an element of the CORBA Sequence with operator[], you can access
that one element -- it's not an iterator / array /
pointer-arithmetic-capable thing. There are methods in the sequence for
getting access to the underlying buffer.

[Andre Kostur]

Also, in 2.0.5, doesn't the unbounded_value_sequence type have .begin() and .end() methods?

_______________________________________________
tao-users mailing list
tao-...@list.isis.vanderbilt.edu
http://list.isis.vanderbilt.edu/mailman/listinfo/tao-users

--

Andre Kostur Senior Product Design Engineer P: 604-678-2864 E: ako...@incognito.com Toll-Free: 1-800-877-1856	F: 604-678-2864 VoIP: sip:8...@sip.incognito.com

[Adam Mitz]

On 1/19/2012 2:53 PM, Andre Kostur wrote:
> Also, in 2.0.5, doesn't the unbounded_value_sequence type have
> .begin() and .end() methods?

It might, but the methods defined by the specification work fine for all
sequences in all versions of TAO and any other compliant C++ ORB.

Octet sequence works a little differently than the other value sequences
and it doesn't seem to have begin(). See Unbounded_Octet_Sequence_T.h.

[M Hayman]

This thread offers a good example of why Northrop has been periodically & incrementally sponsoring Remedy IT to help them define and build a preliminary implementation of the newly evolving OMG IDL to C++11 mappings for A+T+C+D.  Problems like this would go away with the newer STL friendly APIs.  In fact, my understanding is that such a copy wouldn't even be required at all since a CORBA sequence would already BE a std::vector by default.

If there are any others out there in the user community who would also like to see a new C++ mapping option sooner rather than later, I'd encourage you to kick in with your own incremental sponsorship to help Remedy along :).

M. Hayman
Northrop Grumman

On Thu, Jan 19, 2012 at 11:48 AM, <Nick.A...@generaldynamics.uk.com> wrote:

Hi Adam.

Thanks for that.
We'll move to a less stl way of doing it and use the memcpy.

Thanks,
Adam Mitz
Senior Software Engineer
Object Computing, Inc.

This email and any files attached are intended for the addressee and may contain information of a confidential nature. If you are not the intended recipient, be aware that this email was sent to you in error and you should not disclose, distribute, print, copy or make other use of this email or its attachments. Such actions, in fact, may be unlawful. In compliance with the various Regulations and Acts, General Dynamics United Kingdom Limited reserves the right to monitor (and examine for viruses) all emails and email attachments, both inbound and outbound. Email communications and their attachments may not be secure or error- or virus-free and the company does not accept liability or responsibility for such matters or the consequences thereof. General Dynamics United Kingdom Limited, Registered Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and Wales No: 1911653.

[Nadeau, Trent (ES)]

To add to Mark’s response, Remedy IT has example IDL and generated header files corresponding to the initial, incomplete version of the OMG IDL to C++11 mapping at https://osportal.remedy.nl/projects/idl2cppx0/repository/show/trunk/examples. The Sequence example in particular is applicable to this thread.

 

Trent Nadeau
Software Engineer

Northrop Grumman Electronic Systems

[Adam Mitz]

On 1/19/2012 3:58 PM, M Hayman wrote:
> This thread offers a good example of why Northrop has been
> periodically & incrementally sponsoring Remedy IT to help them define
> and build a preliminary implementation of the newly evolving OMG IDL
> to C++11 mappings for A+T+C+D. Problems like this would go away with
> the newer STL friendly APIs. In fact, my understanding is that such a
> copy wouldn't even be required at all since a CORBA sequence would
> already BE a std::vector by default.
>

I won't argue against evolving the specifications, that's a good idea
for the future of these middleware systems.

For the near term, solving these problems is possible -- and not that
difficult -- with the existing specs. I just worked on some code in
OpenDDS that builds a std::set from a CORBA Sequence. It's just two
method calls (one if you already have the length).

[Johnny Willemsen]

Hi,

> Also, in 2.0.5, doesn't the unbounded_value_sequence type have .begin()
> and .end() methods?

These methods are only available when TAO_HAS_SEQUENCE_ITERATORS is
defined to 1. The problem is that this non spec compliant addition has
several bugs which wheren't addressed by the original author. At this
moment that addition is on the list of things we are scheduling to
remove, it is a feature that has bugs and is never tested by the core
team at all.

Johnny

>
> On Thu, Jan 19, 2012 at 08:58, Adam Mitz <mi...@ociweb.com
> <mailto:mi...@ociweb.com>> wrote:
>
> On 1/19/2012 10:48 AM, Nick.A...@generaldynamics.uk.com

> <mailto:Nick.A...@generaldynamics.uk.com> wrote:
> > Hi Adam.
> >
> > Thanks for that.
> > We'll move to a less stl way of doing it and use the memcpy.
> >
>

> I think you may have missed the point of my previous post. I'm not sure
> how memcpy() will behave differently than std::copy() here. When you
> access an element of the CORBA Sequence with operator[], you can access
> that one element -- it's not an iterator / array /
> pointer-arithmetic-capable thing. There are methods in the sequence for
> getting access to the underlying buffer.
>

> Thanks,
> Adam Mitz
> Senior Software Engineer
> Object Computing, Inc.

> _______________________________________________
> tao-users mailing list
> tao-...@list.isis.vanderbilt.edu

> <mailto:tao-...@list.isis.vanderbilt.edu>
> http://list.isis.vanderbilt.edu/mailman/listinfo/tao-users
>
>
>
>
> --
> *Andre Kostur*
> Senior Product Design Engineer
> *P:* 604-678-2864
> *E:* ako...@incognito.com <mailto:ako...@incognito.com>
> *Toll-Free:* 1-800-877-1856
>
>
> *F:* 604-678-2864
> *VoIP:* sip:8...@sip.incognito.com
>
> Incognito Software Inc. <http://www.incognito.com>
>
> <http://www.incognito.com/company/events>

[Johnny Willemsen]

Hi,

If people want to read more background details, see
http://www.orbzone.org for the IDL to C++11 discussion forum. Feel free
to register for an account and join the discussion for this new language
mapping.

As Mark mentioned NGC is one of the sponsors funding this new language
mapping. Through this funding we are working on a revised submission and
an implementation. We are looking for more sponsors to finish the
mapping and implementation and release it to the community.

Besides the examples on OSPortal we are able to take almost any IDL file
and generate the files that show the new API and types for your IDL. If
you want to see how things would like for your IDL, feel free to contact
me to get your IDL processed by our new tooling.

Best regards,

Johnny Willemsen
http://www.theaceorb.nl

On 01/19/2012 11:14 PM, Nadeau, Trent (ES) wrote:
> To add to Mark’s response, Remedy IT has example IDL and generated
> header files corresponding to the initial, incomplete version of the OMG
> IDL to C++11 mapping at
> https://osportal.remedy.nl/projects/idl2cppx0/repository/show/trunk/examples.
> The Sequence example in particular is applicable to this thread.
>
> Trent Nadeau
> Software Engineer
>
> Northrop Grumman Electronic Systems
>

> *From:*tao-user...@list.isis.vanderbilt.edu
> [mailto:tao-user...@list.isis.vanderbilt.edu] *On Behalf Of *M Hayman
> *Sent:* Thursday, January 19, 2012 4:59 PM
> *To:* Nick.A...@generaldynamics.uk.com
> *Cc:* tao-...@list.isis.vanderbilt.edu
> *Subject:* EXT :Re: [tao-users] Copying corba data to STL types.

>
> This thread offers a good example of why Northrop has been periodically
> & incrementally sponsoring Remedy IT to help them define and build a
> preliminary implementation of the newly evolving OMG IDL to C++11
> mappings for A+T+C+D. Problems like this would go away with the newer
> STL friendly APIs. In fact, my understanding is that such a copy
> wouldn't even be required at all since a CORBA sequence would already BE
> a std::vector by default.
>

> If there are any others out there in the user community who would also
> like to see a new C++ mapping option sooner rather than later, I'd
> encourage you to kick in with your own incremental sponsorship to help
> Remedy along :).
>
> M. Hayman
> Northrop Grumman
>

> On Thu, Jan 19, 2012 at 11:48 AM, <Nick.A...@generaldynamics.uk.com

> <mailto:Nick.A...@generaldynamics.uk.com>> wrote:
>
> Hi Adam.
>
> Thanks for that.
> We'll move to a less stl way of doing it and use the memcpy.
>

> Thanks.
> Nick.
>
>
>
>
> Nick Adamson
> Software Engineer
>
> C4I Systems
>
> General Dynamics United Kingdom Limited
> Bryn Brithdir, Oakdale Business Park, Blackwood, South Wales, NP12 4AA
>

> Telephone: +44 (0) 1495 236467 <tel:%2B44%20%280%29%201495%20236467>

> Email: Nick.A...@generaldynamics.uk.com
> <mailto:Nick.A...@generaldynamics.uk.com>
> Website: www.generaldynamics.uk.com <http://www.generaldynamics.uk.com>
>

> Please consider the environment before printing this email
>
> -----Original Message-----
> From: tao-user...@list.isis.vanderbilt.edu
> <mailto:tao-user...@list.isis.vanderbilt.edu>
> [mailto:tao-user...@list.isis.vanderbilt.edu
> <mailto:tao-user...@list.isis.vanderbilt.edu>] On Behalf Of Adam
> Mitz
> Sent: Thursday, 19 January 2012 15:59
> To: tao-...@list.isis.vanderbilt.edu
> <mailto:tao-...@list.isis.vanderbilt.edu>
> Subject: Re: [tao-users] Copying corba data to STL types.
>

> On 1/19/2012 5:57 AM, Nick.A...@generaldynamics.uk.com
> <mailto:Nick.A...@generaldynamics.uk.com> wrote:
>
> {

> Thanks,
> Adam Mitz
> Senior Software Engineer
> Object Computing, Inc.
>
>
>

> This email and any files attached are intended for the addressee and may
> contain information of a confidential nature. If you are not the
> intended recipient, be aware that this email was sent to you in error
> and you should not disclose, distribute, print, copy or make other use
> of this email or its attachments. Such actions, in fact, may be
> unlawful. In compliance with the various Regulations and Acts, General
> Dynamics United Kingdom Limited reserves the right to monitor (and
> examine for viruses) all emails and email attachments, both inbound and
> outbound. Email communications and their attachments may not be secure
> or error- or virus-free and the company does not accept liability or
> responsibility for such matters or the consequences thereof. General
> Dynamics United Kingdom Limited, Registered Office: 21 Holborn Viaduct,
> London EC1A 2DY. Registered in England and Wales No: 1911653.
>

> _______________________________________________
> tao-users mailing list
> tao-...@list.isis.vanderbilt.edu
> <mailto:tao-...@list.isis.vanderbilt.edu>
> http://list.isis.vanderbilt.edu/mailman/listinfo/tao-users
>
>
>