[PPL-devel] ppl/tests/Polyhedron numberinput1.cc

[Abramo Bagnara]

Matthew Mundell ha scritto:
> CVSROOT:	/cvs/ppl
> Module name:	ppl
> Changes by:	mundell at cs.unipr.it	2005-09-29 11:24:26
> 
> Modified files:
> 	tests/Polyhedron: numberinput1.cc 
> 
> Log message:
> 	Convert test_template to function test, which uses an mpq_class
> 	checked number.  In function test read number with function input
> 	(instead of op>>), compare the result of the conversion with an
> 	expected result, and use is_not_a_number instead of classify.
> 	
> 	Narrow long test invocations.  Add an expected result value to each
> 	invocation.
> 

Some notes:

1) You don't need to explicitly pass template arguments to templatic
functions when these can be deduced from type of arguments.

IMO this is a bad practice.

  Checked_Number<mpq_class, Test_Extended_Number_Policy> q1;

  Result result = Parma_Polyhedra_Library::input<mpq_class,
Test_Extended_Number_Policy>(q1, f, ROUND_UP);

can be written as a far more readable:

Result result = input(q1, f, ROUND_UP);

(eliminating also the redundant namespace specification)

2) Don't try to be excessively smart in parsing:

>  test("3^^", "0", "", V_EQ);   // FIX "3", "^^", V_EQ

3^^ is a regular input up to detection of end
Then the input is consumed fully.

The policy is that when we find the first character that prove that
input is terminated or invalid we unget this character and we exit.

3) Just a doubt (sorry for my annoying paranoia): the expected result of
every tests has been checked by you? I'd like to avoid an excess of
trust in my code: tests are only useful if the expected values are
generated in a very different way wrt the thing that has to be tested :-)


-- 
Abramo Bagnara                       mailto:abramobagnara at tin.it

Opera Unica                          Phone: +39.0546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy