www.digitalmars.com         C & C++   DMDScript  

c++.stlsoft - Generic Programming Must-Reads?

reply "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?
Oct 14 2003
parent reply "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 ---------------------------------------------------------------------------- ---
Oct 14 2003
parent reply "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.
Oct 16 2003
parent reply "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) -----------------------------------------------------
Oct 16 2003
parent reply "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. :)
Oct 16 2003
parent reply "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 ---------------------------------------------------------------------------- ---
Oct 16 2003
parent reply "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.
Oct 17 2003
parent "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. :)
Oct 17 2003