Hi Ralf,
I am trying to understand what you mean by intuitive? How is it
intuitive for example a test case which tests for the existence of a
header file?
I believe there is hardly anything intuitive about the test case I
presented. A test case, by definition, tests a marginal use-case of the
language and in the absence of the rest of the application (from which
the test-case has been carved) some parts or all of it may not make sense.
The example is useful to me in that it allows me to detect a particular
behaviour of a C++ compiler/linker which allows me to craft my code
accordingly. In what regards portability I would expect the [portable]
infrastructure I use to provide me the means to detect the unportable
language constructs or non-compliant compiler behaviour across the
platforms I am porting on.
The example I provided is representative for a real-world situation:
Microsoft Visual C++ 6.0/7.0/7.1 and Visual Age for C++ 5.x/6.x/7.0 both
violate ODR in certain situations. If you know a better or simpler way
to detect the behaviour in my example I would be happy to learn about
it, but just dismissing the example as not being representative for a
real-world situation is not very helpful.
These being said, I appreciate you're taking the time to respond.
Thanks.
Liviu
Ralf Wildenhues wrote:
Hi Liviu,
* Liviu Nicoara wrote on Wed, Jun 29, 2005 at 06:12:36PM CEST:
One trivial example would be a test to detect whether or not a compiler
collapses static locals in inline functions occurring in both library
and user program. It would require a library and a program, e.g.:
Ouch. While I see why you need more than one translation unit
here, the example seems very unfortunate to me: it's a very ugly
and non-intuitive way of coding IMVHO. Could you provide a useful
example, i.e. one for which it would make sense to adapt a piece
of intended-to-be-portable software to?
To put it another way: with that example, you did not convince me
of the usefulness. IME the autoconf developers are less easily
convinced than I am. :)
Regards,
Ralf
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
