[boost] Re: A comment and a question about the current configmacros

From: Gennaro Prota (gennaro_prota_at_[hidden])
Date: 2002-08-20 13:23:13

On Tue, 20 Aug 2002 11:03:53 -0500 (EST), Jeremy Siek
<jsiek_at_[hidden]> wrote:

>Gennaro,
>
>That is not true. I told you, I was moving to a new apartment and was not
>checking email for a couple days. Moreover, since then I've been very
>busy, both with the boost release and with studying for PhD qualifying
>exams. So if you feel I was ignoring you, please realize it was not
>intentional on my part.
>

Ok :-)

>I made a few changes to dynamic_bitset yesterday to workaround VC++ and
>Borland. If there are any further changes that you would like to go in,
>please email them to me.
>

The issue is that I had many other things to say you (I don't dare to
modify the code without first discussing it with you; that could be
considered disrespectful) and was waiting for your reply about
encapsulation breaking before asking about new changes: that reply
would have said me that you were checking mail again. Of course, when
I saw that you were posting on the list again but didn't reply to my
mail I thought that you were not interested. In practice instead of
risking that you didn't like my changes I stopped working, and now
there's only 1 day to the new release (while I'm writing it's 8.15 P.M
of August 20 here).

Anyhow these are the main issues:

a) you prefer making all data members (m_bits, m_num_bits,
m_num_blocks) and base classes public for compilers that have
BOOST_NO_MEMBER_TEMPLATE_FRIENDS problems. There are 6 (now 5)
functions that are involved in this problem: operator==, operator<,
operator >, to_block_range and dump_to_string, which need to access
the internal representation but are currently not members.

Your rationale for breaking encapsulation was that people read Boost
code as an example of how to write good C++ code, and the "right" way
to implement operators is as friend functions, not members. Frankly
not even the "make it non member" man (just kidding... I mean Scott
Meyers) would agree with your second assertion in this case, see for
instance

http://www.cuj.com/articles/2000/0002/0002c/0002c.htm?topic=articles

Anyhow, even if you want to make the operators non-members the problem
of "people who read the code" remains: if you are worried about giving
them the wrong hint on operator implementation you should be probably
feeling terror at the idea of exposing all data members and base
classes, even if to workaround compilers bug.
Currently, I would make all the 5 functions above members. Anyhow if
you don't like that solution you can still adopt something like this:

template <typename Block, typename Allocator>
bool operator==(const dynamic_bitset<Block, Allocator>& a, 
                const dynamic_bitset<Block, Allocator>& b)
{
    return a.is_equal_to(b);
}

// for broken compilers this is public and operator== is not a friend
//
template <typename Block, typename Allocator>
bool dynamic_bitset<Block, Allocator>::
is_equal_to(const dynamic_bitset<Block, Allocator> & b) const {
 
    using namespace std;
    return (m_num_bits == b.m_num_bits) && ....
}

In this case you are "exposing" a member function and not data
members!

b) many member functions are still extremely slow and now I don't have
enough time to reimplement them.

c) the functions dealing with strings have problems with types
different from char (think for instance of to_string on a machine
where the encoding for chars is EBCDIC and the encoding for wchar_t is
Unicode). I was working to a solution but, again, I had to stop.

There are other issues but this are the most important.

P.S.: precisely, can changes submitted on day 22? Or is August 21 the
last useful day?

Genny.