Re: [dev] [HOTD] comphelper::sequenceToContainer friends
Hi Frank, On Mon, Oct 31, 2005 at 08:47:06 +0100, Frank Schönheit wrote: Hmm. Is a wiki really better for discussing things which are still evolving? For discussion it depends. Lengthy discussions may be better handled by mail, at least if participants know how to quote ... shorter discussion is also ok in a wiki if it stays ontopic. On the other hand, you can also group the discussion nicely by topic or whatever you like, and gain more overview than by mail. See Wikipedia, there is a discussion page for each individual topic, same in the go-ooo wiki, just that there isn't much content in discussions yet. For the sample code it would be better to live in a wiki. Having several levels of quotes in mail interspersed with new code fragments and arbitrary line breaks inserted by incapable mail tools doesn't really add to clearness. The advantage of a wiki is that you immediately see the current final version, but still have the diffs available, much the same as with any versioning system. You simply can't do that with mail. Futhermore, a wiki is searchable. The Collab mailing list archives are just a pain in this regard, and if at all don't produce results that would really fit the query, mildly spoken. Going to mail-archive.com helps, and even better if you happen to keep your own mail archive and use a capable mailer that can do a full body text search. Still, for collaborative editing I think a wiki is predestinated. My (who I am seldomly working with Wikis, admittedly) impression with Wikis is that they are not really good in exchanging opinions about a problem, on the track to a final mutual solution. Mailing lists have the advantage to track opinions over time, by the natural sequence of mail flow and immediately visible in quote hierarchies. Wikis have the advantage of being able to group topics and rearrange things over time. Combining both cultures seems appropriate, such as putting the snippets into the wiki and discussing them on the list, giving a pointer. Summarizing the discussion in the wiki again could be another option, though I don't think that would happen frequently, developers don't do such things ;-) Eike -- OOo/SO Calc core developer. Number formatter bedevilled i18n transpositionizer. GnuPG key 0x293C05FD: 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] [HOTD] comphelper::sequenceToContainer friends
Frank Schönheit - Sun Microsystems Germany wrote: Hi Eike, If DstType and SrcType refer to the same type (which is often the case), using one of Sequence's ctors is faster, i.e. [...] This is a perfectly good example of why a wiki is better for such type of collaborative work than a mailing list could ever be.. Hmm. Is a wiki really better for discussing things which are still evolving? My (who I am seldomly working with Wikis, admittedly) impression with Wikis is that they are not really good in exchanging opinions about a problem, on the track to a final mutual solution. I think they can be really good at it. I've used a wiki for one issue (12719) to draft a specification - this means that different people can edit the document in a nice ad-hoc way. You can always use a wiki page to have separate sections for different opinions if this is needed. However I think sometimes email / chat is better for debate David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] [HOTD] comphelper::sequenceToContainer friends
Hi David, However I think sometimes email / chat is better for debate Think so, too. And I *do* expect debates if people really start introducing their pet helper classes :) Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Database http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] [HOTD] comphelper::sequenceToContainer friends
Hi Eike, If DstType and SrcType refer to the same type (which is often the case), using one of Sequence's ctors is faster, i.e. [...] This is a perfectly good example of why a wiki is better for such type of collaborative work than a mailing list could ever be.. Hmm. Is a wiki really better for discussing things which are still evolving? My (who I am seldomly working with Wikis, admittedly) impression with Wikis is that they are not really good in exchanging opinions about a problem, on the track to a final mutual solution. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Database http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] [HOTD] comphelper::sequenceToContainer friends
Hi, On Wed, Oct 26, 2005 at 19:12:19 +0200, Daniel Bölzle wrote: [...] If DstType and SrcType refer to the same type (which is often the case), using one of Sequence's ctors is faster, i.e. [...] This is a perfectly good example of why a wiki is better for such type of collaborative work than a mailing list could ever be.. Eike -- OOo/SO Calc core developer. Number formatter bedevilled i18n transpositionizer. GnuPG key 0x293C05FD: 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] [HOTD] comphelper::sequenceToContainer friends (was: [dev] Helper of the Day: call for papers)
Frank Schönheit - Sun Microsystems Germany [EMAIL PROTECTED] writes:
What do you think?
Hey - this is a _damn_ good idea! I take the liberty to just start
with it, hopefully short-circuiting a long and fruitful discussion,
which just keeps us from doing TheRightThing (tm) right away!
-%---
C++ Sequence to/from STL container converter
From time to time, one needs to convert from a uno::Sequence to and
fro a STL container or a plain old array. If you need to copy anyway
(instead of somehow facading the uno::Sequence with something that
masquerades it as an STL container), use these function templates
(from comphelper/sequence.hxx):
/** Copy from a plain C/C++ array into a Sequence.
@tpl SrcType
Array element type. Must be assignable to DstType
@tpl DstType
Sequence element type. Must be assignable from SrcType
@param i_pArray
Valid pointer to at least num elements of type SrcType
@param nNum
Number of array elements to copy
@return the resulting Sequence
@attention when copying from e.g. a double array to a
Sequenceint, no proper rounding will be performed, but the
values will be truncated. There's currently no measure to
prevent or detect precision loss, overflow or truncation.
*/
template typename DstType, typename SrcType
::com::sun::star::uno::Sequence DstType arrayToSequence( const SrcType*
i_pArray, sal_Int32 nNum )
{
::com::sun::star::uno::Sequence DstType result( nNum );
::std::copy( i_pArray, i_pArray+nNum, result.getArray() );
return result;
}
//-
/** Copy from a Sequence into a plain C/C++ array
@tpl SrcType
Sequence element type. Must be assignable to DstType
@tpl DstType
Array element type. Must be assignable from SrcType
@param io_pArray
Valid pointer to at least i_Sequence.getLength() elements of
type DstType
@param i_Sequence
Reference to a Sequence of SrcType elements
@return a pointer to the array
@attention when copying from e.g. a Sequencedouble to an int
array, no proper rounding will be performed, but the values
will be truncated. There's currently no measure to prevent or
detect precision loss, overflow or truncation.
*/
template typename DstType, typename SrcType
DstType* sequenceToArray( DstType* io_pArray, const
::com::sun::star::uno::Sequence SrcType i_Sequence )
{
::std::copy( i_Sequence.getConstArray(),
i_Sequence.getConstArray()+i_Sequence.getLength(), io_pArray );
return io_pArray;
}
//-
/** Copy from a container into a Sequence
@tpl SrcType
Container type. This type must fulfill the STL container
concept, in particular, the size(), begin() and end() methods
must be available and have the usual semantics.
@tpl DstType
Sequence element type. Must be assignable from SrcType's
elements
@param i_Container
Reference to the input contain with elements of type SrcType
@return the generated Sequence
@attention this function always performs a copy. Furthermore,
when copying from e.g. a vectordouble to a Sequenceint, no
proper rounding will be performed, but the values will be
truncated. There's currently no measure to prevent or detect
precision loss, overflow or truncation.
*/
template typename DstType, typename SrcType
::com::sun::star::uno::Sequence DstType containerToSequence( const
SrcType i_Container )
{
::com::sun::star::uno::Sequence DstType result( i_Container.size() );
::std::copy( i_Container.begin(), i_Container.end(), result.getArray()
);
return result;
}
//-
/** Copy from a Sequence into a container
@tpl SrcType
Sequence element type. Must be assignable to SrcType's
elements
@tpl DstType
Container type. This type must fulfill the STL container and
sequence concepts, in particular, the begin(), end() and the
unary constructor DstType(int) methods must be available and
have the usual semantics.
@param i_Sequence
Reference to a Sequence of SrcType elements
@return a pointer to the generated container
@attention this function always performs a copy. Furthermore,
when copying from e.g. a Sequencedouble to a vectorint, no
proper rounding will be performed, but the values will be
Re: [dev] [HOTD] comphelper::sequenceToContainer friends
Hello,
template typename DstType, typename SrcType
::com::sun::star::uno::Sequence DstType arrayToSequence( const
SrcType* i_pArray, sal_Int32 nNum )
{
::com::sun::star::uno::Sequence DstType result( nNum );
::std::copy( i_pArray, i_pArray+nNum, result.getArray() );
return result;
}
If DstType and SrcType refer to the same type (which is often the case),
using one of Sequence's ctors is faster, i.e.
::com::sun::star::uno::SequenceDstType seq( pArray, nElements );
Adding a special
template typename T
inline ::com::sun::star::uno::SequenceT arrayToSequence(
T const* p, sal_Int32 n )
{
return ::com::sun::star::uno::SequenceT(p, n);
}
would most probably break existing code which has explicitly specified
DstType (= leads to ambiguity when DstType equals SrcType). So I
recommend to use that Sequence ctor directly whenever possible.
template typename DstType, typename SrcType
::com::sun::star::uno::Sequence DstType containerToSequence( const
SrcType i_Container )
{
::com::sun::star::uno::Sequence DstType result( i_Container.size()
);
::std::copy( i_Container.begin(), i_Container.end(),
result.getArray() );
return result;
}
The same optimization applies when copying from a std::vector; can
seamlessly be overloaded by adding
template typename T
inline ::com::sun::star::uno::SequenceT containerToSequence(
::std::vectorT const v )
{
return ::com::sun::star::uno::SequenceT( v[0], v.size() );
}
(No need to explicitly state the element type.)
I will add the latter function to comphelper/sequence.hxx if nobody
(incl. any compiler) complains.
regards,
-Daniel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
