• Pablo Aguilar (55/55) Mar 14 2005 Finally got around to downloading 1.8.3b2
• Matthew (6/62) Mar 17 2005 I have, and will attempt to address them all either in 1.8.3 or 1.9.1.
• Pablo Aguilar (5/11) Mar 17 2005 Lets assume for a minute I've enough time to spare to help out.
• Matthew (14/28) Mar 17 2005 Not really sure, but I'm open to suggestions.
• Pablo Aguilar (3/20) Mar 18 2005 Sounds ok, any module in particular you're interested in? or should I ju...
• Matthew (8/35) Mar 18 2005 Whatever you think is currently the most poorly documented, I guess.
• Matthew (30/67) May 26 2005 As it happens, Jonathon's currently reviewing the instalment for Bjorn a...

"Pablo Aguilar" <paguilarg hotmail.com> writes:

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 

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

"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

"Pablo Aguilar" <paguilarg hotmail.com> writes:

 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

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

"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 

"Pablo Aguilar" <paguilarg hotmail.com> writes:

 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

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

"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

"Matthew" <admin.hat stlsoft.dot.org> writes:

 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