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?

> 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

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

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

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

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

"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

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

> 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? I've got lots of tools that I like and enjoy using, such as Python and C#, 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.

"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 your tool in C# or in D (btw, the new D.win32.registry module's supposed to be really cool ... ;)

> I've got lots of tools that I like and enjoy using, such as Python and C#, 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.

:)