Issue 75: Access to sequence buffers (cxx_revision) Source: (, ) Nature: ENHANCEMENT Severity: Serious Summary: Summary: We would like to see an enhancement which allows access to sequence buffers once they have been constructed. Resolution: Fixed Revised Text: Actions taken: August 13, 1996: Received issue February 19, 1999: closed issue Discussion: End of Annotations:===== >From vinoski@apollo.hp.com Thu Aug 8 15:41:57 1996 Received: from amway.ch.apollo.hp.com by amethyst.omg.org (5.4R2.01/1.34) id AA25699; Thu, 8 Aug 1996 15:41:57 -0400 Received: from nis_mstr.ch.apollo.hp.com by amway.ch.apollo.hp.com id Thu, 8 Aug 1996 15:38:38 -0400 Received: from earl.ch.apollo.hp.com by nis_mstr.ch.apollo.hp.com id AA258193117; Thu, 8 Aug 1996 15:38:37 -0400 Message-Id: <2.2.32.19960808193802.0068fed4@pop-e3.ch.apollo.hp.com> X-Sender: vinoski@pop-e3.ch.apollo.hp.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 08 Aug 1996 15:38:02 -0400 To: cxx-revision@omg.org, issues@omg.org From: Steve Vinoski Subject: access to sequence buffers We've run into applications that require direct access to the buffers used to hold sequence data. Currently, sequences allow users to construct them from their own buffers, but they do not allow access to the buffer inside once constructed. Traffic on comp.object.corba lately has also been bemoaning the fact that sequence buffers can't be accessed. People are using sequence to transmit large chunks of data and are running into performance problems because they can only access the data using operator[]. HP proposes that something like the following be added for the C++ language mapping for sequences. --steve class MySeq { // provides read access to the sequence's elements: const T* buffer() const; // is the sequence responsible for managing this // buffer and its elements? CORBA::Boolean manage_buffer() const; // provides write access to the sequence's elements: // (if "manage_buffer()" is true, then caller must // release the element before writing over it) T* buffer() const; // reset the sequence's buffer (just like the "data" // constructors") (causes the sequence to forget/release // the old buffer based on whether or not it was // responsible for releasing the old buffer, then causes // the sequence to adopt/reference the new buffer based // on the new release flag // for bounded sequences: void buffer( CORBA::ULong length, T* data, CORBA::Boolean release = 0); ); // for unbounded sequences: void buffer( CORBA::ULong max, CORBA::ULong length, T* data, CORBA::Boolean release = 0 ); // detach the sequence from its buffer. // if "manage_buffer" is true, then the caller // becomes responsible for managing the buffer and its // elements. after this call, the sequence is // of length 0. this, combined with "void buffer(...)" // can be used to transfer a buffer from one sequence // to another without having to copy the elements. T* detach_buffer(); }; Return-Path: From: "Ian Pepper" To: Subject: Issue 75: Access to sequence buffers Date: Wed, 14 Jan 1998 11:18:36 -0000 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Re the proposal to add two new member functions to sequence types: BUFTYPE get_buffer(CORBA::Boolean orphan = 0); const BUFTYPE get_buffer() const; It seems to me that this may be a little restrictive, in that it assumes that the underlying representation is a contiguous buffer. While this may the case for 99% of ORBs, there may be restrictions to the size of a buffer imposed by the underlying OS or environment e.g. some realtime environments have a segmented memory architecture. If this is indeed an issue, then I suggest some text should be added to the specification pointing this out. Ian Ian Pepper, Software Architect ApTest Ireland Ltd, Ph: +353-1-662 9012 52 Leeson St Lwr, Fax: +353-1-662 7102 Dublin 2, IRELAND Email: ian@aptest.ie