Re: [lmi] passing objects instead of references to value_cast

[Greg Chicares]

On 2008-05-26 00:34Z, Vadim Zeitlin wrote:
> 
>  One of the problems we have when compiling LMI with MSVC is that we get
> errors such as this:
> 
> any_member.hpp(171) : error C2259: 'datum_base' : cannot instantiate abstract 
> class
> any_member.hpp(198) : error C2259: 'datum_base' : cannot instantiate abstract 
> class

Your [snipped] analysis does seem to indicate an actual problem.
You had a special case that would permit a special workaround,
but I skip over that because I think we want a change like this
to handle the general case (which might incidentally resolve the
special problem):

[in 'value_cast.hpp'...]
>  Would replacing
> "From" with "const From&" unconditionally be acceptable?

I think that would be a more natural signature anyway, so I have
no objection at all in principle.

Experimentally, I changed
  s/From from/From const& from/g
in that file, and the unit tests succeeded with gcc-3.4.4; but
they failed with como, giving errors like this:

    instantiation of class "std::_Numeric_limits_base<__number>
        [with __number=const char [2]]" at line 324

apparently because of

                std::numeric_limits<To  >::is_specialized
            &&  std::numeric_limits<From>::is_specialized

so I'm not sure how pervasive the change will have to be. But it
seems like a good change, so let it pervade wherever it must.

We want this to work for all of {g++, como, msvc}. I'd somewhat
prefer to keep it "working" for borland, but if there's a fair
reason to break it for borland, then I'd shed few tears. Really,
the only advantage to using borland here is that it has its own
independently C runtime; for all the other msw toolchains, the
underlying implementations of snprintf() and strto[f,d,ld,l,ll]()
all ultimately come from ms. (For versions of MinGW gcc later
than the one we use in production, that's changing.)

> This is by far the
> easiest solution but it does impose some overhead for primitive types which
> could be passed by value otherwise. Do you think this is significant in the
> context of LMI use?

No, I don't think it could possibly be significant. The worst
thing that could happen, AFAICT, is that we would in effect do

  std::string f(int const& d)
  {
      // initialize appropriate X, Y, Z...
      return snprintf(X, "%.*i", Y, Z, d);
  }

where passing the int by value saves about zero percent of the
overhead of calling snprintf() (or something like strtol() for
the opposite conversion). Of course we'll measure runtime speed
just to be sure.

Passing the argument by const reference seems like the right
thing to do. Probably I passed it by value because I studied
Henney's boost::lexical_cast, which originally passed by value,
and saw no strong reason at the time to do otherwise here.
(Lines 191-195 here:

  http://cvs.savannah.gnu.org/viewvc/lmi/lmi/stream_cast.hpp?annotate=1.19

give a similar rationale for the return type.) However, Henney
later changed the way he passes the argument:

  http://www.boost.org/doc/libs/1_35_0/libs/conversion/lexical_cast.htm
|
| June 2005:
|
|    * Call-by-const reference for the parameters. This requires
| partial specialization of class templates, so it doesn't work
| for MSVC 6, and it uses the original pass by value there.

which only gives further support for the change you propose.