On Fri, May 8, 2009 at 1:53 PM, Johan Hake <[email protected]> wrote: > On Friday 08 May 2009 13:41:37 Ola Skavhaug wrote: >> On Fri, May 8, 2009 at 11:40 AM, Anders Logg <[email protected]> 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 >> > [email protected] >> > http://www.fenics.org/mailman/listinfo/dolfin-dev > > > -- Ola Skavhaug _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
