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

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

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:
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
>
>

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
>
>

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:
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
> >
> >
>
>