www.digitalmars.com         C & C++   DMDScript  

c++.stlsoft - STLSoft 1.8.2 released

reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
Bug fixes, and minor modifications. There's only one major change: the
implicit conversion operator has been removed from stlsoft::auto_buffer.
To access the address of the first element as a pointer, you must either
use the data() member, or take its address by &buf[0].

If you want the old behaviour, there's a
_STLSOFT_AUTO_BUFFER_ALLOW_NON_CONST_CONVERSION_OPERATOR #define,
although I've not tested its compatibility with *all* extant components,
so it may be a trifle dodgy. (Which is better than a dodgy trifle, in
anyone's game, eh?)

The other non-fix/mod change is the addition of the r_copy_if() range
algorithm to the range library. There'll be a lot more range stuff
coming up in the next release, as well as the first beta of the new
ACESTL sub-project.

Cheers

Matthew
Oct 10 2004
next sibling parent reply "Pablo Aguilar" <paguilarg hotmail.com> writes:
Again, rangelib folder is missing from the "full" download...

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message 
news:ckcqfv$bm5$1 digitaldaemon.com...
 Bug fixes, and minor modifications. There's only one major change: the
 implicit conversion operator has been removed from stlsoft::auto_buffer.
 To access the address of the first element as a pointer, you must either
 use the data() member, or take its address by &buf[0].

 If you want the old behaviour, there's a
 _STLSOFT_AUTO_BUFFER_ALLOW_NON_CONST_CONVERSION_OPERATOR #define,
 although I've not tested its compatibility with *all* extant components,
 so it may be a trifle dodgy. (Which is better than a dodgy trifle, in
 anyone's game, eh?)

 The other non-fix/mod change is the addition of the r_copy_if() range
 algorithm to the range library. There'll be a lot more range stuff
 coming up in the next release, as well as the first beta of the new
 ACESTL sub-project.

 Cheers

 Matthew

Oct 11 2004
parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
Gah! I'm a fool

Thanks for spotting. I'm amending the build script right now.

Cheers

Matthew


"Pablo Aguilar" <paguilarg hotmail.com> wrote in message
news:ckf33h$2ai8$1 digitaldaemon.com...
 Again, rangelib folder is missing from the "full" download...

 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
 news:ckcqfv$bm5$1 digitaldaemon.com...
 Bug fixes, and minor modifications. There's only one major change:


 implicit conversion operator has been removed from


 To access the address of the first element as a pointer, you must


 use the data() member, or take its address by &buf[0].

 If you want the old behaviour, there's a
 _STLSOFT_AUTO_BUFFER_ALLOW_NON_CONST_CONVERSION_OPERATOR #define,
 although I've not tested its compatibility with *all* extant


 so it may be a trifle dodgy. (Which is better than a dodgy trifle,


 anyone's game, eh?)

 The other non-fix/mod change is the addition of the r_copy_if()


 algorithm to the range library. There'll be a lot more range stuff
 coming up in the next release, as well as the first beta of the new
 ACESTL sub-project.

 Cheers

 Matthew


Oct 12 2004
prev sibling parent reply "Adi Shavit" <adish gentech.co.il> writes:
What's ACESTL?
Adi

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:ckcqfv$bm5$1 digitaldaemon.com...
 Bug fixes, and minor modifications. There's only one major change: the
 implicit conversion operator has been removed from stlsoft::auto_buffer.
 To access the address of the first element as a pointer, you must either
 use the data() member, or take its address by &buf[0].

 If you want the old behaviour, there's a
 _STLSOFT_AUTO_BUFFER_ALLOW_NON_CONST_CONVERSION_OPERATOR #define,
 although I've not tested its compatibility with *all* extant components,
 so it may be a trifle dodgy. (Which is better than a dodgy trifle, in
 anyone's game, eh?)

 The other non-fix/mod change is the addition of the r_copy_if() range
 algorithm to the range library. There'll be a lot more range stuff
 coming up in the next release, as well as the first beta of the new
 ACESTL sub-project.

 Cheers

 Matthew

Oct 15 2004
parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
A set of components that work with ACE - the Adaptive Communications
Environment - to adapt it to STL-like behaviour. It's come about as a
result of my "real" work, in which I'm currently employed in writing
some networking components for a client.

So far, I've got a class that adapts an ACE_Message_Queue to an STL-like
sequence of bytes, and some other components for custom event handling.
As my current work evolves further over the next few weeks I expect
there'll be more. Eventually, these components would probably be
submitted to ACE, but that's some way off, so in the meantime they'll
live in ACESTL. :-)

"Adi Shavit" <adish gentech.co.il> wrote in message
news:ckpjqe$2rlp$1 digitaldaemon.com...
 What's ACESTL?
 Adi

 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
 news:ckcqfv$bm5$1 digitaldaemon.com...
 Bug fixes, and minor modifications. There's only one major change:


 implicit conversion operator has been removed from


 To access the address of the first element as a pointer, you must


 use the data() member, or take its address by &buf[0].

 If you want the old behaviour, there's a
 _STLSOFT_AUTO_BUFFER_ALLOW_NON_CONST_CONVERSION_OPERATOR #define,
 although I've not tested its compatibility with *all* extant


 so it may be a trifle dodgy. (Which is better than a dodgy trifle,


 anyone's game, eh?)

 The other non-fix/mod change is the addition of the r_copy_if()


 algorithm to the range library. There'll be a lot more range stuff
 coming up in the next release, as well as the first beta of the new
 ACESTL sub-project.

 Cheers

 Matthew


Oct 15 2004