c++.stlsoft - STLSoft 1.8.2 released
- Matthew (15/15) Oct 10 2004 Bug fixes, and minor modifications. There's only one major change: the
- Pablo Aguilar (3/18) Oct 11 2004 Again, rangelib folder is missing from the "full" download...
- Matthew (12/34) Oct 12 2004 Gah! I'm a fool
- Adi Shavit (4/19) Oct 15 2004 What's ACESTL?
- Matthew (18/43) Oct 15 2004 A set of components that work with ACE - the Adaptive Communications
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
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
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> 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...theBug fixes, and minor modifications. There's only one major change:stlsoft::auto_buffer.implicit conversion operator has been removed fromeitherTo access the address of the first element as a pointer, you mustcomponents,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* extantinso it may be a trifle dodgy. (Which is better than a dodgy trifle,rangeanyone'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
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
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...theBug fixes, and minor modifications. There's only one major change:stlsoft::auto_buffer.implicit conversion operator has been removed fromeitherTo access the address of the first element as a pointer, you mustcomponents,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* extantinso it may be a trifle dodgy. (Which is better than a dodgy trifle,rangeanyone'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