...

...

class my_class {

Hi For this kind of stuff, when complex objects have strong interrelationships at startup, I prefer usually to "delay" (not the proper word, I guess) the initiliazation of material within the class in this way: private: long __seed; // I always keep tracks of the seed I use in RNPG stuff rng_t * __rng; // note here i use a dynamically allocated instance matrix_t __matrix // could do the same here but it depends on the pb... rng_t & rng () { if ( __rng == 0) throw "Ooops!"; return *__rng; } void initialise () { // do something useful using 'rng ()'... } void __init () { __rng = new my_rng_t (__seed); // do whatever initialization you need here... __matrix.initialise (); // more init... } void __del () { if (__rng != 0) delete __rng; __rng = 0; // clean other stuff... } public: my_class (long seed_) : __rng (0) //, __matrix (DEFAULT CTOR PARAMETERS) { __seed = seed_; __rng = 0; __init (); } ~my_class () { __del (); } ... }; <<< But it is matter of preference... and maybe you don't want to use dyn. alloc. for the '__rng' field. It also enables to reuse this kind of object using proper public "reset ()" and "init (long?)" methods... Using some 'rng_t' virtual base PRNG class (if available) allows you to easily allocate another kind of generator... Hope it can help. regards frc -- Francois Mauger Laboratoire de Physique Corpusculaire de Caen et Universite de Caen ENSICAEN - 6, Boulevard du Marechal Juin, 14050 CAEN Cedex, FRANCE e-mail: mauger@lpccaen.in2p3.fr

Moritz Beber wrote:

...

I use a class which keeps the random number generator around as a member variable; this class also has a const matrix. Now in the constructor of the class I do something like:

my_class::my_class(args) : rng(seed), matrix(initialise()), ... { ... }

Of course, I want to use the rng to initialise the matrix and that's where things fail. I guess, I could use a different rng just to fill the matrix, or make it non-const and fill it in the constructor body. But does anyone know a neat trick to do this in the way proposed?

This might not be the best way, but you need to at least ensure that the rng member of the class is declared before the matrix (in the class declaration.)

Sorry if this doesn't, in fact, answer you problem. -yzt

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

using the graph concepts for a case where I frequently add or remove edges I came across an inconsistency: removing an edge may invalidate the edge counter because it does not check whether the edge existed or not. This is the code from the header file boost/graph/adjacency_matrix.hpp:

template void remove_edge(typename adjacency_matrix::vertex_descriptor u, typename adjacency_matrix::vertex_descriptor v, adjacency_matrix& g) { --(g.m_num_edges); detail::set_edge_exists(g.get_edge(u,v), false, 0); }

That definitely looks like a problem. Can I get you to file a ticket for it on svn.boost.org? I can address the issue on monday. Andrew Sutton andrew.n.sutton@gmail.com