Hello, I am looking for a good cross platform C++ 'base class' library for 
things such as strings, containers, and utility functions that are typically 
found in MFC, Qt, etc.  It doesn't need to support GUI.  This is for a C++ 
middleware project.

I realize the default choice is STL, available with standard C++.  But I 
really hate that, as well as the TR9 and upcoming C++0x standards.  I am 
looking for a simpler and more sane alternative similar to the classes found 
in MFC or Qt (but that don't require a licensing or are necessarily part of 
a GUI framework).

Thanks for any suggestions,
David 

Well, "simpler" and "more sane" usually says "something that has so many limitations that
it probably isn't usable, takes months to develop, is never quite debugged, and doesn't
solve the real problems"

Use STL.  It's worth the time to learn it.
					joe

On Wed, 17 Dec 2008 18:57:28 -0800, "David Ching" <dc@remove-this.dcsoft.com> wrote:

>Hello, I am looking for a good cross platform C++ 'base class' library for 
>things such as strings, containers, and utility functions that are typically 
>found in MFC, Qt, etc.  It doesn't need to support GUI.  This is for a C++ 
>middleware project.
>
>I realize the default choice is STL, available with standard C++.  But I 
>really hate that, as well as the TR9 and upcoming C++0x standards.  I am 
>looking for a simpler and more sane alternative similar to the classes found 
>in MFC or Qt (but that don't require a licensing or are necessarily part of 
>a GUI framework).
>
>Thanks for any suggestions,
>David 
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message 
news:8jkjk49hs7l182hjfusdukafukrjjh8725@4ax.com...
> Well, "simpler" and "more sane" usually says "something that has so many 
> limitations that
> it probably isn't usable, takes months to develop, is never quite 
> debugged, and doesn't
> solve the real problems"
>
> Use STL.  It's worth the time to learn it.

Sorry, it's against my religion.  If .NET can produce a great BCL, the C++ 
people should learn from it.

-- David

"David Ching" <dc@remove-this.dcsoft.com> wrote in message 
news:FA8A0FDA-CC0F-438B-B896-8A696CDBB658@microsoft.com...
> Hello, I am looking for a good cross platform C++ 'base class' library for 
> things such as strings, containers, and utility functions that are 
> typically found in MFC, Qt, etc.  It doesn't need to support GUI.  This is 
> for a C++ middleware project.
>
> I realize the default choice is STL, available with standard C++.  But I 
> really hate that, as well as the TR9 and upcoming C++0x standards.  I am 
> looking for a simpler and more sane alternative similar to the classes 
> found in MFC or Qt (but that don't require a licensing or are necessarily 
> part of a GUI framework).

I don't know if it's stealing, but why not just clip out those things from 
MFC that you like and try to create a scenario such that it compiles and 
runs without all the other junk. Things like CString and CList can be pretty 
much be clipped-out compiled their own; ie. you don't need any of the 
windows wrapper stuff to use the containers (lists, strings, maps) and it's 
all very efficient and well-tested code.

But like I say, not sure if that's allowed. Maybe you have to ask permission 
from Msoft or something? I mean permission to base a library on *just a 
subsection of MFC*. You're allowed to *use* MFC so I don't see why it would 
be illegal "in theory", as long as you're not selling or publishing it.

But ... dunno. I'm not a lawyer.

- Alan Carre

David Ching wrote:
> Hello, I am looking for a good cross platform C++ 'base class' library 
> for things such as strings, containers, and utility functions that are 
> typically found in MFC, Qt, etc.  It doesn't need to support GUI.  This 
> is for a C++ middleware project.
> 
> I realize the default choice is STL, available with standard C++.  But I 
> really hate that, as well as the TR9 and upcoming C++0x standards.  I am 
> looking for a simpler and more sane alternative similar to the classes 
> found in MFC or Qt (but that don't require a licensing or are 
> necessarily part of a GUI framework).

Hi David,

as a result of a web search, I found a class similar to CString, but 
whose implementation is done using STL. This way, you should have both 
the cross-platform feature (because the class is built on top of STL), 
and the CString-like public interface:

   CString-like Class Using STL
   http://www.developer.com/net/cplus/article.php/627611

(I seem to recall that in the past I read something similar of that on 
CodeProject, but I'm not sure...)

Unfortunately, I'm not aware of "simplified" versions of std::vector, 
std::map and tr1::shared_ptr.

My first reaction to STL was that of a disagreement (starting from the 
naming convention; in fact, I prefer camelCasing or PascalCasing to 
c_linux_hacker_casing :)

Moreover, I really don't like std::map having 'first' and 'second'; I 
would much more prefer 'Key' and 'Value' (like in C# BCL Dictionary 
container) as naming choice!

However, I learnt the basics of STL containers like vector and map, and 
now I'm glad to use these STL containers (excluding the naming conventions).
For example, I like the non-linear factor (1.5X) policy of vector 
capacity growing (instead I think that MFC's CArray implements the poor 
arithmetic growing factor).

But I'm not an STL guru, e.g. I've not learnt to use STL allocators, yet.

However, I believe that you are a bright programmer and you can master 
STL as well! :)

If you really don't like STL, you could just use STL as the core to 
implement classes with an MFC-like interface (e.g. a David::CArray, 
David::CList, etc. based on std::vector, std::list, etc.). So, you can 
continue using the MFC-like interfaces, and you also have cross-platform 
thanks to STL implementation "under the hood".
(In this case, you just need to program the STL containers only once, 
when you write the *implementation* of your custom classes like 
David::CArray, then you forget about STL, and you use the usual MFC-like 
public interfaces of your custom classes.)

My 2 cents,
Giovanni

Joseph M. Newcomer wrote:

> Use STL.  It's worth the time to learn it.

STL is a very powerful library, no doubt.

It is also designed with extensibility and customizability in mind, I 
mean: the idea of providing custom allocators for STL containers is 
great, as well as the the distinction (decoupling) between the 
containers and the algorithms, and then using the iterators as kind of a 
"wire" to connect between these two elements (containers and algorithms).

However, if one does not need all this power, maybe a library with a 
simpler interface could be used.

I think that this library could be built on top of STL (e.g. using STL 
as a private implementation of this "simple container" library).

However, there are some bad choices in STL, like having 'first' and 
'second' instead of more understandable Key and Value in STL map, IMHO.

Giovanni

David Ching wrote:
> Hello, I am looking for a good cross platform C++ 'base class' library 
> for things such as strings, containers, and utility functions that are 
> typically found in MFC, Qt, etc.  It doesn't need to support GUI.  This 
> is for a C++ middleware project.
> 
> I realize the default choice is STL, available with standard C++.  But I 
> really hate that, as well as the TR9 and upcoming C++0x standards.  I am 
> looking for a simpler and more sane alternative similar to the classes 
> found in MFC or Qt (but that don't require a licensing or are 
> necessarily part of a GUI framework).
> 
> Thanks for any suggestions,
> David

David - Have you looked at boost?  I haven't done anything with it, but 
thought I would mention it as a possibility.

When you do find what you're looking for, please post back and let us 
know what you settled on.

"Alan Carre" <alan@twilightgames.com> wrote in message 
news:OJ6ggDQYJHA.1188@TK2MSFTNGP05.phx.gbl...
> I don't know if it's stealing, but why not just clip out those things from 
> MFC that you like and try to create a scenario such that it compiles and 
> runs without all the other junk. Things like CString and CList can be 
> pretty much be clipped-out compiled their own; ie. you don't need any of 
> the windows wrapper stuff to use the containers (lists, strings, maps) and 
> it's all very efficient and well-tested code.
>

This used to be easy (you could even just take cstring.h and cstring.cpp and 
compile them directly into a non-MFC project), but then MS refactored these 
things into ATL, and then it became very hard.


> But like I say, not sure if that's allowed. Maybe you have to ask 
> permission from Msoft or something? I mean permission to base a library on 
> *just a subsection of MFC*. You're allowed to *use* MFC so I don't see why 
> it would be illegal "in theory", as long as you're not selling or 
> publishing it.
>
> But ... dunno. I'm not a lawyer.
>

Thanks Alan.  At this point I"m looking for a ready-to use library and not 
have to fight to get MS stuff to build with GNU, etc., and you're right, the 
licensing may be an issue.  I don't think using MFC source code in a cross 
platform manner is going to work.

I see wxWidgets has a wxBase library which looks promising.

Thanks,
David

Thanks G.  At this point I think just using the base classes from a cross 
platform framework like Qt (QtCore) or wxWidgets (wxBase) is my best bet.

Cheers,
David


"Giovanni Dicanio" <giovanniDOTdicanio@REMOVEMEgmail.com> wrote in message 
news:u4N3j6QYJHA.4272@TK2MSFTNGP03.phx.gbl...
> Hi David,
>
> as a result of a web search, I found a class similar to CString, but whose 
> implementation is done using STL. This way, you should have both the 
> cross-platform feature (because the class is built on top of STL), and the 
> CString-like public interface:
>
>   CString-like Class Using STL
>   http://www.developer.com/net/cplus/article.php/627611
>
> (I seem to recall that in the past I read something similar of that on 
> CodeProject, but I'm not sure...)
>
> Unfortunately, I'm not aware of "simplified" versions of std::vector, 
> std::map and tr1::shared_ptr.
>
> My first reaction to STL was that of a disagreement (starting from the 
> naming convention; in fact, I prefer camelCasing or PascalCasing to 
> c_linux_hacker_casing :)
>
> Moreover, I really don't like std::map having 'first' and 'second'; I 
> would much more prefer 'Key' and 'Value' (like in C# BCL Dictionary 
> container) as naming choice!
>
> However, I learnt the basics of STL containers like vector and map, and 
> now I'm glad to use these STL containers (excluding the naming 
> conventions).
> For example, I like the non-linear factor (1.5X) policy of vector capacity 
> growing (instead I think that MFC's CArray implements the poor arithmetic 
> growing factor).
>
> But I'm not an STL guru, e.g. I've not learnt to use STL allocators, yet.
>
> However, I believe that you are a bright programmer and you can master STL 
> as well! :)
>
> If you really don't like STL, you could just use STL as the core to 
> implement classes with an MFC-like interface (e.g. a David::CArray, 
> David::CList, etc. based on std::vector, std::list, etc.). So, you can 
> continue using the MFC-like interfaces, and you also have cross-platform 
> thanks to STL implementation "under the hood".
> (In this case, you just need to program the STL containers only once, when 
> you write the *implementation* of your custom classes like David::CArray, 
> then you forget about STL, and you use the usual MFC-like public 
> interfaces of your custom classes.)
>
> My 2 cents,
> Giovanni 

BobF wrote:

> David - Have you looked at boost?  I haven't done anything with it, but 
> thought I would mention it as a possibility.

Hi Bob,

I think that David's spirit is against the complexity of boost...

Giovanni

David Ching wrote:

> At this point I think just using the base classes from a 
> cross platform framework like Qt (QtCore) or wxWidgets (wxBase) is my 
> best bet.

Thanks David.

You're right: e.g. I'm reading that wxBase offers a wxString class, 
which has a Trim() method.
Instead, with STL std::string you need to implement it yourself with 
something like this:

<code>

string::iterator i;

for (i = str.begin(); i != str.end(); ++i)
{
     if (!isspace(*i))
         break;
}

if (i == str.end())
     str.clear();
else
     str.erase(str.begin(), i);

</code>

wxString has also StartsWith() method ready "off-the-shelf", instead the 
corresponding STL std::string would be something like:

<code>

if ( str.find( substring ) == 0 )
   return true;
else
   return false;

</code>

....and more.

G

I have to say STL.  I know its hard to use (after 18 years of C++, I still 
don't know half of what it can do), but it gets the job done, and it gets it 
done well.

AliR.

"David Ching" <dc@remove-this.dcsoft.com> wrote in message 
news:FA8A0FDA-CC0F-438B-B896-8A696CDBB658@microsoft.com...
> Hello, I am looking for a good cross platform C++ 'base class' library for 
> things such as strings, containers, and utility functions that are 
> typically found in MFC, Qt, etc.  It doesn't need to support GUI.  This is 
> for a C++ middleware project.
>
> I realize the default choice is STL, available with standard C++.  But I 
> really hate that, as well as the TR9 and upcoming C++0x standards.  I am 
> looking for a simpler and more sane alternative similar to the classes 
> found in MFC or Qt (but that don't require a licensing or are necessarily 
> part of a GUI framework).
>
> Thanks for any suggestions,
> David 

"David Ching" <dc@remove-this.dcsoft.com> wrote in message 
news:1F91C76D-2A6A-4B92-B330-DA340AC2D6F5@microsoft.com...
>> MFC that you like and try to create a scenario such that it compiles and 
>> runs without all the other junk. Things like CString and CList can be 
>> pretty much be clipped-out compiled their own; ie. you don't need any of
>
> This used to be easy (you could even just take cstring.h and cstring.cpp 
> and compile them directly into a non-MFC project), but then MS refactored 
> these things into ATL, and then it became very hard.

Oh no! OF COURSE not that code! I was referring to MFC, not this "active MFC 
god-knows-what-the-hell-hit-it" VC8 llBu hSit. I know what you're looking 
for. I have the sources for VC6 on hand and I could probably find 4.2 
somewhere.

> Thanks Alan.  At this point I"m looking for a ready-to use library and not 
> have to fight to get MS stuff to build with GNU, etc., and you're right, 
> the licensing may be an issue.  I don't think using MFC source code in a 
> cross platform manner is going to work.

Well there's nothing really platform specific that I can think of with the 
old stuff. Except maybe that TCHAR business... but that's all #defines so 
you can just add in the bits you need.

But anyway, ya. potential licensing is a problems... That I cannot answer. 
It may be fine if you've purchased VC6 in the past to use that source code 
in your projects. I mean if you don't alter it what's the difference? Is 
taking away features considered "building on someone else's intellectual 
property"?

Actually... in this case I think taking away features *does* amount to added 
value, so I take it back ;)

- Alan Carre

I was ready to suggest wxBase, but it looks like you have
discovered it already.
I have very good experience with the complete wxWidgets library.


But I would really recommend learning STL in the long run.
It is really powerfull, and I find the design quite elegant
(ok, I cannot say the same about the implementation, but
you don't have to read the sources :-)

To address Giovanni's complaint about 'first' and 'second':
it is because they reuse std::pair, which is not always used
in std::map context.
Not sure if creating an identical class with different
member names just for the map would have been a good idea...


-- 
Mihai Nita [Microsoft MVP, Visual C++]
http://www.mihai-nita.net
------------------------------------------
Replace _year_ with _ to get the real email

Hi Mihai,

Mihai N. wrote:

> But I would really recommend learning STL in the long run.
> It is really powerfull, 

100% agree on the power of STL. I think that it is one the most 
important features of this library.

> and I find the design quite elegant
> (ok, I cannot say the same about the implementation, but
> you don't have to read the sources :-)

I find kind of hard to follow the STL implementation code, too :) (at 
least the version provided with Visual C++). I think that advanced 
template programming techniques are required for this kind of job... 
(probably Alexandrescu's book "Modern C++ Design" would be a required 
reading :)


> To address Giovanni's complaint about 'first' and 'second':
> it is because they reuse std::pair, which is not always used
> in std::map context.
> Not sure if creating an identical class with different
> member names just for the map would have been a good idea...

I don't know... but frankly speaking the public interfaces of some STL 
classes are not good, IMHO.
For example, I discussed STL std::string lacking explicit 
ready-off-the-shelf trim, left, right, startsWith, endsWith, etc. public 
methods.

Moreover, if you consider std::map, I think that there is no method like 
contains() that returns a bool, to check if the an item with a given key 
is stored in the map.
Instead, I think that this kind of code should be used (using find() 
method and compare the resulting iterator with .end() :(

   // Check if 'theKey' is a key stored in the map 'myMap'
   map<...>::const_iterator it;
   it = myMap.find( theKey );
   if ( it == myMap.end() )
      ... theKey is not in the map

I would appreciate a method like map::contains(), to just work like this:

   if ( myMap.contains( theKey ) )
      ....

Moreover, it seems to me that there is no method to get a list of all 
the keys stored in the map.
Instead, I think that you should iterate on the map content (e.g. using 
begin() to start), and build a collection by yourself, adding 
iterator->first (i.e. the key) values to an instance of some collection 
class.
Instead, .NET BCL Dictionary container has Keys and Values collections 
ready out-of-the-box :)

So, to summarize, STL is very powerful and the design using the synergy 
of containers+iterators+algorithms is very elegant, no doubt. But the 
interfaces of some of its classes could be much better, IMHO.

I sometimes think of deriving some class from std::string or std::map, 
and write some useful methods to make the interface of these classes 
more rich and useful.

Giovanni

"Giovanni Dicanio" <giovanniDOTdicanio@REMOVEMEgmail.com> wrote in message 
news:OiLBRscYJHA.2124@TK2MSFTNGP04.phx.gbl...
> So, to summarize, STL is very powerful and the design using the synergy of 
> containers+iterators+algorithms is very elegant, no doubt. But the 
> interfaces of some of its classes could be much better, IMHO.
>
> I sometimes think of deriving some class from std::string or std::map, and 
> write some useful methods to make the interface of these classes more rich 
> and useful.
>

Thanks G.  You have a way of saying what I mean better than I do!  :-)

I don't see the point of an elegant design that is not elegant to use.  That 
may work for museum showpieces, but not for software libraries.  ;)

-- David 

Giovanni Dicanio <giovanniDOTdicanio@REMOVEMEgmail.com> wrote in 
news:OiLBRscYJHA.2124@TK2MSFTNGP04.phx.gbl:
> Moreover, if you consider std::map, I think that there is no method 
like 
> contains() that returns a bool, to check if the an item with a given 
key 
> is stored in the map.
> Instead, I think that this kind of code should be used (using find() 
> method and compare the resulting iterator with .end() :(
> 
>    // Check if 'theKey' is a key stored in the map 'myMap'
>    map<...>::const_iterator it;
>    it = myMap.find( theKey );
>    if ( it == myMap.end() )
>       ... theKey is not in the map
> 
> I would appreciate a method like map::contains(), to just work like 
this:
> 
>    if ( myMap.contains( theKey ) )
>       ....

You could always do:
bool contains(map<...> const& myMap, type theKey)
{
    	return myMap.end() != myMap.find(theKey);
}

or
template bool <typename K, typename V>
contains(map<T, V> const& myMap, V const& theKey)
{
    	return myMap.end() != myMap.find(theKey);
}
(my syntax might be off, I don't write templates too often)


That's actually one thing I like about STL - they didn't try to write 
every function that anyone could possibly want. Sure, 'contains' would be 
convenient. But 'find' can be used to do exactly the same thing, and it 
provides more functionality.

Dave Connet

David Ching wrote:

> Thanks G.  You have a way of saying what I mean better than I do!  :-)

Thanks David :)

....but I really have to improve my "Italglish" ;)

G

See below...
On Thu, 18 Dec 2008 13:53:30 +0100, Giovanni Dicanio
<giovanniDOTdicanio@REMOVEMEgmail.com> wrote:

>Joseph M. Newcomer wrote:
>
>> Use STL.  It's worth the time to learn it.
>
>STL is a very powerful library, no doubt.
>
>It is also designed with extensibility and customizability in mind, I 
>mean: the idea of providing custom allocators for STL containers is 
>great, as well as the the distinction (decoupling) between the 
>containers and the algorithms, and then using the iterators as kind of a 
>"wire" to connect between these two elements (containers and algorithms).
****
The extensibility is vaguely interesting, but the flexibility of vector and map are
definitely worth the effort to learn them.  Custom allocators are essential (one of the
problems of MFC for years was that you could not provide custom allocators)
****
>
>However, if one does not need all this power, maybe a library with a 
>simpler interface could be used.
****
I have a few patterns I use.  I don't try to reinvent them each time from basic
principles, I just copy-and-paste them now that they work.  No allocators, for example.
****
>
>I think that this library could be built on top of STL (e.g. using STL 
>as a private implementation of this "simple container" library).
****
I'm less tempted by this idea.  Once you learn a few STL patterns, it is easy to use
because you don't need to do anything ever again to reinvent that pattern.  So I struggled
for a day or so to get map in my head, got it working, and would now need to redo all that
effort, even though I've used it in many apps since.
****
****
>
>However, there are some bad choices in STL, like having 'first' and 
>'second' instead of more understandable Key and Value in STL map, IMHO.
****
I never understood the poor choice of 'first' and 'second' either.
****
>
>Giovanni
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

But C# is not C++; CLR gives a lot more power and flexibility for a number of features
that make it easier to use C#.  I like the language.  But since I have no paying customers
who care about it, I find little cause to use it.  So what else is there to use other than
STL?  Boost has acceptance problems, for example ("We don't use open-source code in our
products"--never mind that the GPL and the Boost license are completely different!)
					joe

On Wed, 17 Dec 2008 21:03:29 -0800, "David Ching" <dc@remove-this.dcsoft.com> wrote:

>"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message 
>news:8jkjk49hs7l182hjfusdukafukrjjh8725@4ax.com...
>> Well, "simpler" and "more sane" usually says "something that has so many 
>> limitations that
>> it probably isn't usable, takes months to develop, is never quite 
>> debugged, and doesn't
>> solve the real problems"
>>
>> Use STL.  It's worth the time to learn it.
>
>Sorry, it's against my religion.  If .NET can produce a great BCL, the C++ 
>people should learn from it.
>
>-- David
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

Did you look at www.mainsoft.com ?
				joe

On Thu, 18 Dec 2008 06:04:24 -0800, "David Ching" <dc@remove-this.dcsoft.com> wrote:

>"Alan Carre" <alan@twilightgames.com> wrote in message 
>news:OJ6ggDQYJHA.1188@TK2MSFTNGP05.phx.gbl...
>> I don't know if it's stealing, but why not just clip out those things from 
>> MFC that you like and try to create a scenario such that it compiles and 
>> runs without all the other junk. Things like CString and CList can be 
>> pretty much be clipped-out compiled their own; ie. you don't need any of 
>> the windows wrapper stuff to use the containers (lists, strings, maps) and 
>> it's all very efficient and well-tested code.
>>
>
>This used to be easy (you could even just take cstring.h and cstring.cpp and 
>compile them directly into a non-MFC project), but then MS refactored these 
>things into ATL, and then it became very hard.
>
>
>> But like I say, not sure if that's allowed. Maybe you have to ask 
>> permission from Msoft or something? I mean permission to base a library on 
>> *just a subsection of MFC*. You're allowed to *use* MFC so I don't see why 
>> it would be illegal "in theory", as long as you're not selling or 
>> publishing it.
>>
>> But ... dunno. I'm not a lawyer.
>>
>
>Thanks Alan.  At this point I"m looking for a ready-to use library and not 
>have to fight to get MS stuff to build with GNU, etc., and you're right, the 
>licensing may be an issue.  I don't think using MFC source code in a cross 
>platform manner is going to work.
>
>I see wxWidgets has a wxBase library which looks promising.
>
>Thanks,
>David
>
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

The biggest problem with the templates is that if you make an error, you get to deal with
the problem in terms of some really bizarre and incomprehensible syntax error messages. It
works extremely well when everything goes right, but is a bit of a pain to figure out
which mistake you made when something goes wrong.

I've been trying for some years now, but I really find the convoluted templates of STL to
be incomprehensible.  But, as observed, I really don't have to read them.  Much.
				joe

On Fri, 19 Dec 2008 12:14:26 +0100, Giovanni Dicanio
<giovanniDOTdicanio@REMOVEMEgmail.com> wrote:

>Hi Mihai,
>
>Mihai N. wrote:
>
>> But I would really recommend learning STL in the long run.
>> It is really powerfull, 
>
>100% agree on the power of STL. I think that it is one the most 
>important features of this library.
>
>> and I find the design quite elegant
>> (ok, I cannot say the same about the implementation, but
>> you don't have to read the sources :-)
>
>I find kind of hard to follow the STL implementation code, too :) (at 
>least the version provided with Visual C++). I think that advanced 
>template programming techniques are required for this kind of job... 
>(probably Alexandrescu's book "Modern C++ Design" would be a required 
>reading :)
>
>
>> To address Giovanni's complaint about 'first' and 'second':
>> it is because they reuse std::pair, which is not always used
>> in std::map context.
>> Not sure if creating an identical class with different
>> member names just for the map would have been a good idea...
>
>I don't know... but frankly speaking the public interfaces of some STL 
>classes are not good, IMHO.
>For example, I discussed STL std::string lacking explicit 
>ready-off-the-shelf trim, left, right, startsWith, endsWith, etc. public 
>methods.
>
>Moreover, if you consider std::map, I think that there is no method like 
>contains() that returns a bool, to check if the an item with a given key 
>is stored in the map.
>Instead, I think that this kind of code should be used (using find() 
>method and compare the resulting iterator with .end() :(
>
>   // Check if 'theKey' is a key stored in the map 'myMap'
>   map<...>::const_iterator it;
>   it = myMap.find( theKey );
>   if ( it == myMap.end() )
>      ... theKey is not in the map
>
>I would appreciate a method like map::contains(), to just work like this:
>
>   if ( myMap.contains( theKey ) )
>      ....
>
>Moreover, it seems to me that there is no method to get a list of all 
>the keys stored in the map.
>Instead, I think that you should iterate on the map content (e.g. using 
>begin() to start), and build a collection by yourself, adding 
>iterator->first (i.e. the key) values to an instance of some collection 
>class.
>Instead, .NET BCL Dictionary container has Keys and Values collections 
>ready out-of-the-box :)
>
>So, to summarize, STL is very powerful and the design using the synergy 
>of containers+iterators+algorithms is very elegant, no doubt. But the 
>interfaces of some of its classes could be much better, IMHO.
>
>I sometimes think of deriving some class from std::string or std::map, 
>and write some useful methods to make the interface of these classes 
>more rich and useful.
>
>Giovanni
>
>
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

> I find kind of hard to follow the STL implementation code, too :) (at 
> least the version provided with Visual C++). I think that advanced 
> template programming techniques are required for this kind of job... 
> (probably Alexandrescu's book "Modern C++ Design" would be a required 
> reading :)

Few years I have browsed "Modern C++ Design" in a Borders store.
And I was ashamed to discover that my rusty-old-style C++ is not good
enough, and I did not understand a thing.
So I have set as my goal to get better.
For the next year I did a lot of reading, experimenting, writing
stuff, as much as possible by the new standard.
And at the end of the year I have bought the book, read it all,
and understood it all.
Now I can understand what is going on, and I can even write some useful
stuff using templates. Far from mastery, but comes in handy once in a while.



> For example, I discussed STL std::string lacking explicit 
> ready-off-the-shelf trim, left, right, startsWith, endsWith, etc. public 
> methods.

Here are also some problems with C/C++ itself, not with STL.
There is no info, for instance, on what is the code page of the strings.
Even wchar_t can be 16 or 32 bits (and if you read the standard, pretty much
anything) and also it does not mean Unicode.

In order to implement a proper "left" you have to know a lot about the
characters in the string. You cannot remove a base character and leave
the following combining characters "hanging"

The current string classes are just a slightly smarter container.


> Moreover, it seems to me that there is no method to get a list of all 
> the keys stored in the map.

A map is a containter.
You want all the keys, the result should be some other kind of container.
If they put it in a list, you would want it in a vector.
I think what STL did was just fine: a powerfull set of APIs, which
makes it very easy to write everything you want in 2-3 lines of code.
You get to appreciate some of it's power when need to change the type
of a container and discover that all you need to do is change the
declaration, and all processing you do on it remains (almost) the same.

Anyway, it is a tool.
Good for some things, not soo good for others.
Knowing how to use all the tools out there allows you to choose the best
one for the job and that makes you a better craftman,


-- 
Mihai Nita [Microsoft MVP, Visual C++]
http://www.mihai-nita.net
------------------------------------------
Replace _year_ with _ to get the real email

> ****
> I never understood the poor choice of 'first' and 'second' either.
> ****

"it is because they reuse std::pair, which is not always used
in std::map context."


-- 
Mihai Nita [Microsoft MVP, Visual C++]
http://www.mihai-nita.net
------------------------------------------
Replace _year_ with _ to get the real email

Joseph M. Newcomer wrote:
> But C# is not C++; CLR gives a lot more power and flexibility for a
> number of features that make it easier to use C#.  I like the
> language.  But since I have no paying customers who care about it, I
> find little cause to use it.  So what else is there to use other than
> STL?

> Boost has acceptance problems, for example ("We don't use
> open-source code in our products"--never mind that the GPL and the
> Boost license are completely different!)

Well, this is a point of view. In my company we use boost everywhere. The policy
is in the other side ( "we don't use propietary libraries" -with a very few
exceptions). To add more information: We develop cross plattform telecom
applications (windows, linux, solaris). Boost has a huge value for us.

Regards


--
Cholo Lennon
Bs.As.
ARG

>In my company we use boost everywhere. The policy
>is in the other side ( "we don't use propietary libraries" -with a very few
>exceptions). To add more information: We develop cross plattform telecom
>applications (windows, linux, solaris). Boost has a huge value for us.

Out of interest, what do you use to develop/debug with on
Linux/Solaris? I've been watching a colleague use Eclipse/CDT and from
what I can see it's nowhere near as nice to debug with as VS when
using STL since there's no visualizers for STL collections like there
are in newer version of VS.

Dave

See below...
On Mon, 22 Dec 2008 17:36:01 -0200, "Cholo Lennon" <chololennon@hotmail.com> wrote:

>Joseph M. Newcomer wrote:
>> But C# is not C++; CLR gives a lot more power and flexibility for a
>> number of features that make it easier to use C#.  I like the
>> language.  But since I have no paying customers who care about it, I
>> find little cause to use it.  So what else is there to use other than
>> STL?
>
>> Boost has acceptance problems, for example ("We don't use
>> open-source code in our products"--never mind that the GPL and the
>> Boost license are completely different!)
>
>Well, this is a point of view. In my company we use boost everywhere. The policy
>is in the other side ( "we don't use propietary libraries" -with a very few
>exceptions). To add more information: We develop cross plattform telecom
>applications (windows, linux, solaris). Boost has a huge value for us.
****
I didn't say their attitude made sense.  I have suggested boost to several clients with
the same reaction, and it turns out their legal people say "no open source" as a policy.
They can't tell the difference between a FreeBSD license, a Boost license, a GPL, or a
Creative Commons (to name the ones most often important).  The technologists find this
laughable, but they can't use sensible technologies as a result.
				joe
****
>
>Regards
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

David Lowndes wrote:
>> In my company we use boost everywhere. The policy
>> is in the other side ( "we don't use propietary libraries" -with a
>> very few exceptions). To add more information: We develop cross
>> plattform telecom applications (windows, linux, solaris). Boost has
>> a huge value for us.
>
> Out of interest, what do you use to develop/debug with on
> Linux/Solaris?

Eclipse CDT

> I've been watching a colleague use Eclipse/CDT and from
> what I can see it's nowhere near as nice to debug with as VS when
> using STL since there's no visualizers for STL collections like there
> are in newer version of VS.

Yes, you're right, it's difficult to debug STL code but you can live with that.
Nothing to say...VS has one of the best debuggers. In the other side I have to
say that Eclipse CDT is a very good IDE with some nice points like the
intellisense, it's works very well most of the time! :-)

>
> Dave

Regards

--
Cholo Lennon
Bs.As.
ARG

Joseph M. Newcomer wrote:
> See below...
> On Mon, 22 Dec 2008 17:36:01 -0200, "Cholo Lennon"
> <chololennon@hotmail.com> wrote:
>
>> Joseph M. Newcomer wrote:
>>> But C# is not C++; CLR gives a lot more power and flexibility for a
>>> number of features that make it easier to use C#.  I like the
>>> language.  But since I have no paying customers who care about it, I
>>> find little cause to use it.  So what else is there to use other
>>> than STL?
>>
>>> Boost has acceptance problems, for example ("We don't use
>>> open-source code in our products"--never mind that the GPL and the
>>> Boost license are completely different!)
>>
>> Well, this is a point of view. In my company we use boost
>> everywhere. The policy is in the other side ( "we don't use
>> propietary libraries" -with a very few exceptions). To add more
>> information: We develop cross plattform telecom applications
>> (windows, linux, solaris). Boost has a huge value for us.
> ****
> I didn't say their attitude made sense.

Ok, I understood you very well. I just wanted to show another point where boost
has not acceptance problems :-)

> I have suggested boost to
> several clients with the same reaction, and it turns out their legal
> people say "no open source" as a policy. They can't tell the
> difference between a FreeBSD license, a Boost license, a GPL, or a
> Creative Commons (to name the ones most often important).  The
> technologists find this laughable, but they can't use sensible
> technologies as a result.
> joe
> ****


--
Cholo Lennon
Bs.As.
ARG

>> Out of interest, what do you use to develop/debug with on
>> Linux/Solaris?
>
>Eclipse CDT
>
>> I've been watching a colleague use Eclipse/CDT and from
>> what I can see it's nowhere near as nice to debug with as VS when
>> using STL since there's no visualizers for STL collections like there
>> are in newer version of VS.
>
>Yes, you're right, it's difficult to debug STL code but you can live with that.
>Nothing to say...VS has one of the best debuggers. In the other side I have to
>say that Eclipse CDT is a very good IDE with some nice points like the
>intellisense, it's works very well most of the time! :-)

Cheers for that - I just wanted to be sure we weren't missing
something since this is our first use of such tools and developing on
Unix platforms.

Merry Christmas
Dave