dolfin team mailing list archive

[Ola Skavhaug <skavhaug@xxxxxxxxx>]

On Fri, May 8, 2009 at 1:53 PM, Johan Hake <hake@xxxxxxxxx> wrote:
> On Friday 08 May 2009 13:41:37 Ola Skavhaug wrote:
>> On Fri, May 8, 2009 at 11:40 AM, Anders Logg <logg@xxxxxxxxx> wrote:
>> > On Fri, May 08, 2009 at 11:19:35AM +0200, Anders Logg wrote:
>> >> We currently have two ways to print object data to the screen in
>> >> DOLFIN:
>> >>
>> >>   cout << foo << endl;
>> >>
>> >>   foo.disp()
>> >>
>> >> The first of these prints a nicely-formatted one-liner:
>> >>
>> >>   [Mesh of topological dimension 2 with 121 vertices and 200 cells]
>> >>
>> >> The second prints more detailed information:
>> >>
>> >> Mesh data
>> >> ---------
>> >>
>> >>   Mesh topology
>> >>   -------------
>> >>
>> >>     Topological dimension: 2
>> >>
>> >>     Number of entities:
>> >>
>> >>       dim = 0: 121
>> >>       dim = 1: 0
>> >>       dim = 2: 200
>> >>
>> >>     ...
>> >>
>> >>     Connectivity:
>> >>
>> >>         0 1 2
>> >>       0 - - -
>> >>       1 - - -
>> >>       2 x - -
>> >>
>> >>     Connectivity 2 -- 0:
>> >>
>> >>       0: 0 1 12
>> >>       1: 0 11 12
>> >>       2: 1 2 13
>> >>       3: 1 12 13
>> >>
>> >> I'm thinking we could add a method named str() to all classes and then
>> >> call str() both from LogStream<< and from __str__ in Python.
>> >>
>> >> Should the disp() method remain as it is today or should it be renamed
>> >> to something else? Maybe print()?
>> >
>> > Or maybe info() is more logical, since calling foo.info() will result
>> > in a string being sent to the info() function.
>
> This won't work for some of the linear algebra disp's as these rely on the
> underlaying library. We can of course change this.
>
>> I like this idea. Will all dolfin classes inherit a pure virtual base
>> class defining the str() method?
>
> Isn't the meaning of str() to return a string representation of the object?
> Not print it. That should Info, Debug and its like do?
>
> With disp it is another case as I expect this function to print to the screen
> if I do not tell it otherwise.
>
> Also _pure_ virtual is good. Haveing a base class that all classes should
> inherit is not good as the public/protected base class methods are
> unreachable for the derived classes when these are declared as shared_ptr
> classes in swig.

What do you mean? Pure virtual without a base class? Doesn't make
sense in my head :)

>> If that's the case, we can, optionally, provide a stream to which the
>> info is written, e.g., cerr, cout, or a stringstream from Python.
>
> Could this be done by
>
>  info(foo.str());
>
> and then redirect the output of info?

This could be done in several ways, for instance through the parameter
system or by a base class method a-la set_output(std::ostream&
outstream); Following Anders, your solution would not enable the
redirection of foo.info(), which is what I want. Being able to control
this outside the library, that is in application space, is good.

Ola

>
> Johan
>> Ola
>>
>> > --
>> > Anders
>> >
>> > -----BEGIN PGP SIGNATURE-----
>> > Version: GnuPG v1.4.9 (GNU/Linux)
>> >
>> > iEYEARECAAYFAkoD/gwACgkQTuwUCDsYZdGgBACfTFed2EaWzhyWy2i0PX/hsALz
>> > sPgAn1399kkwXnp7jyp2R9cTarJn0vUZ
>> > =qi/J
>> > -----END PGP SIGNATURE-----
>> >
>> > _______________________________________________
>> > DOLFIN-dev mailing list
>> > DOLFIN-dev@xxxxxxxxxx
>> > http://www.fenics.org/mailman/listinfo/dolfin-dev
>
>
>



-- 
Ola Skavhaug