www.digitalmars.com         C & C++   DMDScript  

c++.stlsoft - ccombstr_veneer

reply "Adelle Hartley" <adelle bullet.net.au> writes:
Hi,

I just started using StlSoft today.  I like ccombstr_veneer, but I was
wondering whether it would be possible in some parallel universe not too far
from here, to use it like this:

class MyMostExcellentStringClass : public
ccombstr_veneer<MyHideouslyCleverStringClass>
{
    void DoSomethingHideouslyClever()
    {
        ... do something that uses both CComBSTR and ccombstr_veneer methods
    }
};


Is this possible?

Adelle.
Dec 11 2005
parent reply "Matthew" <matthew hat.stlsoft.dot.org> writes:
This is one of the classes that's going to be getting a rewrite soon, to
properly support, and distinguish between, class adaptation and instance
adaptation, so your request is timely.

Unfortunately, I think you'll have to provide more information about what it
is that you're wanting. I am, alas, not sufficiently hideously clever to
intuit what DoSomethingHideouslyClever() might achieve. ;)

Give me a clue, and I'll see what I can do.

Cheers

Matthew

P.S. May I ask how you heard about STLSoft?


"Adelle Hartley" <adelle bullet.net.au> wrote in message
news:dngrfp$vva$1 digitaldaemon.com...
 Hi,

 I just started using StlSoft today.  I like ccombstr_veneer, but I was
 wondering whether it would be possible in some parallel universe not too

 from here, to use it like this:

 class MyMostExcellentStringClass : public
 ccombstr_veneer<MyHideouslyCleverStringClass>
 {
     void DoSomethingHideouslyClever()
     {
         ... do something that uses both CComBSTR and ccombstr_veneer

     }
 };


 Is this possible?

 Adelle.

Dec 11 2005
parent reply "Adelle Hartley" <adelle bullet.net.au> writes:
Hi Mattew,

 Unfortunately, I think you'll have to provide more information about what

 is that you're wanting. I am, alas, not sufficiently hideously clever to
 intuit what DoSomethingHideouslyClever() might achieve. ;)

I have a battery of string functions that I like to use. After playing with Ruby for a while, I thought it would be neat if in my C++ code, my string functions could be methods of the The One True String Class (or at least, The One True BSTR wrapper). My problem is that in creating a class that inherits from ccombstr_veneer, one loses much of the benefits of ccombstr_veneer - constructors, assignment operators, type conversion operators, etc. If ccombstr_veneer were a template, I think it would be the ideal basis from which anyone can derive their own personal One True BSTR wrapper.
 P.S. May I ask how you heard about STLSoft?

I think I first discovered STLSoft in 2003 when I was looking for useful libraries that I could use in continuing my life's work of developing the greatest application ever. At the time, I wrote a note to myself that (along with wxwindows) STLSoft was "not ready yet, but shows promise" and resolved to check up on it at a later date. I don't recall what the magic words are that I typed into Google to come up with STLSoft. Adelle.
Dec 14 2005
parent reply "Matthew" <matthew stlsoft.com> writes:
 Unfortunately, I think you'll have to provide more information about what

 is that you're wanting. I am, alas, not sufficiently hideously clever to
 intuit what DoSomethingHideouslyClever() might achieve. ;)

I have a battery of string functions that I like to use. After playing with Ruby for a while, I thought it would be neat if in my C++ code, my string functions could be methods of the The One True String Class (or at least, The One True BSTR wrapper). My problem is that in creating a class that inherits from ccombstr_veneer, one loses much of the benefits of ccombstr_veneer - constructors, assignment operators, type conversion operators, etc. If ccombstr_veneer were a template, I think it would be the ideal basis from which anyone can derive their own personal One True BSTR wrapper.

Well, this is very interesting. 1. I've been unhappy with the veneer strings - BSTR and CString - for some time, and have thought about them being adaptors. (FYI: A couple of months ago I rewrote the MFCSTL CArray adaptor classes, such that they now share the bulk of their implementation. CArray_iadaptor adapts instances at runtime. CArray_cadaptor adapts classes at compile-time. These'll both be in the next release.) 2. I'm currently kicking XMLSTL into life, after a couple of years of promises, and it's going very well. One of the remaining issues with the current alpha state of it is that it uses the BStr class from the libraries of my company (Synesis), which will eventually have to change. So, a bona fide BSTR class for STLSoft is something that'd find a happy home in XMLSTL (or, rather, in the xmlstl::msxml::dom namespace). 3. Strings feature in volume 2 of my next book, Extended STL, which I'll be finalising in the first quarter of next year. (I'm currently working like a Trojan on volume 1, to be ready for the new year.) I'd considered covering string adaptation, and so this might well be a great tie-in. The thinking I've done on this subject inclines me to steer away from trying to be an everything to everyone, and rather focusing on adapting BSTR types - BSTR, CComBSTR, etc. - to an interface corresponding to std::basic_string (to an appropriate degree, a la simple_string, static_string, string_view) but that's tuned to BSTR-related operations, e.g. the ability to be passed, destructively or nondestructively, to a COM API function/interface method. This is one facility that the SynesisCom::BStr class provides (which is discussed in http://www.artima.com/cppsource/YourAddress.html) provides, and that I'd want such a wrapper to emulate. So the big question, as I see it, is defining the range of adaptable types, to use with our putative BSTR_iadaptor / BSTR_cadaptor templates. Should this range be restricted to strings that are themselves manipulating OLECHAR/wchar_t, or should any string type be adaptable?
 P.S. May I ask how you heard about STLSoft?

I think I first discovered STLSoft in 2003 when I was looking for useful libraries that I could use in continuing my life's work of developing the greatest application ever.

Which is what? Sounds intriguing ...
  At the time, I wrote a note to myself that
 (along with wxwindows) STLSoft was "not ready yet, but shows promise" and
 resolved to check up on it at a later date.

Well, I hope it's now a bit past that. (FYI: 1.9 will be on its way in the next few weeks.) The one thing that still sucks about the libraries is the documentation. I keep trying to find time to document it, but on top of work, kids, writing a book (that's morphed into two volumes) and my articles and columns, it's a little hard to come by. Hopefully, you might be inclined to assist with that a little if we get some nice BSTR adaptor going? ;-) Cheers Matthew
Dec 14 2005
parent reply "Adelle Hartley" <adelle bullet.net.au> writes:
 1. I've been unhappy with the veneer strings - BSTR and CString - for some
 time, and have thought about them being adaptors. (FYI: A couple of months
 ago I rewrote the MFCSTL CArray adaptor classes, such that they now share
 the bulk of their implementation. CArray_iadaptor adapts instances at
 runtime. CArray_cadaptor adapts classes at compile-time. These'll both be

 the next release.)

I don't know if what you're thinking will help me or not, but my problem as I see it now, is that (1) as things stand, if I write a class that inherits from ccombstr_veneer, my derived class lacks most of the niftyness of ccombstr_veneer (like operator [], etc). (2) If ccombstr_veneer were made into a template that takes my class as a base class (as hinted at in my original post), the template instantiation keeps all of ccombstr_veneer's niftyness, but I can't use any of that niftyness inside my implementation of DoSomethingHideouslyClever. For now, I think the pragmatic thing to do is to just leave DoSomethingHideouslyClever as a non-class function that takes a string as its first parameter.
 The thinking I've done on this subject inclines me to steer away from

 to be an everything to everyone, and rather focusing on adapting BSTR
 types - BSTR, CComBSTR, etc. - to an interface corresponding to
 std::basic_string (to an appropriate degree, a la simple_string,
 static_string, string_view) but that's tuned to BSTR-related operations,

This is what prompted me to choose ccombstr_veneer. I found some Ultimate String Classes on CodeGuru and other places, but they all tried too hard to be everything to everyone. I'm not using MFC, I just want something that will be very lightweight in its handling of BSTRs. Preferably doing as few copy operations as possible, as some of my BSTRs can be very long. To that end, I have recently begun toying with the idea of a temporary substring class that can be passed by reference, but uses the same memory as its parent string: (air code follows) class CComTempSubstring { protected: OLECHAR* m_pFirstChar; size_t* m_pLength; long m_lPreviousData; public: CComTempSubstring(BSTR* bstr, size_t start, site_t len) { ccombstr_veneer bstrString(bstr); m_pFirstChar = &(bstrString[start-1]); m_pLength = reinterpret_cast<size_t*>(m_pFirstChar); m_pLength--; m_lPreviousData = *m_pLength; *m_pLength = len; } ~CComTempSubstring() { *m_pLength = m_lPreviousData; } }; I haven't tried out the above yet, and my pointer arithmetic is probably a bit dodgy, but I don't see why something like the above wouldn't (a) work, and (b) be faster than making a temporary copy of a 20k string.
 The one thing that still sucks about the libraries is the documentation. I
 keep trying to find time to document it, but on top of work, kids, writing

 book (that's morphed into two volumes) and my articles and columns, it's a
 little hard to come by.

 Hopefully, you might be inclined to assist with that a little if we get

 nice BSTR adaptor going? ;-)

Assuming I understand it... I find I know less every day. Cheers, Adelle.
Dec 14 2005
parent reply "Matthew" <matthew stlsoft.com> writes:
Adelle

Please check out the CArray_cadaptor and CArray_iadaptor adaptor templates 
in the latest 1.9 beta. This is how I plan to do the BSTR adaptor class(es).

Having said that, it's not likely I'll get change until the new year, but 
you never know, a spare moment might pop up. ;-)

Cheers

Matthew

"Adelle Hartley" <adelle bullet.net.au> wrote in message 
news:dnp3b2$sug$1 digitaldaemon.com...
 1. I've been unhappy with the veneer strings - BSTR and CString - for 
 some
 time, and have thought about them being adaptors. (FYI: A couple of 
 months
 ago I rewrote the MFCSTL CArray adaptor classes, such that they now share
 the bulk of their implementation. CArray_iadaptor adapts instances at
 runtime. CArray_cadaptor adapts classes at compile-time. These'll both be

 the next release.)

I don't know if what you're thinking will help me or not, but my problem as I see it now, is that (1) as things stand, if I write a class that inherits from ccombstr_veneer, my derived class lacks most of the niftyness of ccombstr_veneer (like operator [], etc). (2) If ccombstr_veneer were made into a template that takes my class as a base class (as hinted at in my original post), the template instantiation keeps all of ccombstr_veneer's niftyness, but I can't use any of that niftyness inside my implementation of DoSomethingHideouslyClever. For now, I think the pragmatic thing to do is to just leave DoSomethingHideouslyClever as a non-class function that takes a string as its first parameter.
 The thinking I've done on this subject inclines me to steer away from

 to be an everything to everyone, and rather focusing on adapting BSTR
 types - BSTR, CComBSTR, etc. - to an interface corresponding to
 std::basic_string (to an appropriate degree, a la simple_string,
 static_string, string_view) but that's tuned to BSTR-related operations,

This is what prompted me to choose ccombstr_veneer. I found some Ultimate String Classes on CodeGuru and other places, but they all tried too hard to be everything to everyone. I'm not using MFC, I just want something that will be very lightweight in its handling of BSTRs. Preferably doing as few copy operations as possible, as some of my BSTRs can be very long. To that end, I have recently begun toying with the idea of a temporary substring class that can be passed by reference, but uses the same memory as its parent string: (air code follows) class CComTempSubstring { protected: OLECHAR* m_pFirstChar; size_t* m_pLength; long m_lPreviousData; public: CComTempSubstring(BSTR* bstr, size_t start, site_t len) { ccombstr_veneer bstrString(bstr); m_pFirstChar = &(bstrString[start-1]); m_pLength = reinterpret_cast<size_t*>(m_pFirstChar); m_pLength--; m_lPreviousData = *m_pLength; *m_pLength = len; } ~CComTempSubstring() { *m_pLength = m_lPreviousData; } }; I haven't tried out the above yet, and my pointer arithmetic is probably a bit dodgy, but I don't see why something like the above wouldn't (a) work, and (b) be faster than making a temporary copy of a 20k string.
 The one thing that still sucks about the libraries is the documentation. 
 I
 keep trying to find time to document it, but on top of work, kids, 
 writing

 book (that's morphed into two volumes) and my articles and columns, it's 
 a
 little hard to come by.

 Hopefully, you might be inclined to assist with that a little if we get

 nice BSTR adaptor going? ;-)

Assuming I understand it... I find I know less every day. Cheers, Adelle.

Dec 20 2005
parent reply "Adelle Hartley" <adelle bullet.net.au> writes:
 Please check out the CArray_cadaptor and CArray_iadaptor adaptor templates
 in the latest 1.9 beta. This is how I plan to do the BSTR adaptor

I had a look at these classes. I'm not sure I understand the difference between how CArray_cadaptor works and the way ccombstr_veneer works. However, I DO like the idea of being able to treat a BSTR like a basic_string, and if I were using MFC I think I would really appreciate CArray_cadaptor for similar reasons. I have been working on some code that uses ccombstr_veneer this way (subject to its current limitations), but I haven't had time to see if it actually works. Adelle.
Dec 23 2005
parent "Matthew" <matthew hat.stlsoft.dot.org> writes:
"Adelle Hartley" <adelle bullet.net.au> wrote in message
news:doh50j$1n1s$1 digitaldaemon.com...
 Please check out the CArray_cadaptor and CArray_iadaptor adaptor


 in the latest 1.9 beta. This is how I plan to do the BSTR adaptor

I had a look at these classes. I'm not sure I understand the difference between how CArray_cadaptor works and the way ccombstr_veneer works.

There's no difference in principal, or, rather, in what's achieved. The "big advance" I think I've made with the CArray adaptors is to have the same code serving both class and instance adaptation. And I think the names are more germane than the previous incarnations.
 However, I DO like the idea of being able to treat a BSTR like a
 basic_string, and if I were using MFC I think I would really appreciate
 CArray_cadaptor for similar reasons.

Good to hear. I plan to serve both CString (via CString_cadaptor and CString_iadaptor) and BSTR / CComBSTR / _bstr_t / whatever (via BSTR_adaptor) in the same way. I'll do CString first, because there's no debate about what's being adapted and what facilities it has. Doing the BSTR stuff, once I'm practised with the CString stuff, will be a matter of working out how to serve as wide a set of BSTR-like string types without making it too highly coupled.
 I have been working on some code that uses ccombstr_veneer this way

 to its current limitations), but I haven't had time to see if it actually
 works.

It's such a shame we have to compile, build and test our code. It so often leads to disappointment. ;-) Have a great Christmas, and I hope to have some presents for you to play with by Hogmany. Cheers Matthew
Dec 23 2005