I have a use case where I could use a less strict ODR. Or maybe I should say
"multiple compatible definitions rule" instead?

The use case is this. I have a struct S that is used as type of parameters to
functions that are exported from a DLL. The definition of struct S and its
use as function parameter is as in the following example:

struct S {
 S (std::string const &) {...}
 S (char const *) {...}
#if defined (HAS_SOMEOTHERSTRINGLIKECLASS)
 // Additional ctor, conditionally available.
 S (SomeOtherStringLikeClass const &) {...}
 // Additional member function.
 void set (SomeOtherStringLikeClass const &) {...}
#endif

 char const * member;
};

DLLEXPORT void exported_func (S const &);

As ODR exists in the current standard, it requires that the declaration of
struct S and all of its member function be the same everywhere, in the DLL
and in the main executable that uses the DLL. The
HAS_SOMEOTHERSTRINGLIKECLASS symbol has to be defined when we are compiling
both the DLL and the main executable.

But the presence or absence of the additional ctor or member function does
not affect the ability of the two pieces (DLL and main executable) of
compiled code to interact. The structure still has the same size and layout
in both cases when compiled using any existing compiler.

Would it not be possible to soften the ODR into "multiple compatible
definitions rule"?

--
VH

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Vaclav Haisman" <v.haisman@sh.cvut.cz>
[...]
> Would it not be possible to soften the ODR into "multiple compatible
> definitions rule"?

Not likely unless you provide the suggested wording, and then submit it as a
proposal.



--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

-----  O V E R Q U O T E D  -----
-----  Q U O T E D   B A N N E R  -----

Couldn't you just do a forward declaration of SomeOtherStringLikeClass and
not make the additional members inline?

/Leigh

"Vaclav Haisman" <v.haisman@sh.cvut.cz> wrote in message
news:4A7C7ADC.1020607@sh.cvut.cz...
>I have a use case where I could use a less strict ODR. Or maybe I should
>say
> "multiple compatible definitions rule" instead?
>
> The use case is this. I have a struct S that is used as type of parameters
> to
> functions that are exported from a DLL. The definition of struct S and its
> use as function parameter is as in the following example:
>
> struct S {
> S (std::string const &) {...}
> S (char const *) {...}
> #if defined (HAS_SOMEOTHERSTRINGLIKECLASS)
> // Additional ctor, conditionally available.
> S (SomeOtherStringLikeClass const &) {...}
> // Additional member function.
> void set (SomeOtherStringLikeClass const &) {...}
> #endif
>
> char const * member;
> };
>
> DLLEXPORT void exported_func (S const &);
>
> As ODR exists in the current standard, it requires that the declaration of
> struct S and all of its member function be the same everywhere, in the DLL
> and in the main executable that uses the DLL. The
> HAS_SOMEOTHERSTRINGLIKECLASS symbol has to be defined when we are
> compiling
> both the DLL and the main executable.
>
> But the presence or absence of the additional ctor or member function does
> not affect the ability of the two pieces (DLL and main executable) of
> compiled code to interact. The structure still has the same size and
> layout
> in both cases when compiled using any existing compiler.
>
> Would it not be possible to soften the ODR into "multiple compatible
> definitions rule"?
>
> --
> VH
>
> --
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]
>


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]