Finally got around to downloading 1.8.3b2

1. Saw scoped_handle. Great! Just one suggestion, though. You could do a
parallel version with a static destruction policy, might come in handy...
(see Jonathan Turkanis' move_ptr at
http://www.kangaroologic.com/move_ptr/libs/move_ptr/doc/index.html)
2. The docs for string_view say "it is US to the caller", where I believe it
should say "UP"
3. Also for string_view: empty_string_ seems to be a utility function for
returning something when you own nothing, but then c_str() doesn't use it
and duplicates the static buffer
4. I see you've addressed the STL's map's problems you were complaining
about on the D newgroup (containter_access.hpp doesn't hint at all at being
about associative containers, is that on purpose?)
5. I've no clue what options_verifier is for (I tried reading the source
code, but it didn't help.. :-( )
6. I wonder what the difference would be between using:
        copy(seq.begin(), seq.end(),
c_str_ptr_inserter(std::back_inserter(out)));
    and using:
        transform(seq.begin(), seq.end(), std::back_inserter(out),
c_str_ptr<seq_type::value_type>);
    Not that it matters much, just wondering...
7. How is using stlsoft::shared_ptr different/better than using boost's? (I
see it doesn't have the custom deleter option, so I guess it's lower on
memory footprint, but other than tha?)
8. The hierarchical directory structure looks better... it was getting
crowded in a single directory...

That's all I can say for now, haven't used this release yet, just looked through the code for a while...

One last comment though, (no offense intended! this is just IMO)

When I first discovered stlsoft (back in the 1.6.x days), I already knew and used boost. Having both libraries was great, boost for the std-like stuff and stlsoft for the platform specific stuff, it wasn't hard at all to decide what library to use when, or where to look for something I needed. Now, that the covered areas by both libraries are starting to overlap some more, I'm finding harder to figure out when and why to use each. So my suggestion would be, when you document a class, rather than just stating it's purpose I think it'd be very helpful to also state the "exceptional" features to it or how it compares to other implementations (you might want to look at Boost.Serialization's docs to get an idea of what I mean).

I know it's a good deal of work, and so this might just not be the moment for it (being that your very busy writting the libraries in the first place! and DPD, and what not...). At first glance, I thought it might not be a good idea to repeat work done by boost, and that being more used to boost I'd be biased towards using it when having the same functionality available. Later I rememberd your rule of "header only", and thought "well, that comes in handy when I don't want to go through building an entire library and it's dependencies just to get a single function I need". This is the one most important reason I can think of for choosing (for instance Xstl::path instead of boost::path). Another would be a cleaner interface (as in stlsoft::string_tokeniser vs boost::tokenizer). But then, how do I pick between shared_ptr-s?

Anyway, those are my thoughts for now..
Hope you find them useful...


Pablo Aguilar

"Pablo Aguilar" <paguilarg@hotmail.com> wrote in message news:d157rq$2rk1$1@digitaldaemon.com...
> Finally got around to downloading 1.8.3b2
>
> 1. Saw scoped_handle. Great! Just one suggestion, though. You could do
> a parallel version with a static destruction policy, might come in
> handy... (see Jonathan Turkanis' move_ptr at
> http://www.kangaroologic.com/move_ptr/libs/move_ptr/doc/index.html)
> 2. The docs for string_view say "it is US to the caller", where I
> believe it should say "UP"
> 3. Also for string_view: empty_string_ seems to be a utility function
> for returning something when you own nothing, but then c_str() doesn't
> use it and duplicates the static buffer
> 4. I see you've addressed the STL's map's problems you were
> complaining about on the D newgroup (containter_access.hpp doesn't
> hint at all at being about associative containers, is that on
> purpose?)
> 5. I've no clue what options_verifier is for (I tried reading the
> source code, but it didn't help.. :-( )
> 6. I wonder what the difference would be between using:
>        copy(seq.begin(), seq.end(),
> c_str_ptr_inserter(std::back_inserter(out)));
>    and using:
>        transform(seq.begin(), seq.end(), std::back_inserter(out),
> c_str_ptr<seq_type::value_type>);
>    Not that it matters much, just wondering...
> 7. How is using stlsoft::shared_ptr different/better than using
> boost's? (I see it doesn't have the custom deleter option, so I guess
> it's lower on memory footprint, but other than tha?)
> 8. The hierarchical directory structure looks better... it was getting
> crowded in a single directory...
>
> That's all I can say for now, haven't used this release yet, just looked through the code for a while...
>
> One last comment though, (no offense intended! this is just IMO)
>
> When I first discovered stlsoft (back in the 1.6.x days), I already knew and used boost. Having both libraries was great, boost for the std-like stuff and stlsoft for the platform specific stuff, it wasn't hard at all to decide what library to use when, or where to look for something I needed. Now, that the covered areas by both libraries are starting to overlap some more, I'm finding harder to figure out when and why to use each. So my suggestion would be, when you document a class, rather than just stating it's purpose I think it'd be very helpful to also state the "exceptional" features to it or how it compares to other implementations (you might want to look at Boost.Serialization's docs to get an idea of what I mean).
>
> I know it's a good deal of work, and so this might just not be the moment for it (being that your very busy writting the libraries in the first place! and DPD, and what not...). At first glance, I thought it might not be a good idea to repeat work done by boost, and that being more used to boost I'd be biased towards using it when having the same functionality available. Later I rememberd your rule of "header only", and thought "well, that comes in handy when I don't want to go through building an entire library and it's dependencies just to get a single function I need". This is the one most important reason I can think of for choosing (for instance Xstl::path instead of boost::path). Another would be a cleaner interface (as in stlsoft::string_tokeniser vs boost::tokenizer). But then, how do I pick between shared_ptr-s?
>
> Anyway, those are my thoughts for now..
> Hope you find them useful...

I have, and will attempt to address them all either in 1.8.3 or 1.9.1.

Of course, some help on the docs wouldn't be rejected ... ;-)

Cheers

Matthew

>> Anyway, those are my thoughts for now..
>> Hope you find them useful...
>
> I have, and will attempt to address them all either in 1.8.3 or 1.9.1.
>
> Of course, some help on the docs wouldn't be rejected ... ;-)
>
> Cheers
>
> Matthew

Lets assume for a minute I've enough time to spare to help out. How'd I go about it?

Note that I've never really USED doxygen, I've tried it out, but not to a fully working extent.


Pablo

"Pablo Aguilar" <paguilarg@hotmail.com> wrote in message news:d1d8mk$294u$1@digitaldaemon.com...
>>> Anyway, those are my thoughts for now..
>>> Hope you find them useful...
>>
>> I have, and will attempt to address them all either in 1.8.3 or 1.9.1.
>>
>> Of course, some help on the docs wouldn't be rejected ... ;-)
>>
>> Cheers
>>
>> Matthew
>
> Lets assume for a minute I've enough time to spare to help out. How'd I go about it?

Not really sure, but I'm open to suggestions.

> Note that I've never really USED doxygen, I've tried it out, but not to a fully working extent.

Well, it's braindeadedly simple - it must be, because I've taken to use it rather than writing my own. ;)

I don't doubt for a second that you can work it out from the examples in the code, although I am sometimes forced to open up Doxygen's help.

As for how we might proceed, I'd say initially I'd be quite happy for you to just have a go at a couple of compoents, and send me the files. I can then bring those diffs into the mainstream, and run the doc stuff and see how it looks. If there're any Doxygen nuances that you've skipped I can fix it up and send you a note.

How's that sound?

Yours, grateful in anticipation :-)

Matthew

>> Lets assume for a minute I've enough time to spare to help out. How'd I go about it?
>
> Not really sure, but I'm open to suggestions.
>
>> Note that I've never really USED doxygen, I've tried it out, but not to a fully working extent.
>
> Well, it's braindeadedly simple - it must be, because I've taken to use it rather than writing my own. ;)
>
> I don't doubt for a second that you can work it out from the examples in the code, although I am sometimes forced to open up Doxygen's help.
>
> As for how we might proceed, I'd say initially I'd be quite happy for you to just have a go at a couple of compoents, and send me the files. I can then bring those diffs into the mainstream, and run the doc stuff and see how it looks. If there're any Doxygen nuances that you've skipped I can fix it up and send you a note.
>
> How's that sound?
>
> Yours, grateful in anticipation :-)
>
> Matthew

Sounds ok, any module in particular you're interested in? or should I just take my pick?


Pablo

"Pablo Aguilar" <paguilarg@hotmail.com> wrote in message news:d1ffgv$2520$1@digitaldaemon.com...
>>> Lets assume for a minute I've enough time to spare to help out. How'd I go about it?
>>
>> Not really sure, but I'm open to suggestions.
>>
>>> Note that I've never really USED doxygen, I've tried it out, but not to a fully working extent.
>>
>> Well, it's braindeadedly simple - it must be, because I've taken to use it rather than writing my own. ;)
>>
>> I don't doubt for a second that you can work it out from the examples in the code, although I am sometimes forced to open up Doxygen's help.
>>
>> As for how we might proceed, I'd say initially I'd be quite happy for you to just have a go at a couple of compoents, and send me the files. I can then bring those diffs into the mainstream, and run the doc stuff and see how it looks. If there're any Doxygen nuances that you've skipped I can fix it up and send you a note.
>>
>> How's that sound?
>>
>> Yours, grateful in anticipation :-)
>>
>> Matthew
>
> Sounds ok, any module in particular you're interested in? or should I just take my pick?

Whatever you think is currently the most poorly documented, I guess.

I'd also be interested in any general thoughts of how to present "The STLSoft Message". Naturally, being inside it, it's hard for me to know what's missing from the general picture.

Thanks

Matthew

> 1. Saw scoped_handle. Great! Just one suggestion, though. You could do a parallel version with a static destruction policy, might come in handy... (see Jonathan Turkanis' move_ptr at http://www.kangaroologic.com/move_ptr/libs/move_ptr/doc/index.html)

As it happens, Jonathon's currently reviewing the instalment for Bjorn and my column that discusses scoped_handle, and is making some good suggestions about how the series on smart pointers might be aimed. His review of scoped_handle is that it's pretty good as it is. ;)

> 2. The docs for string_view say "it is US to the caller", where I believe it should say "UP"

Fixed.

> 3. Also for string_view: empty_string_ seems to be a utility function for returning something when you own nothing, but then c_str() doesn't use it and duplicates the static buffer


Fixed.

> 4. I see you've addressed the STL's map's problems you were complaining about on the D newgroup (containter_access.hpp doesn't hint at all at being about associative containers, is that on purpose?)


No. That should probably be fixed.

> 5. I've no clue what options_verifier is for (I tried reading the source code, but it didn't help.. :-( )

Check out http://www.cuj.com/documents/cujexp0412wilson/

> 6. I wonder what the difference would be between using:
>        copy(seq.begin(), seq.end(), c_str_ptr_inserter(std::back_inserter(out)));
>    and using:
>        transform(seq.begin(), seq.end(), std::back_inserter(out), c_str_ptr<seq_type::value_type>);
>    Not that it matters much, just wondering...

No idea! LOL

Can't think about that at the mo. Brain hurts

> 7. How is using stlsoft::shared_ptr different/better than using boost's? (I see it doesn't have the custom deleter option, so I guess it's lower on memory footprint, but other than tha?)

Conceptually, I have no idea. I suspect it's the minimum no-frills equivalent, missing all that groovy remote deletion stuff that Scott Meyers is a big fan of. ;)

Practically, it means you don't have to use Boost. Whether thats boon or bane, I cannot comment ....

> 8. The hierarchical directory structure looks better... it was getting crowded in a single directory...

Now 1.8.3 is out, I think the benefits are clear.

As 1.8.x progresses, content will gradually be moved into the redirect files in the sub-directories.

My plan is that by 1.9.1 all files in the root directory will be redirect files, and that in 1.10.x they will be removed entirely, and available as a separate distribution.

> That's all I can say for now, haven't used this release yet, just looked through the code for a while...
>
> One last comment though, (no offense intended! this is just IMO)
>
> When I first discovered stlsoft (back in the 1.6.x days), I already knew and used boost. Having both libraries was great, boost for the std-like stuff and stlsoft for the platform specific stuff, it wasn't hard at all to decide what library to use when, or where to look for something I needed. Now, that the covered areas by both libraries are starting to overlap some more, I'm finding harder to figure out when and why to use each.

I can see how that would be a little confusing.

> So my suggestion would be, when you document a class, rather than just stating it's purpose I think it'd be very helpful to also state the "exceptional" features to it or how it compares to other implementations (you might want to look at Boost.Serialization's docs to get an idea of what I mean).

Good idea. Why don't you start with a simple example? In fact, since you helped me work on them, what about doing your best job on the String Slice Functions. If you set me a good example, I promise I will follow up on other components. :-)

> I know it's a good deal of work, and so this might just not be the moment for it (being that your very busy writting the libraries in the first place! and DPD, and what not...).

Actually I'm in a documentation phase for the networking project I did for my client, and then I'll be full-tilt in writing Extended STL. DPD has been left for later in the year.

> At first glance, I thought it might not be a good idea to repeat work done by boost, and that being more used to boost I'd be biased towards using it when having the same functionality available. Later I rememberd your rule of "header only", and thought "well, that comes in handy when I don't want to go through building an entire library and it's dependencies just to get a single function I need". This is the one most important reason I can think of for choosing (for instance Xstl::path instead of boost::path).

I agree.

> Another would be a cleaner interface (as in stlsoft::string_tokeniser vs boost::tokenizer).

Indeed. And if you think that's a significant comparison, try out the multidimensional array class templates!

You should also bear in mind that most STLSoft components are written with efficiency and portability given very high consideration. Think of me as the mad nephew of Bjarne Stroustrup in that regard.

> But then, how do I pick between shared_ptr-s?

You probably shouldn't. I've no doubt the Boost one is superior in functionality, because I wrote mine as a stop-gap until C++0x, and it's served all my needs in its current form thus far. When it doesn't, or when someone else needs more functionality and lets me know, it will evolve, but not before then.

> Anyway, those are my thoughts for now..
> Hope you find them useful...

I do. Thanks