On Friday 08 May 2009 15:09:44 Ola Skavhaug wrote: > 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 :)
Well, of course not. To make a long story short. Based on your (Olas) suggestions I have fixed this for Variable. Just reimplemented the member functions of Variable in its derived classes. Johan > >> 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 _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
