• John Abney (10/10) Oct 14 2003 I really like what Matthew has done with STLSoft, especially the WinSTL
• Matthew Wilson (35/45) Oct 14 2003 That's very good to hear. :)
• John Abney (50/71) Oct 16 2003 I've been trawling like crazy up and down the registry with the WinSTL.
• Matthew Wilson (49/123) Oct 16 2003 I'm with you there. :)
• John Abney (35/57) Oct 16 2003 Maybe that's what it is! :) But to me, it just doesn't seem like it's ...
• Matthew Wilson (64/122) Oct 16 2003 the
• John Abney (34/52) Oct 17 2003 I think that even without STLSoft C++ currently offers a tremendous amou...
• Matthew Wilson (64/119) Oct 17 2003 Oh dear! Write at once, repent at leisure. I didn't realise that I'd wri...

"John Abney" <johnNOSPAMPLEASEabney yahoo.com> writes:

I really like what Matthew has done with STLSoft, especially the WinSTL
(because it's just so darn _practical_.)  Thanks for the hard work.

I've been a big fan of generic programming for a while, but I've just sort
of muddled along in learning it, mostly just picking it up over time - an
article here and there, bits of books, Modern C++ Design, but although I've
grown quite comfortable with generic programming, there was no definitive
a-ha! moment for me.  My knowledge is hard-won, but (I fear) incomplete.

Is there an article or book that serves as the Bible for generic
programming?  The market seems to be flooded with this kind of thing for
object-oriented development.  Have I missed anything?

"Matthew Wilson" <matthew stlsoft.org> writes:

 I really like what Matthew has done with STLSoft, especially the WinSTL
 (because it's just so darn _practical_.)  Thanks for the hard work.

That's very good to hear. :)

What've you been using it for? Id' love to hear.

The problem with STLSoft is either that it's so well-written (ahem) that
no-one has any issues, or it's so bad that no-one is using it. Combining the
direct (from http://stlsoft.org/) and the Digital Mars
(http://stlsoft.digiialmars.com/) downloads, it's being downloaded at more
than 1000 per month, which seems +ve, but I really have very little idea how
well it's being received.

(feel free to email me in person to chat less publicly, if you wish

 I've been a big fan of generic programming for a while, but I've just sort
 of muddled along in learning it, mostly just picking it up over time - an
 article here and there, bits of books, Modern C++ Design, but although

I've
 grown quite comfortable with generic programming, there was no definitive
 a-ha! moment for me.  My knowledge is hard-won, but (I fear) incomplete.

As is the case for us all!

 Is there an article or book that serves as the Bible for generic
 programming?  The market seems to be flooded with this kind of thing for
 object-oriented development.  Have I missed anything?

Not that I'm aware of. I actually think a single book would not cover it,
because there are different perspectives on what is "generic". Check out my
August CUJ article - http://www.cuj.com/documents/s=8681/cuj0308wilson/ -
for a genericity mechanism, shims, that works back to front (and rather well
(!) in the WinSTL libs, though you've probably not even noticed. :) ). It's
almost the reverse of traits, where characteristics are bundled, shims are
spread about.

If I can ever get through the "difficult first book" (deadline due in the
next couple of months, eek!) I do have a plan to write a book on how to
extend the STL beyond the standard library, in the very way that I've been
doing with STLSoft. (btw, once the book is out of the way, there're masses
of new things planned for STLSoft. Hopefully you'll not have lost faith with
the lack of progress by then ... )

Thanks again for your kind words.

Cheers

-- 
Matthew Wilson

STLSoft moderator and C++ monomaniac       (http://www.stlsoft.org)
Contributing editor, C/C++ Users Journal
(www.synesis.com.au/articles.html#columns)

"An Englishman by birth, a Yorkshireman by the grace of God" -- Michael
Gibbs

----------------------------------------------------------------------------
---

"John Abney" <johnNOSPAMPLEASEabney yahoo.com> writes:

 What've you been using it for? Id' love to hear.

I've been trawling like crazy up and down the registry with the WinSTL.
Being able to write code like this excites me to no end:
   reg_key_a key(HKEY_CURRENT_USER, keyName);
   reg_value_sequence_a values(key);
   for_each(values.begin(), values.end(), dump_key);

I think we've all seen the other side, and know that this is far better than
the "usual" way of doing this.  I've poked around in the code quite a bit,
and I've been very pleased with the other pieces that I've seen,
particularly the promise of XmlStl, DbStl, etc.  I love the STL, and I love
the boost libraries, so I'm happy to see the concepts of generics extended
further out to these "in the trenches" problem domains.  When I find a good
pattern, I like to see it reapplied, and see how well it works (or whether
it perhaps doesn't work.)  I feel like this has been tried pretty
extensively with object-oriented programming, and I like the idea of giving
things a try with a generic programming-oriented approach.  If this has been
tried in the past, I've certainly missed it.

 The problem with STLSoft is either that it's so well-written (ahem) that
 no-one has any issues, or it's so bad that no-one is using it. Combining

the
 direct (from http://stlsoft.org/) and the Digital Mars
 (http://stlsoft.digiialmars.com/) downloads, it's being downloaded at more
 than 1000 per month, which seems +ve, but I really have very little idea

how
 well it's being received.

Well, if it helps, I haven't run into any issues yet, outside of minor
documentation quibbles.  (For example, I noticed
basic_reg_key_sequence(reg_key_type const &key) being labelled as a copy
constructor in the doxygen-compliant comments.)  I still haven't tried most
of the libraries in practice, though, since I like to look through the code
and see how things are put together.

I think that over time you'll see usage pick up when clean, straightforward,
"Oh yeah, this is much better!" example programs become plentiful.  The *Stl
family looks to be pretty new, so I understand that example programs and
tutorials are not the focus right now.  I think that as obvious examples and
tutorials emerge over time, the value of the libraries will be more
immediately obvious.  When you see some formerly onerous task broken down
into a tiny code snippet - that makes you want to adopt a library.  The
registry traversal from above is an obvious example.

I actually happened on WinStl because I was contemplating creating something
similar.  Mostly, I just wanted see how generic programming would look when
applied to Windows.  The "WinStl" name occurred for me, and I googled for it
just to see if anything else like that was out there.  So that's how I got
here, and it's part of why I'm so interested to crack open the source and
start digging around a bit.

 Not that I'm aware of. I actually think a single book would not cover it,
 because there are different perspectives on what is "generic". Check out

my
 August CUJ article - http://www.cuj.com/documents/s=8681/cuj0308wilson/ -
 for a genericity mechanism, shims, that works back to front (and rather

well
 (!) in the WinSTL libs, though you've probably not even noticed. :) ).

It's
 almost the reverse of traits, where characteristics are bundled, shims are
 spread about.

I'm (naturally) a CUJ subscriber, so I've read your articles (nice job, by
the way.)  I haven't needed to mess with shims in my toy test programs,
since the default shims cover a lot of ground.  But having dealt with the
scads of Windows string types, I think they're quite welcome.  I chuckled
when I saw that you had included shims for my personal non-favorite string
type LSA_UNICODE_STRING.  :)

 If I can ever get through the "difficult first book" (deadline due in the
 next couple of months, eek!) I do have a plan to write a book on how to
 extend the STL beyond the standard library, in the very way that I've been
 doing with STLSoft. (btw, once the book is out of the way, there're masses
 of new things planned for STLSoft. Hopefully you'll not have lost faith

with
 the lack of progress by then ... )

Best of luck with your book - I'm looking forward to its publication.

 Thanks again for your kind words.

Any time - keep up the good work.

"Matthew Wilson" <matthew stlsoft.org> writes:

"John Abney" <johnNOSPAMPLEASEabney yahoo.com> wrote in message
news:bmn5tr$1lmj$1 digitaldaemon.com...
 What've you been using it for? Id' love to hear.

 I've been trawling like crazy up and down the registry with the WinSTL.
 Being able to write code like this excites me to no end:
    reg_key_a key(HKEY_CURRENT_USER, keyName);
    reg_value_sequence_a values(key);
    for_each(values.begin(), values.end(), dump_key);

I'm with you there. :)

 I think we've all seen the other side, and know that this is far better

than
 the "usual" way of doing this.  I've poked around in the code quite a bit,
 and I've been very pleased with the other pieces that I've seen,
 particularly the promise of XmlStl, DbStl, etc.

Indeed. I'm looking forward, post-book, to taking a month or so to getting
all the planned next parts of the libraries ready. There'll be lots added to
ATLSTL, COMSTL, UNIXSTL and WinSTL, and I'll be adding InetSTL, .netSTL,
WTLSTL and perhaps XMLSTL and DbSTL.

 I love the STL, and I love
 the boost libraries, so I'm happy to see the concepts of generics extended
 further out to these "in the trenches" problem domains.  When I find a

good
 pattern, I like to see it reapplied, and see how well it works (or whether
 it perhaps doesn't work.)  I feel like this has been tried pretty
 extensively with object-oriented programming, and I like the idea of

giving
 things a try with a generic programming-oriented approach.  If this has

been
 tried in the past, I've certainly missed it.

Yes, I'm not aware of any other significant efforts in this area. There are
a couple of narrowly focused ones, but nothing as extensive. Maybe I'm the
only one mad enough!

 The problem with STLSoft is either that it's so well-written (ahem) that
 no-one has any issues, or it's so bad that no-one is using it. Combining

 the
 direct (from http://stlsoft.org/) and the Digital Mars
 (http://stlsoft.digiialmars.com/) downloads, it's being downloaded at


more
 than 1000 per month, which seems +ve, but I really have very little idea

 how
 well it's being received.

 Well, if it helps, I haven't run into any issues yet, outside of minor
 documentation quibbles.  (For example, I noticed
 basic_reg_key_sequence(reg_key_type const &key) being labelled as a copy
 constructor in the doxygen-compliant comments.)

Well-spotted. I've now fixed that one.

  I still haven't tried most
 of the libraries in practice, though, since I like to look through the

code
 and see how things are put together.

Feel free to shoot your questions to me here, or to the FAQ
(http://stlsoft.gregpeet.com/)

 I think that over time you'll see usage pick up when clean,

straightforward,
 "Oh yeah, this is much better!" example programs become plentiful. The

*Stl
 family looks to be pretty new, so I understand that example programs and
 tutorials are not the focus right now.  I think that as obvious examples

and
 tutorials emerge over time, the value of the libraries will be more
 immediately obvious.  When you see some formerly onerous task broken down
 into a tiny code snippet - that makes you want to adopt a library.  The
 registry traversal from above is an obvious example.

Feel free to contribute some, and I'll include them in the distribution.

 I actually happened on WinStl because I was contemplating creating

something
 similar.  Mostly, I just wanted see how generic programming would look

when
 applied to Windows.  The "WinStl" name occurred for me, and I googled for

it
 just to see if anything else like that was out there.  So that's how I got
 here, and it's part of why I'm so interested to crack open the source and
 start digging around a bit.

He he. Great minds!

 Not that I'm aware of. I actually think a single book would not cover


it,
 because there are different perspectives on what is "generic". Check out

 my
 August CUJ article -


http://www.cuj.com/documents/s=8681/cuj0308wilson/ -
 for a genericity mechanism, shims, that works back to front (and rather

 well
 (!) in the WinSTL libs, though you've probably not even noticed. :) ).

 It's
 almost the reverse of traits, where characteristics are bundled, shims


are
 spread about.

 I'm (naturally) a CUJ subscriber, so I've read your articles (nice job, by
 the way.)

Thanks. Writing articles is almost as anonymous as writing free libs: i.e.
you rarely hear anything, and almost all the responses you do get are -ve.
:)

 I haven't needed to mess with shims in my toy test programs,
 since the default shims cover a lot of ground.  But having dealt with the
 scads of Windows string types, I think they're quite welcome.  I chuckled
 when I saw that you had included shims for my personal non-favorite string
 type LSA_UNICODE_STRING.  :)

Yes, it's a wart in way. Although zero-termination is a pretty cacky idiom
as well, so maybe LSA_UNICODE_STRING isn't that bad?

 If I can ever get through the "difficult first book" (deadline due in


the
 next couple of months, eek!) I do have a plan to write a book on how to
 extend the STL beyond the standard library, in the very way that I've


been
 doing with STLSoft. (btw, once the book is out of the way, there're


masses
 of new things planned for STLSoft. Hopefully you'll not have lost faith

 with
 the lack of progress by then ... )

 Best of luck with your book - I'm looking forward to its publication.

Thanks. Maybe we'll get the purchaser list into double figures!

 Thanks again for your kind words.

 Any time - keep up the good work.

Thank you. I hope you'll continue to like STLSoft, and to make demands for
new and exciting libs.

Cheers


-- 
Matthew Wilson

Director, Synesis Software                 (www.synesis.com.au)
STLSoft moderator and C++ monomaniac       (http://www.stlsoft.org)
Contributing editor, C/C++ Users Journal
(www.synesis.com.au/articles.html#columns)
-----------------------------------------------------

"John Abney" <johnNOSPAMPLEASEabney yahoo.com> writes:

 Yes, I'm not aware of any other significant efforts in this area. There

are
 a couple of narrowly focused ones, but nothing as extensive. Maybe I'm the
 only one mad enough!

Maybe that's what it is!  :)  But to me, it just doesn't seem like it's even
been properly tried.  Which, of course, makes it all that much more
interesting to just go ahead and give generics a real try on these kinds of
problems.  In some ways, libraries like the STL work so well that people may
not take the time to dig into them and seek out the patterns that make
things lock so neatly into place.

 I think that over time you'll see usage pick up when clean,

 straightforward,
 "Oh yeah, this is much better!" example programs become plentiful. The

 *Stl
 family looks to be pretty new, so I understand that example programs and
 tutorials are not the focus right now.  I think that as obvious examples

 and
 tutorials emerge over time, the value of the libraries will be more
 immediately obvious.  When you see some formerly onerous task broken


down
 into a tiny code snippet - that makes you want to adopt a library.  The
 registry traversal from above is an obvious example.

 Feel free to contribute some, and I'll include them in the distribution.

I would actually be very happy to put something together.  The one thing
that's intimidating there is how to get such a high level of cross-compiler
compatibility.  When you could run up against compilers that lack major
features such as namespaces, you've got to take some care in how you write
your code.

I'd also imagine that most people don't have access to some of the compilers
on the compatibility list.  For me, the problem compilers are Metrowerks,
the Intel compiler, and the early versions of Visual Studio.  I've heard
Metrowerks is pretty on-the-ball with their standards compliance, so that
one is probably not an issue.  Intel I know a lot less about, but Visual
Studio 5 is probably quite tricky for template-based code.

Though I'd say the high level of compatibility makes things tricky, I'm sure
it's probably well worth it - just takes a bit more work.  The Python make
script looks like it makes that testing a lot easier.

Speaking of which, what's this AceSTL project I see referenced in the .py
file?  Is this a lib based on the ACE libraries?  Or are we not supposed to
ask about that one?  :)

 Thanks. Writing articles is almost as anonymous as writing free libs: i.e.
 you rarely hear anything, and almost all the responses you do get are -ve.
 :)

Honestly, that surprises me.  I just have a hard time imagining someone
disliking an article enough to throw their CUJ across the room and dash off
an anti-shim flame email.  Or perhaps someone thought you were unfairly
dissing itoa().  :)

 Yes, it's a wart in way. Although zero-termination is a pretty cacky idiom
 as well, so maybe LSA_UNICODE_STRING isn't that bad?

That's true - null termination has terrible properties like linear-time
length determination, but I guess I've grown used to it.  LSA_UNICODE_STRING
just seems like this odd, boorish cousin that makes me write unnecessarily
funky code to do simple things.  I'm quite happy to see him get shimmed...

 Thank you. I hope you'll continue to like STLSoft, and to make demands for
 new and exciting libs.

You can definitely count on that... I'll keep the demands to a minimum, of
course.  :)

"Matthew Wilson" <matthew stlsoft.org> writes:

"John Abney" <johnNOSPAMPLEASEabney yahoo.com> wrote in message
news:bmntv6$2kup$1 digitaldaemon.com...
 Yes, I'm not aware of any other significant efforts in this area. There

 are
 a couple of narrowly focused ones, but nothing as extensive. Maybe I'm


the
 only one mad enough!

 Maybe that's what it is!  :)  But to me, it just doesn't seem like it's

even
 been properly tried.  Which, of course, makes it all that much more
 interesting to just go ahead and give generics a real try on these kinds

of
 problems.  In some ways, libraries like the STL work so well that people

may
 not take the time to dig into them and seek out the patterns that make
 things lock so neatly into place.

Could be. One of the four books I have planned is going to tackle what I've
done with the STL.

I have a huge amount of respect for the STL and Boost, but I think an
STLSoft is sorely lacking, and without it C++ will be overrun. Maybe if STL
becomes in the next 6-12 months what I want (to have time to make) it
become, then it will help _boost_ it back to the forefront of language
technology.

Of course, I have a couple of good platforms to help me make that happen
(the CUJ columns, and my omni-presence in Windows Developer Network), but
it'd be great to see some articles on STLSoft from some other people. I have
a suspicion that people think I'm some lone madman, and are skeptical
<friendly-invitation/challenge>until they see a community building, other
people writing articles</friendly-invitation/challenge>.

 I think that over time you'll see usage pick up when clean,

 straightforward,
 "Oh yeah, this is much better!" example programs become plentiful. The

 *Stl
 family looks to be pretty new, so I understand that example programs



and
 tutorials are not the focus right now.  I think that as obvious



examples
 and
 tutorials emerge over time, the value of the libraries will be more
 immediately obvious.  When you see some formerly onerous task broken


 down
 into a tiny code snippet - that makes you want to adopt a library.



The
 registry traversal from above is an obvious example.

 Feel free to contribute some, and I'll include them in the distribution.

 I would actually be very happy to put something together.  The one thing
 that's intimidating there is how to get such a high level of

cross-compiler
 compatibility.  When you could run up against compilers that lack major
 features such as namespaces, you've got to take some care in how you write
 your code.

Well, if you're talking about contributing test progs, mostly you don't have
to worry, since I've done most of the hard yards. It's also perfectly fine
to have a #if .... #error section in your test program to stipulate which
compilers your code is compatible with. (And I'd probably have a fiddle, to
make it work with them all anyway. ;)

 I'd also imagine that most people don't have access to some of the

compilers
 on the compatibility list.  For me, the problem compilers are Metrowerks,
 the Intel compiler, and the early versions of Visual Studio.  I've heard
 Metrowerks is pretty on-the-ball with their standards compliance, so that
 one is probably not an issue.  Intel I know a lot less about, but Visual
 Studio 5 is probably quite tricky for template-based code.

I imagine that's true. But as I said above, it's really my responsibility to
have the compatibility done, and I do have all the compilers we support. (Of
course :)

 Though I'd say the high level of compatibility makes things tricky, I'm

sure
 it's probably well worth it - just takes a bit more work.  The Python make
 script looks like it makes that testing a lot easier.

It does. Very tricky. I'm working on a tool to make it all simple pimple,
but it's been put on the back-burner along with everying else atm.

 Speaking of which, what's this AceSTL project I see referenced in the .py
 file?  Is this a lib based on the ACE libraries?  Or are we not supposed

to
 ask about that one?  :)

;)

 Thanks. Writing articles is almost as anonymous as writing free libs:


i.e.
 you rarely hear anything, and almost all the responses you do get


are -ve.
 :)

 Honestly, that surprises me.  I just have a hard time imagining someone
 disliking an article enough to throw their CUJ across the room and dash

off
 an anti-shim flame email.  Or perhaps someone thought you were unfairly
 dissing itoa().  :)

That's the way it goes. I guess probably only religion precipitates more
religious heat than writing about software. Oh god, wait until the book
comes out. "Imperfect C++" - can you imagine how that's going to be
received!?

 Yes, it's a wart in way. Although zero-termination is a pretty cacky


idiom
 as well, so maybe LSA_UNICODE_STRING isn't that bad?

 That's true - null termination has terrible properties like linear-time
 length determination, but I guess I've grown used to it.

LSA_UNICODE_STRING
 just seems like this odd, boorish cousin that makes me write unnecessarily
 funky code to do simple things.  I'm quite happy to see him get shimmed...

Yeah, he was asking for it!

 Thank you. I hope you'll continue to like STLSoft, and to make demands


for
 new and exciting libs.

 You can definitely count on that... I'll keep the demands to a minimum, of
 course.  :)

Cool. Although I've said I'm busy now, I really do want a lot of demands
towards the end of the year, and I'm perfectly happy now to chat about the
odd thing.

Do you want to send me your email (to my email), and I can add you onto the
mailing list (and maybe I might have one or two private ideas I'd like to
run past you from time to time)

Cheers



-- 
Matthew Wilson

STLSoft moderator and C++ monomaniac       (http://www.stlsoft.org)
Contributing editor, C/C++ Users Journal
(www.synesis.com.au/articles.html#columns)

"An Englishman by birth, a Yorkshireman by the grace of God" -- Michael
Gibbs

----------------------------------------------------------------------------
---

"John Abney" <johnNOSPAMPLEASEabney yahoo.com> writes:

 I have a huge amount of respect for the STL and Boost, but I think an
 STLSoft is sorely lacking, and without it C++ will be overrun. Maybe if

STL
 becomes in the next 6-12 months what I want (to have time to make) it
 become, then it will help _boost_ it back to the forefront of language
 technology.

I think that even without STLSoft C++ currently offers a tremendous amount
of very strong libraries, but a lot of times they're very balkanized - you
have to adopt a huge amount of infrastructure in order to get the
functionality you need, and a lot of times, these libraries just refuse to
integrate the way you want.  Think of how easy it is to "adopt" the STL -
include the header you need, grab something that can act like a
pointer\iterator and go.  You can "sort" a C-style array if you want, or
perform a binary search on a vector.  No need to swaddle objects in blankets
to conform to a pre-determined interface or drag in yet another framework.
And the generated code is _fast_!  It's the fabled nearly-free lunch.

As for C++ being overrun, I never make predictions about such things.  The
Holy Crusaders of every language from Java to Lisp have been declaring C++'s
demise for years.  :)  What do you see as the top contender for its spot?

but they don't cut the mustard on the tasks that are most important to me.
I think we're very lucky to live in an age with so many great tools
available, not the least of which is a powerhouse C++ language that has
improved dramatically over the years.

 Of course, I have a couple of good platforms to help me make that happen
 (the CUJ columns, and my omni-presence in Windows Developer Network), but
 it'd be great to see some articles on STLSoft from some other people. I

have
 a suspicion that people think I'm some lone madman, and are skeptical
 <friendly-invitation/challenge>until they see a community building, other
 people writing articles</friendly-invitation/challenge>.

Hey, if the presence of additional madpeople will help you out, no problem.
We're in no short supply in the programming community!  What kind of
articles are needed most?  Tutorials of some kind?

 That's the way it goes. I guess probably only religion precipitates more
 religious heat than writing about software. Oh god, wait until the book
 comes out. "Imperfect C++" - can you imagine how that's going to be
 received!?

Hopefully you'll be okay - consider that everyone from Koenig to Stroustrup
to Meyers to Alexandrescu have all at one time or another very clearly
acknowledged the "imperfect" nature of C++.  Any language describing itself
as "perfect" is just bound to disappoint me.  I think Koenig's "pickup
truck" description is pretty accurate.  You could say that C++ "fits like an
old shoe" to most problems I face day to day, and offers me great expressive
power.

 Do you want to send me your email (to my email), and I can add you onto

the
 mailing list (and maybe I might have one or two private ideas I'd like to
 run past you from time to time)

Yeah, I've sent you an email at the address listed in the NG header, so let
me know if you don't get it.  Feel free to run anything you'd like past me,
I hope I can be of help.

"Matthew Wilson" <matthew stlsoft.org> writes:

"John Abney" <johnNOSPAMPLEASEabney yahoo.com> wrote in message
news:bmpufi$2b16$1 digitaldaemon.com...
 I have a huge amount of respect for the STL and Boost, but I think an
 STLSoft is sorely lacking, and without it C++ will be overrun. Maybe if

 STL
 becomes in the next 6-12 months what I want (to have time to make) it
 become, then it will help _boost_ it back to the forefront of language
 technology.

 I think that even without STLSoft C++ currently offers a tremendous amount
 of very strong libraries,

Oh dear! Write at once, repent at leisure. I didn't realise that I'd written
something that sounds so toweringly arrogant. (It was late at night ...)

I did say "an" STLSoft, rather than "the" STLSoft, but still ... <blush>

 but a lot of times they're very balkanized - you
 have to adopt a huge amount of infrastructure in order to get the
 functionality you need, and a lot of times, these libraries just refuse to
 integrate the way you want.

Quite. One of the things I've put a lot of effort into is making it as
lightweight as possible. Anytime I have to use a library and there's all
kinds of configuration to be done, I just loose heart. Even with STLport: I
tend to stick with the VC++ libs for the reason that having to look up the
_STLP_NO_OWN_IOSTREAMS, or whatever the hell it is everytime I create a new
project is a pita. (On VC++ I include the correct definition in the wizards
that I use, but I've not got round to doing wizards for VS.NET yet. )

 Think of how easy it is to "adopt" the STL -
 include the header you need, grab something that can act like a
 pointer\iterator and go.  You can "sort" a C-style array if you want, or
 perform a binary search on a vector.  No need to swaddle objects in

blankets
 to conform to a pre-determined interface or drag in yet another framework.
 And the generated code is _fast_!  It's the fabled nearly-free lunch.

Indeed. I hope that STLSoft follows this, and anytime it doesn't I expect
people to shout at me until I fix the offending peice.

 As for C++ being overrun, I never make predictions about such things.  The
 Holy Crusaders of every language from Java to Lisp have been declaring

C++'s
 demise for years.  :)

True. They still are. I find it laughable, since I can't see anything doing
that. Even D, which has great promise, forces one to use GC, which may be
good for most situations, but there'll be situations in which it will not
suffice.

C++ is the only language that can do everything, even if the doing is often
less than pretty.

 What do you see as the top contender for its spot?

I wasn't really meaning that C++ will die, more that it will not be the
preferred choice for a growing majority. Universities only teach swill these
days, so we have to reeducate graduates into what the real world is like.

Consider that if you had to do a small utility for doing registry stuff.
Without the winstl::reg_key_sequence etc, you'd be far quicker knocking out

be really cool ... ;)


 but they don't cut the mustard on the tasks that are most important to me.
 I think we're very lucky to live in an age with so many great tools
 available, not the least of which is a powerhouse C++ language that has
 improved dramatically over the years.

For me, I still wouldn't dream of doing a non-trivial app in anything else,
but oftentimes I do reach for another language when I need to do something
simple (and I don't have the time to add a new STLSoft component.)

So, if we can have a fabulous standard library (STL), a fabulous
platform-/technology-independent library (Boost), and a fabulous
platform-/technology-specific library (STLSoft), then there'll be very
little need to fall back on "lesser" languages.

 Of course, I have a couple of good platforms to help me make that happen
 (the CUJ columns, and my omni-presence in Windows Developer Network),


but
 it'd be great to see some articles on STLSoft from some other people. I

 have
 a suspicion that people think I'm some lone madman, and are skeptical
 <friendly-invitation/challenge>until they see a community building,


other
 people writing articles</friendly-invitation/challenge>.

 Hey, if the presence of additional madpeople will help you out, no

problem.
 We're in no short supply in the programming community!  What kind of
 articles are needed most?  Tutorials of some kind?

Well, I know Windows Developer Network are always on the lookout for small
articles, in their Tech Tips section. A one page thing on any cool
library/utility/technique/gotcha is always welcome, so if you were to write
some of these on STLSoft I'm pretty confident they'd be well received.
(email wdletter cmp.com). Also Dr Dobb's like things that are from a
practical perspective, so if you'd used any of the stuff to do something
new, or in a new or more efficient way, then they may like that.

If you wanted to do some tutorials that I could include in the download
and/or help, that would be outstanding!! Your reward would be having your
name listed along with the other "greats" on
http://stlsoft.org/help/main.html#mainpage_acknowledgements.

 That's the way it goes. I guess probably only religion precipitates more
 religious heat than writing about software. Oh god, wait until the book
 comes out. "Imperfect C++" - can you imagine how that's going to be
 received!?

 Hopefully you'll be okay - consider that everyone from Koenig to

Stroustrup
 to Meyers to Alexandrescu have all at one time or another very clearly
 acknowledged the "imperfect" nature of C++.  Any language describing

itself
 as "perfect" is just bound to disappoint me.  I think Koenig's "pickup
 truck" description is pretty accurate.  You could say that C++ "fits like

an
 old shoe" to most problems I face day to day, and offers me great

expressive
 power.

I hope you're correct, but I know there'll be heaps of derision. You should
see what some of my reviewers have said so far. =) (Don't worry; there are
vast differences in opinions, and I've a thick skin. Two of them can't see
any purpose in the shims, which you've already grokked, so you can see that
there will be diversity of opinion.)


 Do you want to send me your email (to my email), and I can add you onto

 the
 mailing list (and maybe I might have one or two private ideas I'd like


to
 run past you from time to time)

 Yeah, I've sent you an email at the address listed in the NG header, so

let
 me know if you don't get it.  Feel free to run anything you'd like past

me,
 I hope I can be of help.

Got it. I will be replying forthwith.

:)