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


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 "Adelle Hartley" <adelle bullet.net.au> writes:
Hi Mattew,


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


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


 it

 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


in

 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


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,


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


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? ;-)


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


 in

 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


 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,


 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


 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? ;-)


 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


class(es).

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




templates

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


 class(es).

 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


(subject

 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