www.digitalmars.com         C & C++   DMDScript  

c++.stlsoft - STLSoft goes Digital Mars

reply "Matthew Wilson" <dmd synesis.com.au> writes:
Hi everyone

As of version 1.6.2 of STLSoft and 8.34 of DMC++, the STLSoft libraries will
be bundled with DMC++.

For those of you that don't know anything of STLSoft, you can read all the
blurb at http://stlsoft.org/, but I'll give you a brief intro. As the logo
states, it provides
 "Robust, Lightweight, Cross-platform, Template Software." Robust,
cross-platform, template are all pretty obvious. It's lightweight in two
respects, both of which make it a good fit with Digital Mars:

1. it is very easy to use and install. Since it is, and will remain, 100%
header-only, you simply put it in a directory and add that to the include
paths. For DMC++, it is going in dm\stlsoft, and I'm pretty sure Walter'll
be altering SC.INI so that you won't have to do a thing.
2. it is efficient. There are a number of aspects of the library where it is
proved to be more efficient to other C/C++ libraries. Notable ones in the
current version are the integer to string conversions, and the string
tokeniser.

As well as the main STLSoft project - confusingly called STLSoft itself -
there are
currently five released sub-projects, each with their own website. They are

- ATLSTL, http://atlstl.org/. Deals with ATL. Currently very small, there
are a lot of things about to be added
- COMSTL, http://comstl.org/. All things COM. It is more mature than ATLSTL,
with some very useful components - check out the simple_enum_sequence
template that provides policy-based adaptation of COM IEnumXXX enumerators
to STL-like sequences supporting Input or Forward Iterator semantics.
Nonetheless, there
are still quite a few things that will be added to it in the near future.
- MFCSTL, http://mfcstl.org/. MFC. Most of the current contents deal with
making MFC types work seamlessly in an STL. For example, there are adaptive
templates to make CArrayXxxx, CMapXxxxx and CString all come to the STL
party.
- UNIXSTL, http://unixstl.org/. Some UNIX stuff. Like, ATLSTL, this is
currently quite small, but contains some useful stuff: sequences for
file-system iteration, and performance counter types. There's nothing else
currently planned for UNIXSTL, but I'd be very happy to have
suggestions/requests.
- WinSTL, http://winstl.org/. All things Win32. This was the guy that kicked
the whole shabang off, and contains a _lot_ of stuff: file-system, controls,
performance counters, synchronisation, registry, memory. Check out
http://winstl.org/libraries.html for the full listing. Taming the Win32 API
and making it behave like STL has been at once frustrating, interesting and
rewarding. I think this will be the sub-project that you'll find most
immediately useful.


So you might be wondering what is the purpose of bundling with DMC++. There
are three primary reasons.

First, DMC++ and STLSoft have many compatible traits, especially efficiency
and configuration simplicity.

Second, it will bring DMC++ to the attention of the STLSoft users who have
not yet used Digital Mars. It being one of my favourite three compilers
(along with Intel and Metrowerks), not to mention being the one of the three
that
is freely available, I'd be very happy if this brings a new set of people
into the DM community.

Finally, it will bring STLSoft to the attention of all of you good folks. As
a member of the various Digital Mars newsgroups over the past year or two,
it
has struck me what a unique newsgroup this is. It has attracted an
impressive
array of knowledgeable people - most of whom seem to know more than me on a
scarily
large spectrum of topics - but has attracted virtually none of the
petulance,
pomposity and pointless "religious" fervour that abounds in most of the
others
I've sampled. So I know that whatever feedback I get from you all about
STLSoft
will be constructive, and can only help to improve it further.


Before I sign off I just want to mention the resources available.

1. Websites

STLSoft lives at stlsoft.org (and the sub-projects in their respective
.orgs). Check there for the latest information, in particular
http://stlsoft.org/downloads.html

There will also be a site at Digital Mars:
http://www.digitalmars.com/~synesis. At
the moment there's nothing there, but I expect that I'll be able to correct
that in the
next few days. As things develop, I'll be able to create a DMC-STLSoft
site, listing any interesting facts of STLSoft that pertain to DMC++ or to
the
DM-STLSoft newsgroup, and place the help in a sub-directory, as well as it
hosting
the online HTML help for the libraries.

2. Help/Documentation

With the bundle will come the Doxygen-ated help for all the libraries. This
comes as a set of HTML & support files, and also as a Compile Help Module
(chm).
Naturally the CHM only works on Windows, but I think that doesn't present a
problem to most DM members

Note: I *strongly* recommend to anyone who is creating libraries that they
may use a doc-tool on in the future to put the tags, not just the comments,
in as you go. I spent a _very_ boring 5 days last week!

3. Magazine articles

I've done quite a few STLSoft-related articles over the last year or so,
many
of which are not yet published, but a few are already out there; some
are available online


Developer Magazine, June 2003
- "Win32 Performance Measurement Options", Windows Developer Magazine, May
2003
- "XML Parser Usability and Performance", Windows Developer Magazine, April
2003 - PDF of magazine available for download now from
http://ww.windevnet.com
- "True-typedefs", C/C++ User's Journal, March 2003
- "Adapting Windows Enumeration Models to STL Iterator Concepts", Windows
Developer Magazine, March 2003, http://www.windevnet.com/documents/win0303a/
- "Efficient Integer To String Conversions", C/C++ User's Journal, December
2002

There are more coming out over the coming months, in both CUJ & WDM. Please
bear in mind that WDM makes
all its new, and most of its previous, articles available online. Go to
http://www.windevnet.com/search/ and search for STLSoft. You have to
register, but its free and you can tell them not to send any marketing
email, so it's pretty good.

4. Test programs

This is an area where I've been a bit less than fabulous. The test programs
that
are in the current-bundle / stlsoft.org-download _do_ exercise the
functionality
that they need to, as well as to ensure compiler support, etc., but they're
not
the best examples of my work, to say the least. I was a bit time-poor.

I'm very open to getting questions and feedback from you, not to mention
improvements, and expect that they'll ripen quickly. Also, I plan to place a
couple of non-trivial example programs on the
http://www.digitalmars.com/~synesis  site shortly. One of these is an
enhancement to Walter's very useful whereis program, that uses sequences and
functionals such that it has a surprisingly neat and succinct
implementation.

5. The C++.STLSoft newsgroup

Naturally I'm going to shoulder the responsibility of answering the posts on
the newsgroup, at least
until the STLSoft experience is widened. I'm hoping you'll all participate,
and help me
make the newsgroup, and the libraries, better than they already are.

I've got a pretty thick skin, so please don't worry about upsetting me: all
_constructive_
criticism is welcome. One aim of the DMC++-STLSoft exercise is to help take
STLSoft to
the next level. Fire at will!

6. The libraries themselves

For the moment, I'm not sure whether Walter's going to bundle with the next
beta, or wait until 8.34. My presumption is that he'll wait until 8.34 is
released. In the meantime you can download the latest distribution from
http://stlsoft.org/downloads.html. (Please note that this does _not_ contain
a
DMC++ makefile, which the bundled version does have, so you're a little bit
on your own - but then that's what the newsgroup is for, of course.)


Ok, that's it. Thanks for listening.

Cheers

Matthew Wilson, C++ monomaniac open to a bit of D-programming. ;)

admin stlsoft.org
Apr 09 2003
next sibling parent reply Garen Parham <nospam garen.net> writes:
I've given it a browse and cursory look.  Some things that I wonder right away
which could go in a FAQ or something:

* Is there any reason to use your filesystem code rather than boost's?

* WinSTL...hmm..  Looks like a more minimal version of WTL.  Seen that?

* Why do they all have STL in their name? :)
Apr 11 2003
parent reply "Matthew Wilson" <dmd synesis.com.au> writes:
 * Is there any reason to use your filesystem code rather than boost's?


That's a small part of a very large question - "Why isn't STLSoft part of
Boost?" - which Greg is trying to prise an answer out of me at the current
time.

With respect to file-system in particular, the boost file-system library was
added in 1.30, which was only released in March this year. The
WinSTL/UNIXSTL file-system components have been around for a lot longer.
That explains the chronology.

As to whether you should use boost or WinSTL/UNIXSTL file-system libraries
in particular, I guess that's to be determined from a comparison of the two.
I have not done so, but I'm more than happy to look through the results if
someone else wants to do so.


 * WinSTL...hmm..  Looks like a more minimal version of WTL.  Seen that?


I have. WinSTL is no more a replacement for WTL than STLSoft is a
replacement for STLPort. In other words, none.

WinSTL is about applying and extending STL techniques over the Win32 API(s).
WTL is a framework.

In fact, there is a plan to do a WTLSTL, though it's likely to be a while.


 * Why do they all have STL in their name? :)


:)
Apr 12 2003
parent reply Garen Parham <nospam garen.net> writes:
Matthew Wilson wrote:

...

 

 * WinSTL...hmm..  Looks like a more minimal version of WTL.  Seen that?


 
 I have. WinSTL is no more a replacement for WTL than STLSoft is a
 replacement for STLPort. In other words, none.
 
 WinSTL is about applying and extending STL techniques over the Win32 API(s).
 WTL is a framework.


Yeah I know, thought I noticed some overlap though.  I'm not very familiar 
with either as of yet, just thought I'd throw out some curiosity. :)


 
 In fact, there is a plan to do a WTLSTL, though it's likely to be a while.


I bet.  It's huge.  In my C++ fantasy mind's eye, what I'd really like is
something that looked WTLish that was cross-platform to Linux and Mac OS X.
IMO it's the biggest thing lacking from boost.

One thing that popped out at me though was your performance counter stuff.
I could use that sometime.  I don't think I've seen anything like that
available in a template library anywhere else.

Thanks.
Apr 12 2003
next sibling parent "Matthew Wilson" <matthew stlsoft.org> writes:
"Garen Parham" <nospam garen.net> wrote in message
news:b7as4v$13ii$1 digitaldaemon.com...

 Matthew Wilson wrote:

 ...

 * WinSTL...hmm..  Looks like a more minimal version of WTL.  Seen that?


 I have. WinSTL is no more a replacement for WTL than STLSoft is a
 replacement for STLPort. In other words, none.

 WinSTL is about applying and extending STL techniques over the Win32




API(s).

 WTL is a framework.


 Yeah I know, thought I noticed some overlap though.  I'm not very familiar
 with either as of yet, just thought I'd throw out some curiosity. :)


I'll have to take your word for it, as I've not devled into Boost for some
months, apart from to performance test their tokeniser against the STLSoft
one (STLSoft won - 2.5 times quicker at tokenising with either single
character or string delimiters) for my article in June's WDM. The first look
I had at their file-system stuff was the other day in response to your post.


 In fact, there is a plan to do a WTLSTL, though it's likely to be a




while.

 I bet.  It's huge.  In my C++ fantasy mind's eye, what I'd really like is
 something that looked WTLish that was cross-platform to Linux and Mac OS


X.

 IMO it's the biggest thing lacking from boost.

 One thing that popped out at me though was your performance counter stuff.
 I could use that sometime.  I don't think I've seen anything like that
 available in a template library anywhere else.


I'm glad you like it. I've found it very useful, especially since I've been
doing so many performance related articles in the last year or so. :)

If you hadn't noticed, there's a UNIXSTL performance_counter with the exact
same syntax and semantics as the WinSTL one. Naturally, a simple bit of
#ifdef allows one to select the appropriate one for UNIX vs Win32
compilations.

If you want to read the full jazz on the performance counters, I've the lead
article in May's WDM - online now at http://wd-mag.com/ - which describes
all six counter classes and the init/scope classes as well. You can download
the whole mag in PDF form (although it's about 5MB)



 Thanks.


Pleasure. Thanks for the interest.
Apr 12 2003
prev sibling parent "Matthew Wilson" <matthew stlsoft.org> writes:
 One thing that popped out at me though was your performance counter stuff.
 I could use that sometime.  I don't think I've seen anything like that
 available in a template library anywhere else.



programmers who may be interested, there are an equivalent set of
performance counter classes in the SynSoft D and .NET libraries. See
http://synsoft.org/d.html and http://synsoft.org/dotnet.html.



--
Matthew Wilson

STLSoft moderator and C++ monomaniac

mailto:matthew stlsoft.org
http://www.stlsoft.org
news://news.digitalmars.com/c++.stlsoft

"So far, C++ is the best language I've discovered to say what I want to
say" -- Alex Stepanov

----------------------------------------------------------------------------
---
Apr 12 2003
prev sibling parent reply "Włodzimierz Skiba" <abx abx.art.pl> writes:
"Matthew Wilson" <dmd synesis.com.au> wrote in
news:b72ero$1kbc$1 digitaldaemon.com: 

 Hi everyone


Hi


 As of version 1.6.2 of STLSoft and 8.34 of DMC++, the STLSoft
 libraries will be bundled with DMC++.


How it will be available for owners of previous CD versions ?
Will this be available in usual CD upgrade or separated common download for 
all (free and payed) DMC users ?


 1. it is very easy to use and install. Since it is, and will remain,
 100% header-only, you simply put it in a directory and add that to the
 include paths. For DMC++, it is going in dm\stlsoft, and I'm pretty
 sure Walter'll be altering SC.INI so that you won't have to do a
 thing. 2. it is efficient. There are a number of aspects of the
 library where it is proved to be more efficient to other C/C++
 libraries. Notable ones in the current version are the integer to
 string conversions, and the string tokeniser.


Are there any benefits for application where doubles are strongly used 
(including conversion from string). Is there any ?


 As things develop, I'll be able to create a DMC-STLSoft
 site, listing any interesting facts of STLSoft that pertain to DMC++
 or to the
 DM-STLSoft newsgroup, and place the help in a sub-directory, as well
 as it hosting
 the online HTML help for the libraries.


Looking at http://www.synesis.com.au/winstl/compiler_compatibility.html
I noticed some 'x' in DMC section. Solvable in the future ?

Thanks for your work.

ABX
Apr 11 2003
next sibling parent reply "Gregory Peet" <admin gregpeet.com> writes:
"Włodzimierz Skiba" <abx abx.art.pl> wrote in message
news:b75sin$q89$1 digitaldaemon.com...


 How it will be available for owners of previous CD versions ?
 Will this be available in usual CD upgrade or separated common download


for

 all (free and payed) DMC users ?


The newest version of the STL projects will always be available from their
appropriate website.
As far as being available with CD-related upgrades and users, I am not the
author or representative for DM so I do not know.
If you have any problems with incorporating STLsoft with DMC, then please
post any problems here.


 Are there any benefits for application where doubles are strongly used
 (including conversion from string). Is there any ?


From my experience, it always depends on what you wish to do. You do not
have to use all the functionality within
the STLprojects. 8 Bytes is not a terribly large size for a "strongly used"
type in these current times where RAM is cheap
and value overrun is common ;)


 Looking at http://www.synesis.com.au/winstl/compiler_compatibility.html
 I noticed some 'x' in DMC section. Solvable in the future ?


Remember that the author is a one-man workhouse for the projects ;(
If you are comfortable with modification of code, then you are welcome to
contribute any fixes or workarounds ;)

--
-Gregory Peet

Newsgroup FAQ:
http://stlsoft.gregpeet.com

Golden Rule of Open-Source Programming:
"Don't whine about something unless you are going to implement it yourself."
Apr 11 2003
parent "Matthew Wilson" <dmd synesis.com.au> writes:
 The newest version of the STL projects will always be available from their
 appropriate website.


Correct


 As far as being available with CD-related upgrades and users, I am not the
 author or representative for DM so I do not know.


I'm currently sorting this out, but I can't see any reason preventing
 - the most recent versions available immediately on the STLSoft website(s)
 - the latest version being included with DMC++ versions (and maybe betas)


 If you have any problems with incorporating STLsoft with DMC, then please
 post any problems here.


Indeed. I don't think there should be many, subject to the compiler
compatiblities found at http://stlsoft.org/compiler_compatiblity.html,
http://atlstl.org/compiler_compatiblity.html,
http://comstl.org/compiler_compatiblity.html,
http://mfcstl.org/compiler_compatiblity.html,
http://winstl.org/compiler_compatiblity.html,
http://unixstl.org/compiler_compatiblity.html.

DMC++ is supporting more and more of the libraries, and I think there'll be
very few not supported after the 8.34 release


 From my experience, it always depends on what you wish to do. You do not
 have to use all the functionality within
 the STLprojects.


This is a good general point. The STLSoft projects do *not* represent a
framework that must be adopted wholesale. Subject to the very small number
of root headers - usually stlsoft.h and stlsoft_cccap_dmc.h for DMC++
compilations - you can pick and mix as you see fit.

This selectiveness is one of the motivations of STLSoft. I personally hate
having to bring in a whole load of stuff I don't need/want just to get some
stuff I do - e.g. ATL's _Module.


 Remember that the author is a one-man workhouse for the projects ;(


Not sure if that's a compliment, or what? :)


 If you are comfortable with modification of code, then you are welcome to
 contribute any fixes or workarounds ;)


I am very keen to have people contribute. However, contributions must follow
the ethos of STLSoft, including:

 * 100% header only. There are no exceptions to this. However, before people
bombard me with reasons for it, take a look at the implementation of, say,
winstl::performance_counter, to see just how far one can get with simulating
static members via functions. Greg and I have talked about starting a
SourceForge project STLSoftX - eXtension - which would allow some things -
simpler and more powerful type conversions, broader support for
process/thread synchronisation, etc. etc. - by sacrificing some portability
and having implementation files. If this project did take shape, there is no
reason whatsoever that we couldn't target DMC++, and thereby provide a
richer library suite for the compiler. But we're getting ahead of ourselves:
there's plenty in the current STLSoft libraries for people to digest and
make use of, and I have a significant number of modifications sitting in my
todo list which I hope to attend to in 4-6 weeks time.
 * wide variety of compiler/library/memory-environment/etc. compatiblity.
    1. I'm against compiler-extensions because they reduce portability, not
because they are "impure". I avoid them, unless backup mechanisms are
provided in the libraries as well. For example, COMSTL's interface_cast<>
components use the __declspec(uuid) if it's available, but there is a backup
mechanism for compilers that do not support that extension. Another good
examples is in "move constructors" - see
http://synesis.com.au/resources/articles/cpp/movectors.pdf - and in fact
DMC++ is the only compiler that _does_ support them.
    2. I'm against being dependent on a particular version of the STL, or
even on STL at all. In many parts of the library you can get by without any
STL. However, for bits that need it, I make sure that there's a broad
compatibility with different implementations. (And anyone who thinks this is
trivial, check out the contents of stlsoft_iterator.h - major brain ache,
most of it caused by VC 4, 5, 6 & 7's libraries)
 * very efficient. I'm attracted by complexity and elegance and all that
stuff just as much as the next man, but there are so many parts of C++ that
are so slow. C++ is a blindingly fast language, it's just often let down by
libraries. STLSoft libraries aim to be efficient, sometimes at the cost of
flexibility. Look at the multidimensional fixed_array/frame_array classes.
They contain at() and at_unchecked() so that you can code to a model that
will check your index(es), or to one that assumes that you only pass correct
indexes; this is in stark contrast to, say, std::vector, which enforces that
[] does not do checking and at() does.
 * simplicity. As a rule, people don't want to use things they cannot
understand. Hence, I try to be as simple as possible to get the job done.
Before anyone goes rooting through the code to prove me wrong, I'll concede
right now that there are some scarily complex parts (such that I have to do
a few double-takes before I remember how they work), e.g. string_tokeniser,
but they're only done where it is necessary to achieve efficiency and ease
of use. Wherever I can, I try and make it simple. I'm not a fan of
template-meta programming, and use it sparingly; one good reason for this is
that TMP is the stuff most likely to upset compilers and reduce portability,
which I see as not worth it.
 * minimisation of implicit conversions. I don't like implicit conversion
operators, nor implicit conversions through constructors, and to do both
together in the same class is positively criminal. Programmers are better
served by having to type a few more characters and know what the compiler is
generating for them, than being able to pass a string-class-instance to a
C-API without any kind of conversion. Of course, I employ a technique I've
invented - at least I'm not aware of any other work on it - of
Generalisation via Explicit Conversion, of which I'd like to say a whole lot
more than is said in http://synesis.com.au/resources/articles/cpp/shims.pdf,
but can't until CUJ publish my article on the subject in August's issue.
 * minimisation of OO notions. Inheritance is a dodo of an idea for most
programming tasks (though there are some for which it is suitable, of
course). But am largely, though not completely, a subscriber to Alex
Stepanov who says in http://www.stlport.org/resources/StepanovUSA.html: "I
find OOP technically unsound. It attempts to decompose the world in terms of
interfaces that vary on a single type. To deal with the real problems you
need multisorted algebras - families of interfaces that span multiple types.
I find OOP philosophically unsound. It claims that everything is an object.
Even if it is true it is not very interesting - saying that everything is an
object is saying nothing at all. I find OOP methodologically wrong. It
starts with classes. It is as if mathematicians would start with axioms. You
do not start with axioms - you start with proofs. Only when you have found a
bunch of related proofs, can you come up with axioms. You end with axioms.
The same thing is true in programming: you have to start with interesting
algorithms. Only when you understand them well, can you come up with an
interface that will let them work." (If you think that's bad, you should
read what he says about Java - which I also agree with)


 Golden Rule of Open-Source Programming:
 "Don't whine about something unless you are going to implement it


yourself."

Like it. :)



Well, it's too late, and I've spent too much time ranting on.

Come one, come all. If you like it, that's great. If you hate it, let's make
it better.
Apr 12 2003
prev sibling parent reply "Matthew Wilson" <dmd synesis.com.au> writes:
 How it will be available for owners of previous CD versions ?


Despite Walter's insistence over the last few months that I shouldn't
bother, I've maintained as much support as possible for backwards
compatibility back to 8.26. The compatibility tables on the various
projects' sites should help you find out what components are available for
which DMC++ versions.


 Will this be available in usual CD upgrade or separated common download


for

 all (free and payed) DMC users ?


The five sub-projects' latest versions are always available from their
respective web-sites, as well as all being available from the main site's
downloads page - http://stlsoft.org/downloads.html.

Naturally there will be times that STLSoft will be updated between DMC++
updates, and vice versa.

I will ensure that any changes to STLSoft are always available for the
version updates and the betas, but anyone can download the latest direct any
time they like.

As I've mentioned above, I like to ensure as much backwards compatiblity -
with all the supported compilers, not just DMC++ - as possible, so if you
choose to do intermediate downloads you should be pretty safe from any
breakage.


 Are there any benefits for application where doubles are strongly used
 (including conversion from string). Is there any ?


Alas, the technique that allows the integer to string conversion to be so
fast can't be applied to floating-points, so there's very little chance to
cater for them. You're probably better off sticking to sprintf() for fp to
string conversion.


 Looking at http://www.synesis.com.au/winstl/compiler_compatibility.html
 I noticed some 'x' in DMC section. Solvable in the future ?


The only problems with DMC and WinSTL is the fact that the namespaces cannot
be properly supported for DMC++ versions prior to 8.34. For DMC++, the
constructs are all declared within the global namespace. All the components
still work, it's just that they are not within the winstl namespace
(actually stlsoft::winstl_project - winstl is an alias).

To write code that will work correctly in the context of
compilers/compiler-versions that do and do not support the namespaces, you
can do either of the following

1. using declarations

Instead of

  #include <winstl_findfile_sequence.h>

  using winstl::findfile_sequence;

you can write

  #include <winstl_findfile_sequence.h>

  winstl_ns_using(findfile_sequence)

The macro winstl_ns_using(x) resolves to the "using winstl::x;" form in
compilers for which winstl is used, and to nothing for those that do not.

2. explicit qualification

Instead of

  int main()
  {
    winstl::findfile_sequence<char>    entries("*.h");
  }

you can write

  int main()
  {
    winstl_ns_qual(findfile_sequence)<char>    entries("*.h");
  }

The macro winstl_ns_qual(x) resolves to "winstl::x" compilers for which
winstl is used, and to "::x" nothing for those that do not.

[Greg, is that good enough for you?]


 Thanks for your work.


You're most welcome. I hope that you can find the libraries useful, and that
you can help with bug reports and feature requests.
Apr 12 2003
parent "Gregory Peet" <admin gregpeet.com> writes:
"Matthew Wilson" <dmd synesis.com.au> wrote in message
news:b790u0$314v$1 digitaldaemon.com...

 [Greg, is that good enough for you?]


*Sniff* Hmm, yes it seems I do smell a FAQ entry. This also brings up
something I did not consider, lexical parsing of code for nice formatting
via html. And oh how I love to pars =)
Apr 12 2003