www.digitalmars.com         C & C++   DMDScript  

c++.stlsoft - hello all

reply "lattice" <zhangwusheng sina.com> writes:
I am a fan of STL and a new user to STLSoft.
Aug 11 2003
next sibling parent reply "Greg Peet" <admin gregpeet.com> writes:
"lattice" <zhangwusheng sina.com> wrote in message
news:bh9qtg$2uj4$1 digitaldaemon.com...
| I am a fan of STL and a new user to STLSoft.

Hello there!

Yes I agree! The Standard Template Library is awesome. When I first learned
the use of templates I was shocked that I did not have to write countless
overloaded functions. Quite nice isn't it?

There are numerous sites you should know about for your STLSoft escapades.

The Faq site: http://stlsoft.gregpeet.com (Oops is this first? =P)
The Main site: http://www.stlsoft.org
The Digital Mars site: http://www.digitalmars.com/~stlsoft

Please feel free to post comments, questions, requests to this newsgroup (or
privately, if you wish, to me and Matt via the Faq site's contact page).

Happy hacking and hope to see you posting =)
-- 

Regards,
Gregory Peet

Fellow Digital Martian
STLSoft FAQ: http://stlsoft.gregpeet.com
Aug 12 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
 Yes I agree! The Standard Template Library is awesome. When I first

 the use of templates I was shocked that I did not have to write countless
 overloaded functions. Quite nice isn't it?

I first thought it was awful. Those were the days when I thought OO and inheritance were profound things, so ...
 There are numerous sites you should know about for your STLSoft escapades.

 The Faq site: http://stlsoft.gregpeet.com (Oops is this first? =P)
 The Main site: http://www.stlsoft.org
 The Digital Mars site: http://www.digitalmars.com/~stlsoft

I like it how you've put the gregpeet.com address up first. Power to your ego!
 Please feel free to post comments, questions, requests to this newsgroup

 privately, if you wish, to me and Matt via the Faq site's contact page).

I'd *much* prefer comments to be on the newsgroup, than sent in private. I'm not troubled by bug reports - in fact I encourage them - and as yet have received no criticisms in any forum, so am not worried about that either. Post away! -- -- Matthew Wilson STLSoft moderator and C++ monomaniac mailto:matthew stlsoft.org http://www.stlsoft.org news://news.digitalmars.com/c++.stlsoft "I can't sleep nights till I found out who hurled what ball through what apparatus" -- Dr Niles Crane
Aug 12 2003
next sibling parent "Greg Peet" <admin gregpeet.com> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bha51n$913$1 digitaldaemon.com...
| I like it how you've put the gregpeet.com address up first. Power to your
| ego!

I'm not sure what you're talking about =P
Aug 12 2003
prev sibling parent reply Jan Knepper <jan smartsoft.us> writes:
 I first thought it was awful. Those were the days when I thought OO and
 inheritance were profound things, so ...

Actually... I *still* think OO is great. STL only uses half the power of C++. If the original design was done a little better they could have done it in such a way that STL could be used two fold: 1. Derived from an empy base class which would be optimized out with the compiler and STL would be STL as is. 2. Derived from a common (replaceable) base class and STL could have been STL, but with OO and all the OO power of C++. Something like: class empty_iterator { }; class empty_collection { public : typedef empty_iterator iterator_base; }; class common_iterator { public : virtual ... }; class common_collection { public : typedef common_iterator iterator_base; public : virtual common_iterator begin (); virtual common_iterator end (); }; template < class X, class Base = empty_collection > vector : public Base { public : template < class X, class IBase > _iterator : public IBase { // } typedef _Iterator < X, Base :: iterator_base > iterator; public : // Would be virtual when vector < Type, common_collection > is used. // Would NOT be virtual per default: vector < Type, empty_collection> iterator begin (); iterator end (); // etc... }; Of course this would require the iterator interface to be standardized so that there always is a 'first' and 'second' member which in case of a vector, set, etc could both point to the key and key is data... Better, we would be able to 'replace' the base of any STL template collection when a custom class would be derived from common_collection as: class MyCollection : public common_collection { }; class MyVector : public vector < int, MyCollection > { }; Now my personal opinion is that this TRUELY would have been great. Jan -- ManiaC++ Jan Knepper
Aug 12 2003
next sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
"Jan Knepper" <jan smartsoft.us> wrote in message
news:3F39093B.5D8A84CD smartsoft.us...
 I first thought it was awful. Those were the days when I thought OO and
 inheritance were profound things, so ...

Actually... I *still* think OO is great.

I guess I do, in a way. I was probably just being sly for a good quote. <blush>
 STL only uses half the power of C++. If the original design was done a

 better they could have done it in such a way that STL could be used two

 1.    Derived from an empy base class which would be optimized out with

 compiler and STL would be STL as is.
 2.    Derived from a common (replaceable) base class and STL could have

 STL, but with OO and all the OO power of C++.

. . . <snip> Nice. Actually, I'll be sending you some docs soon demonstrating a very similar technique, albeit for a quite different class. Now you've got me thinking ... maybe we'll see some more (borrowed) flesh on the concept in the next revision, correctly attributed of course. ;) btw, isn't this a potentially rather spiffy thought to carry into the DTL. Yours impressedly Peter the Plagiarist -- Matthew Wilson STLSoft moderator and C++ monomaniac mailto:matthew stlsoft.org http://www.stlsoft.org news://news.digitalmars.com/c++.stlsoft "If i'm curt with you it's because time is a factor. I think fast, I talk fast, and I need you guys to act fast" -- Mr Wolf ---------------------------------------------------------------------------- ---
Aug 12 2003
parent reply Jan Knepper <jan smartsoft.us> writes:
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Matthew Wilson wrote:

 "Jan Knepper" <jan smartsoft.us> wrote in message
 news:3F39093B.5D8A84CD smartsoft.us...
 I first thought it was awful. Those were the days when I thought OO and
 inheritance were profound things, so ...

Actually... I *still* think OO is great.

I guess I do, in a way. I was probably just being sly for a good quote. <blush>

<g> Don't worry about it...
 STL only uses half the power of C++. If the original design was done a

 better they could have done it in such a way that STL could be used two

 1.    Derived from an empy base class which would be optimized out with

 compiler and STL would be STL as is.
 2.    Derived from a common (replaceable) base class and STL could have

 STL, but with OO and all the OO power of C++.

. . . <snip> Nice.

Thanks! It is an <brag> original idea </brag>, but I heard later that someone else (might have been Scott Meyers) wrote something alike about it.
 Actually, I'll be sending you some docs soon demonstrating a very similar
 technique, albeit for a quite different class. Now you've got me thinking
 ... maybe we'll see some more (borrowed) flesh on the concept in the next
 revision, correctly attributed of course. ;)

I just smacked the example out rather quickly. The syntax might have been a bit off. Because *some* people are so much into templates and STL and forget that the real power of C++ started with OO I got so upset a while ago that I started http://www.vstl.org/ ;-) I made a start patching a SGI version of STL to actually create VSTL, but I am kinda short in time and money at the moment...
 btw, isn't this a potentially rather spiffy thought to carry into the DTL.

Now, that would be a GREAT idea. Let's not make the same mistake twice, but honer design patterns... ;-) Well, that last one because I am upset with the ANSI committee for prototyping swprintf as snwprintf. They didn't want to make the same mistake twice either, but I think declined the fact that there is tons of code out there that works with swprintf WITHOUT the string length parameters. Besides, they had a nice pattern going as: printf -> wprintf sprintf -> swprintf snprintf -> snwprintf vsprintf -> vswprintf vsnprintf -> vsnwprintf Which is now broke... <sigh>
 Yours impressedly

Now now... ;-)
 Peter the Plagiarist

Who does not? -- ManiaC++ Jan Knepper
Aug 12 2003
next sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
 It is an <brag> original idea </brag>,

Being such a software solipsist, I can assure you my idea was original as well. <g> Alas, so many people having the same ideas. sigh ...
 I just smacked the example out rather quickly. The syntax might have been

 Because *some* people are so much into templates and STL and forget that

started http://www.vstl.org/ ;-) Curse those types. I can't stand people like that ... Actually, I do kind of agree with your sentiments. It is certainly something worth pursuining at some point in the future.
 I made a start patching a SGI version of STL to actually create VSTL, but

Am absolutely with you there, my penurious brother. When oh when will it start to rain again ...
 Now, that would be a GREAT idea. Let's not make the same mistake twice,

Sounds cool. I've a massive list of stuff to go into STLSoft 1.7.1, but it's going to be awhile. There are a couple of container ideas, and maybe we can chat about them before it goes in, and perhaps enable some VSTL stuff? (Current timeline: 4 chapters to you guys tomorrow; CUJ column by the 18th; STLSoft 1.6.5 next week; more chapters for book for foreseeable future; never-ending writing commitments having me superglued into my chair and not seeing the world or going for nice bike rides; ... ; STLSoft 1.7.1; ...; Borland, Intel, Metrowerks, Microsoft, Sun form a consortium to invest in STLSoft and make me very rich; ... wake up from delusions to find I'm back at the beginning of the book; ...; remainder of my days blurbling around a padded room;) To be serious, have you checked out my Veneers concept (http://synesis.com.au/resources/articles/cpp/veneers.pdf), as this has some related stipulations about in what ways (non-polymorphic, i.e. non-vtable) inheritance can be done?
 Well, that last one because I am upset with the ANSI committee for

twice either, but I think declined the fact that there is tons of code out there that works with swprintf WITHOUT the string length parameters. Besides, they had a nice pattern going as:
 printf -> wprintf
 sprintf -> swprintf
 snprintf -> snwprintf
 vsprintf -> vswprintf
 vsnprintf -> vsnwprintf
 Which is now broke... <sigh>

Agreed.
Aug 12 2003
parent Jan Knepper <jan smartsoft.us> writes:
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

 It is an <brag> original idea </brag>,

Being such a software solipsist, I can assure you my idea was original as well. <g> Alas, so many people having the same ideas. sigh ...
 I just smacked the example out rather quickly. The syntax might have been

 Because *some* people are so much into templates and STL and forget that

started http://www.vstl.org/ ;-) Curse those types. I can't stand people like that ...

Thanks!
 Actually, I do kind of agree with your sentiments. It is certainly something
 worth pursuining at some point in the future.

Cool!
 I made a start patching a SGI version of STL to actually create VSTL, but

Am absolutely with you there, my penurious brother. When oh when will it start to rain again ...

Oh, it rains here and than it gets warm... and sticky...
 Now, that would be a GREAT idea. Let's not make the same mistake twice,

Sounds cool. I've a massive list of stuff to go into STLSoft 1.7.1, but it's going to be awhile. There are a couple of container ideas, and maybe we can chat about them before it goes in, and perhaps enable some VSTL stuff? (Current timeline: 4 chapters to you guys tomorrow; CUJ column by the 18th; STLSoft 1.6.5 next week; more chapters for book for foreseeable future; never-ending writing commitments having me superglued into my chair and not seeing the world or going for nice bike rides; ... ; STLSoft 1.7.1; ...; Borland, Intel, Metrowerks, Microsoft, Sun form a consortium to invest in STLSoft and make me very rich; ... wake up from delusions to find I'm back at the beginning of the book; ...; remainder of my days blurbling around a padded room;)

;-)
 To be serious, have you checked out my Veneers concept
 (http://synesis.com.au/resources/articles/cpp/veneers.pdf), as this has some
 related stipulations about in what ways (non-polymorphic, i.e. non-vtable)
 inheritance can be done?

Actually, I had not looked at it before, but I have used constructions like (not exactly like) this in the past one was for more or less the same reason as you explained to make MFC controls 'cool' or 'hover over' sensitive without deriving separately from each control. Instead I had a template like: tempate < class Ctrl > CoolCtrl : public Ctrl { // etc... }; Than... typedef CoolCtrl < CEdit > CoolEditCtrl; typedef CoolCtrl < CDateTimeCtrl > CoolDateTimeCtrl; etc.. Since I am writing some C++ code for the Symbian ( http://www.symbian.com/ http://www.nokia.com/ ) operating system at this moment and had to implement the same extension functionality for two different classes at some point derived from the same base class I used the same type of construction again... Just a template to extend each of the classes and typedef'ed them... ;-)
 Well, that last one because I am upset with the ANSI committee for

twice either, but I think declined the fact that there is tons of code out there that works with swprintf WITHOUT the string length parameters. Besides, they had a nice pattern going as:
 printf -> wprintf
 sprintf -> swprintf
 snprintf -> snwprintf
 vsprintf -> vswprintf
 vsnprintf -> vsnwprintf
 Which is now broke... <sigh>

Agreed.

Thanks! -- ManiaC++ Jan Knepper
Aug 12 2003
prev sibling parent Luc Hermitte <hermitte free.fr.invalid> writes:
Hello,

Jan Knepper <jan smartsoft.us> wrote in
news:3F396AF3.74D1297A smartsoft.us: 

 STL only uses half the power of C++. If the original design was
 done a little better they could have done it in such a way that STL
 could be used two fold: 
 1.    Derived from an empy base class which would be optimized out 
 with the compiler and STL would be STL as is. 
 2.    Derived from a common (replaceable) base class and STL
 could have been STL, but with OO and all the OO power of C++.


else (might have been Scott Meyers) wrote something alike about it.

This technique definitivelly looks like one of the subsets (/side effect) of "Mixin layers". Several papers and a Phd. Thesis are available (online) on this topic. -- Luc Hermitte
Dec 12 2003
prev sibling parent "John Abney" <johnNOSPAMPLEASEabney yahoo.com> writes:
 Actually... I *still* think OO is great.

 STL only uses half the power of C++. If the original design was done a

 better they could have done it in such a way that STL could be used two

 1.    Derived from an empy base class which would be optimized out with

 compiler and STL would be STL as is.
 2.    Derived from a common (replaceable) base class and STL could have

 STL, but with OO and all the OO power of C++.

since it's old school STL. With option 2, I'd be able to use iterators in non-template code, something like this: void MyFunc(const common_iterator & begin, const common_iterator & end) { // Do stuff } I'm also assuming that common_iterator would actually be a template since you'd need to get a particular type from operator*(). common_iterator<int> doesn't seem like it'd be the same as common_iterator<string>. If so, that means template template parameters might come in handy in vector's definition (to avoid specifying the type of the container twice.) Unfortunately, you can't always count on having those - a big constraint for the original STL's designers. One advantage of your scheme is that it would allow people to more safely inherit from STL containers. (I typically just use them as plain old members, myself.) By default, they don't have virtual destructors, so inheriting from them is a bit on the dicey side. VSTL would allow the user to inject a virtual destructor into the hierarchy and eliminate that problem. It's sometimes a real pain to provide operator->(), so it could be a tough call whether or not to put operator->() in common_iterator... I'd assume the empty base class optimization is fairly pervasive now, but could it have been somewhat rare in the days when STL was first being designed? That might have made VSTL less practical for the earlier implementations of STL back in the olden days. Let me know if I've missed the boat on this - I think I've probably only touched on 10% of the value of such a feature.
Oct 16 2003
prev sibling parent "Matthew Wilson" <matthew stlsoft.org> writes:
Welcome.

Feel free to post your STLSoft comments, bug reports (not that there'll be
many of them ...) and requests here.

Cheers


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

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


"lattice" <zhangwusheng sina.com> wrote in message
news:bh9qtg$2uj4$1 digitaldaemon.com...
 I am a fan of STL and a new user to STLSoft.

Aug 12 2003