Re: [lmi] building with Visual C++

[Vaclav Slavik]

Hi,

Greg Chicares wrote:
> Error
> Trying to index database with key 0: e_number_of_axes is 7, and
> axis_lengths.size() is 196609, but those quantities must be equal.
> [file /lmi/src/lmi/ihs_dbvalue.cpp, line 301]
>
> To reproduce that, load the program and then immediately load
> that file; if you do anything else first, you probably won't see
> the error message.

Strange, I can't reproduce that here (CVS as of yesterday, Windows, 
built using install_msw.sh).

> +        spread = MinPremIntSpread_[Year] * 1.0 / Mode.value();
> -        spread = MinPremIntSpread_[Year] * 1.0 / Mode;
> +    return (1.0 - std::pow(u, 12.0 / Mode.value())) / (1.0 - u);
> -    return (1.0 - std::pow(u, 12.0 / Mode)) / (1.0 - u);
>
> I wonder why those two cases, and other similar cases in other
> files, weren't problems for msvc.

No idea...

> I'm not sure whether it's the explicit instantiation, or the out-
> of-line function bodies, that msvc complains about--or maybe it's
> both in combination.

I think it's some combination of these two and mc_enum's complicated 
template parameters that confuse msvc, because it can compile 
other .tpp files' content without problems, it's only mc_enum.tpp 
that the compiler fails on.

> If you can point out some way in which this 
> doesn't conform to the language standard, 

I can't think of anything, looks like msvc bug to me.

> 'datum_base.hpp': I don't understand these changes:

Quick hacks to make it compile.

> +    // FIXME: VC++ complains about lack of this. Looks suspicious,
> the comment +    // above about implicit versions of these methods
> may be wrong... +    bool operator==(const datum_base& d) const;
>
> The comment referred to is
>   // Implicitly-declared special member functions do the right
> thing. C++2003 12, paragraph 1, defines which are "special", and
> the equality-comparison operator isn't one of them. But how can it
> help to declare this member function and not implement it? Is msvc
> using something like 'guiding-decls' from pre-standard C++?

I don't know, but without operator== declaration, I get this error 
when compiling the code:

1>z:\devel\tt-solutions\lmi\lmi-editor-visualc\any_member.hpp(192) : 
error C2678: binary '==' : no operator found which takes a left-hand 
operand of type 'datum_base' (or there is no acceptable conversion)
1>        z:
\devel\tt-solutions\lmi\lmi-editor-visualc\datum_boolean.hpp(55): 
could be 'bool operator ==(const datum_boolean &,const datum_boolean 
&)'
1>        z:
\devel\tt-solutions\lmi\lmi-editor-visualc\datum_string.hpp(60): 
or 'bool operator ==(const datum_string &,const datum_string &)'
1>        while trying to match the argument list '(datum_base, 
datum_base)'
1>        z:
\devel\tt-solutions\lmi\lmi-editor-visualc\any_member.hpp(184) : 
while compiling class template member function 'bool 
holder<ClassType,ValueType>::equals(const placeholder &) const'
1>        with
1>        [
1>            ClassType=Input,
1>            ValueType=pmd_type
1>        ]

(this is with sources from back when I tried VC++ compilation, they 
weren't updated since, but the relevant files didn't see significant 
changes)

Adding the declaration (but not definition, unlike in case of read() 
and write() methods that need a definition) fixes compilation and it 
links. This may be related to the errors below. 

> -    virtual std::istream& read (std::istream&)       = 0;
> -    virtual std::ostream& write(std::ostream&) const = 0;
> +    // FIXME: this looks like VC++ is trying to make *instances*
> of datum_base +    //        from inside value_cast<> code, which
> would be incorrect, datum_base +    //        copy ctor is not OK!
> +    virtual std::istream& read (std::istream& s)       {return
> s;}//= 0; +    virtual std::ostream& write(std::ostream& s) const
> {return s;}//= 0;
>
> If there's a real standard-C++ problem here, I'd like to fix it.
> But in what way is the implicitly-defined copy ctor not okay?
> Are you sure that's the actual (msvc) problem?

The problem is that msvc tries to instantiate datum_base somewhere and 
because it's not done explicitly, I assume it must be doing a copy 
somewhere where gcc uses references. This fails if datum_base is pure 
virtual, obviously, but succeeds after the patch above, but the 
implicit copy ctor is used somewhere to create a new instance of 
datum_base from some existing instance that must be either 
datum_string or datum_boolean, but is certainly not datum_base (which 
couldn't be instantiated without this patch and so is definitely not 
instantiated in LMI  code explicitly).

Without the patch, msvc complains about datum_base being abstract in 
the following places (line numbers from CVS sources), both in 
holder<> code:

Error   19      error C2259: 'datum_base' : cannot instantiate abstract class   
z:\devel\tt-solutions\lmi\lmi-editor-visualc\any_member.hpp     171
Error   21      error C2259: 'datum_base' : cannot instantiate abstract class   
z:\devel\tt-solutions\lmi\lmi-editor-visualc\any_member.hpp     198

For the second one, full description of the error is this:

1>z:\devel\tt-solutions\lmi\lmi-editor-visualc\any_member.hpp(199) : 
error C2259: 'datum_base' : cannot instantiate abstract class
1>        due to following members:
1>        'std::istream &datum_base::read(std::istream &)' : is 
abstract
1>        z:
\devel\tt-solutions\lmi\lmi-editor-visualc\datum_base.hpp(52) : see 
declaration of 'datum_base::read'
1>        'std::ostream &datum_base::write(std::ostream &) const' : is 
abstract
1>        z:
\devel\tt-solutions\lmi\lmi-editor-visualc\datum_base.hpp(53) : see 
declaration of 'datum_base::write'
1>        z:
\devel\tt-solutions\lmi\lmi-editor-visualc\any_member.hpp(197) : 
while compiling class template member function 'std::string 
holder<ClassType,ValueType>::str(void) const'
1>        with
1>        [
1>            ClassType=Input,
1>            ValueType=pmd_type
1>        ]

For the first one, it's longer, but value_cast<> is involved too. 

I suspect (but didn't verify it yet) that the problem here is that 
arguments are passed to value_cast() by value, not reference, and 
that msvc instantiates the value_cast<> template with From=datum_base 
in this above code while gcc uses From=const datum_base&. If that's 
the case, changing it to use boost::call_traits<T>::param_type should 
help.

Regards,
Vaclav

-- 
PGP key: 0x465264C9, available from http://pgp.mit.edu/