 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
H Davies
Guest
|
 Posted: Wed Dec 15, 2004 6:52 pm Post subject: Use of an init() function |
 |
|
I have a class which needs two things to be fully operational.
1) A few essential parameters.
2) The loading of a large tree structure from a DB.
If I provide a constructor which takes the essential parameters and
loads everthing from the DB then this would mean clients could not
take a lazy instantiation approach. I.e create object then perform the
lengthy initialisation at a later time. I could delay the loading of
the data to an Init() function which is called at a later date, but
then what if someone uses the default constructor to create the
object. They then have no way to pass the essential parameters needed
for the init() method (I would also have the common problem with using
an init function). I could provide them with a way of setting these
parameters, but it would mean a lot of extra "Set" methods, and a lot
of checking of parameters in the init() function itself. At the moment
I am inclined to take the following approach.
1) Have the constructor take all the essential parameters, check all
of them and throw an exception if any are invalid.
2) Have a loadData() method to do the loading from the DB.
3) To force clients to use the constructor in 1), make the default one
private.
I believe this is the most minimal approach and does not allow the
client to abuse the class too much. The only problem is that all other
member functions would need to check if loadData() had been called
before proceeding. Does anyone have any comments/suggestions on my
problem. Thanks
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
Antoun Kanawati
Guest
|
| Posted: Thu Dec 16, 2004 1:44 pm Post subject: Re: Use of an init() function |
|
|
H Davies wrote:
| Quote: | I have a class which needs two things to be fully operational.
1) A few essential parameters.
2) The loading of a large tree structure from a DB.
If I provide a constructor which takes the essential parameters and
loads everthing from the DB then this would mean clients could not
take a lazy instantiation approach.
[snip]
At the moment
I am inclined to take the following approach.
1) Have the constructor take all the essential parameters, check all
of them and throw an exception if any are invalid.
2) Have a loadData() method to do the loading from the DB.
3) To force clients to use the constructor in 1), make the default one
private.
I believe this is the most minimal approach and does not allow the
client to abuse the class too much. The only problem is that all other
member functions would need to check if loadData() had been called
before proceeding. Does anyone have any comments/suggestions on my
problem. Thanks
|
You can solve this problem as follows:
class MyClass {
bool loaded; // initialize to false in ctor.
inline void loadData() {
if (loaded) return;
this->do_loadData();
loaded = true;
}
void do_loadData() { /* Big Fat implementation */ }
public:
void somePublicMethod(....) {
this->loadData();
.....
}
};
Another somewhat more metamorphic approach would make the class a
wrapper around an implementation pointer, and then switch the
implementation type when it becomes necessary to load the data.
In Smalltalk (or some versions of it), this would be something like
(self become: (FullyLoadedImplementation new: ....)) feature: ....
In Perl, this would be something like:
package Foo;
use FooFullyLoaded;
sub feature {
my $self = shift;
# UNIVERSAL::isa($self, 'Foo') is true now.
FooFullyLoaded->load($self);
# now, UNIVERSAL::isa($self, 'FooFullyLoaded') is true!
# the reference has been reblessed...
return $self->feature(@_);
}
In C++, an object cannot switch types dynamically, so you'll
have to do this sort of trickery with an implementation pointer
and two implementation classes.
--
A. Kanawati
[email]NO.antounk.SPAM (AT) comcast (DOT) net[/email]
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Swampmonster
Guest
|
| Posted: Thu Dec 16, 2004 1:45 pm Post subject: Re: Use of an init() function |
|
|
| Quote: | I have a class which needs two things to be fully operational.
1) A few essential parameters.
2) The loading of a large tree structure from a DB.
If I provide a constructor which takes the essential parameters and
loads everthing from the DB then this would mean clients could not
take a lazy instantiation approach. I.e create object then perform the
lengthy initialisation at a later time.
|
Is there something meaningful a client could do with a "not fully"
initialised instance of that class?
Usually I find it much more comforting to never have "not fully"
initialized instances at all. Saves you a lot of work and headaches. See
the RAII pattern.
| Quote: | 1) Have the constructor take all the essential parameters, check all
of them and throw an exception if any are invalid.
2) Have a loadData() method to do the loading from the DB.
3) To force clients to use the constructor in 1), make the default one
private.
|
4) I'd rewrite "3)" as : Declare no default constructor for that class
at all.
| Quote: | I believe this is the most minimal approach and does not allow the
client to abuse the class too much. The only problem is that all other
member functions would need to check if loadData() had been called
before proceeding. Does anyone have any comments/suggestions on my
problem. Thanks
|
Having the check in the member has one drawback: you must remember to do
it, but the compiler won't cry if you don't.
Instead of that you could write a wrapper/proxy class, that constructs
the object when needed, and then forwards the call. Think of something like:
class Foo {
public:
// do this and that, access db, ...
// throw something if something fails
Foo( int a, const char* b, int c);
// cleanup
~Foo();
int a();
int b();
};
// you can put LazyIndirectFoo this in a detail namespace or
// make it a subclass of LazyFoo if you don't want/need it
// on it's own.
class LazyIndirectFoo {
public:
LazyIndirectFoo( int a, const char* b, int c)
: a_(a), b_(b), c_(c), pimp_(0)
{ }
~LazyIndirectFoo() { delete pimp_; }
Foo& getFoo( ) {
if( !pimp_ ) pimp_ = new Foo( a_, b_.c_str(), c_ );
// if your compilers/(S)TLs new() does not throw:
// if(!pimp_) throw std::bad_alloc("no memory for Foo");
return *pimp_;
// alternatively you can have Foo constructed right
// away in LazyIndirectFoo::LazyIndirectFoo(),
// and only make sure it's fully initialized here,
// (i.e. your loadData() thingy)
// but I see no point in doing this
}
private:
Foo* pimp_;
int a_;
int c_;
// Foo perhaps does not rely on the "b" parameter being valid
// after it's fully constructed, so neither should we
const std::string b_;
};
class LazyFoo {
public:
LazyFoo( int a, const char* b, int c)
: ifoo_( a, b, c )
{ }
// usually one line per method, so should be no big deal
int a() { return ifoo_.getFoo().a(); }
int b() { return ifoo_.getFoo().b(); }
protected:
LazyIndirectFoo ifoo_;
};
Bye,
'monster
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
GianGuz
Guest
|
| Posted: Thu Dec 16, 2004 2:04 pm Post subject: Re: Use of an init() function |
|
|
H Davies wrote:
| Quote: | I have a class which needs two things to be fully operational.
1) A few essential parameters.
2) The loading of a large tree structure from a DB.
If I provide a constructor which takes the essential parameters and
loads everthing from the DB then this would mean clients could not
take a lazy instantiation approach. I.e create object then perform
the
lengthy initialisation at a later time. I could delay the loading of
the data to an Init() function which is called at a later date, but
then what if someone uses the default constructor to create the
object. They then have no way to pass the essential parameters needed
for the init() method (I would also have the common problem with
using
an init function). I could provide them with a way of setting these
parameters, but it would mean a lot of extra "Set" methods, and a lot
of checking of parameters in the init() function itself. At the
moment
I am inclined to take the following approach.
1) Have the constructor take all the essential parameters, check all
of them and throw an exception if any are invalid.
2) Have a loadData() method to do the loading from the DB.
3) To force clients to use the constructor in 1), make the default
one
private.
I believe this is the most minimal approach and does not allow the
client to abuse the class too much. The only problem is that all
other
member functions would need to check if loadData() had been called
before proceeding. Does anyone have any comments/suggestions on my
problem. Thanks
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
You should take care of setting private the default constructor.
If you need to operate with stl containers
you probably need to have it public.
See the following:
#include <vector>
class State {
protected:
typedef enum { undefined, ok } state_values;
state_values state;
State() : state(undefined) { }
explicit State(const state_values s) : state(s) { }
~State() { }
};
class A : public State {
private:
A() : State(undefined) { }
public:
A(const int p0,const int p1=3,const int p2=5,const state_values s =
undefined) : State(s) { }
void loadData() {
//do some stuff with db (is possible to execute these operations in a
different thread
//so the object instance remain available to be queried (State is
still undefined).
//Maybe do this with care!;)
// ...
state = ok;
}
~A() { }
};
int main() {
std::vector<A> a(10);
}
If A() is private you can't create in client side something like that
(try to compile it  But if this is what you want, ok.
I think you should have a default constructor
but you have to define a State behaviour able to tell
you whenever or not the content of A is safe
(i.e the loadData() will return). You can also use
default parameters into your constructors to set a basic
behaviour you want to give to your class users.
Gianguglielmo
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
msalters
Guest
|
| Posted: Thu Dec 16, 2004 2:05 pm Post subject: Re: Use of an init() function |
|
|
H Davies wrote:
| Quote: | I have a class which needs two things to be fully operational.
1) A few essential parameters.
2) The loading of a large tree structure from a DB.
If I provide a constructor which takes the essential parameters and
loads everthing from the DB then this would mean clients could not
take a lazy instantiation approach. I.e create object then perform
the
lengthy initialisation at a later time. I could delay the loading of
the data to an Init() function which is called at a later date, but
then what if someone uses the default constructor to create the
object. They then have no way to pass the essential parameters needed
for the init() method (I would also have the common problem with
using
an init function). I could provide them with a way of setting these
parameters, but it would mean a lot of extra "Set" methods, and a lot
of checking of parameters in the init() function itself. At the
moment
I am inclined to take the following approach.
1) Have the constructor take all the essential parameters, check all
of them and throw an exception if any are invalid.
2) Have a loadData() method to do the loading from the DB.
3) To force clients to use the constructor in 1), make the default
one
private.
|
1 Sounds like a good idea. That is a common pattern, and users will
understand it. 2 May be tricky. Do you really need it? I can imagine
you store a Tree*, and initially set it to 0. In every use of the
tree, you use a private Tree& get() which calls loadData() the
first time.
3 is not needed at all. If you declare a constructor with arguments,
the compiler will not create a default ctor. This makes the error
marginally clearer, when somone forgets the arguments.
The basic guideline is that you should avoid zombies. Either you
have an object, and it is usable (perhaps slow the first time), or
you don't have an object because you don't have enough information
yet. Avoid init() functions and silently failing ctors.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Mickey Moore
Guest
|
| Posted: Fri Dec 17, 2004 11:11 am Post subject: Re: Use of an init() function |
|
|
GianGuz wrote:
| Quote: | int main() {
std::vector<A> a(10);
}
|
I wrote:
| Quote: | No. Sections 20.1.4 and 23.1 of the C++ standard are quite clear:
to be used in a container, an object must be copy constructable and
assignable, but a default constructor *is not* required.
|
I will add that it may take more effort to use objects without
default constructors in the standard containers. While the
containers themselves do not require default constructable objects,
some of their member functions cannot be used for such objects.
The vector<> constructor you use above is one of them obviously, as
you are telling it to make a vector containing 10 default constructed
objects.
You'd instead need to write something like:
std::vector<A> a;
a.push_back(A(12));
a.push_back(A(10,5,2));
// etc.
A nuisance to be sure, but probably far less so than having to
repeatedly check if the object is valid in its member functions.
-- Mickey Moore
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Mickey Moore
Guest
|
| Posted: Fri Dec 17, 2004 11:14 am Post subject: Re: Use of an init() function |
|
|
| Quote: | You should take care of setting private the default
constructor. If you need to operate with stl containers
you probably need to have it public.
|
No. Sections 20.1.4 and 23.1 of the C++ standard are quite clear:
to be used in a container, an object must be copy constructable and
assignable, but default constructor *is not* required.
I suspect the OP didn't realize that the default constructor is not
implicitly created when you declare another constructor (I remember
being confused about that once a long time ago myself), but he was on
the right train of thought: if default construction doesn't make
sense, then don't allow it. (As per Meyers MEC++, item 4: "Avoid
gratuitous default constructors.")
-- Mickey Moore
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
kanze@gabi-soft.fr
Guest
|
| Posted: Fri Dec 17, 2004 1:33 pm Post subject: Re: Use of an init() function |
|
|
GianGuz wrote:
[...]
| Quote: | 1) Have the constructor take all the essential parameters, check
all
of them and throw an exception if any are invalid.
|
[...]
| Quote: | You should take care of setting private the default
constructor. If you need to operate with stl containers you
probably need to have it public.
|
Why? None of the STL containers use the default constructor.
| Quote: | std::vector<A> a(10);
|
The problem here is that you are using a default parameter.
In practice, from the little description he gave, I have a
suspicion that the object in question shouldn't be copiable
either. And that will prevent putting it into STL containers.
On the other hand, there will be no problem with something like:
std::vector< boost::shared_ptr< A > >
which is typically more appropriate for expensive to copy
objects anyway.
--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
kanze@gabi-soft.fr
Guest
|
| Posted: Fri Dec 17, 2004 1:38 pm Post subject: Re: Use of an init() function |
|
|
Swampmonster wrote:
| Quote: | I have a class which needs two things to be fully operational.
1) A few essential parameters.
2) The loading of a large tree structure from a DB.
If I provide a constructor which takes the essential
parameters and loads everthing from the DB then this would
mean clients could not take a lazy instantiation
approach. I.e create object then perform the lengthy
initialisation at a later time.
Is there something meaningful a client could do with a "not
fully" initialised instance of that class? Usually I find it
much more comforting to never have "not fully" initialized
instances at all. Saves you a lot of work and headaches. See
the RAII pattern.
|
I don't quite see the connection with RAII, but I agree.
Basically, by deferring the load, he is requiring all client
code to be able to cope with an error in the load.
I think that this is the key point. He speaks of loading from a
data base. Loading from a data base can fail, so if the load is
deferred, client code at the point when the load takes place
must be able to cope with the error. Typically, this means that
instead of having to cope at one place (where the object is
constructed), you have to cope at many. It also means that some
work may have been done before the error takes place, which
raises the question of what to do with that work.
In general, deferring initialization is only a valid course when
there is a significant chance that the initialization won't be
needed at all. About the only other case I can see it is in an
interactive application, to avoid a visible pause. In this
case, I would probably spawn the initialization off in a lower
priority thread, even though this means some sort of explicit
synchronization before I attempt to use the object, and makes
the problem of when and how to report the error even worse.
If the initialization cannot fail, of course, there is no
problem hiding the fact that it is lazy entirely within the
class.
--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
GianGuz
Guest
|
| Posted: Fri Dec 17, 2004 1:57 pm Post subject: Re: Use of an init() function |
|
|
Yes Mickey:
"Sections 20.1.4 and 23.1 of the C++ standard are quite clear:
to be used in a container, an object must be copy constructable and
assignable, but..."
the point is that you can manage Classes with a private Default
Constructor in containers ...
(i.e. your example )
std::vector<A> a;
a.push_back(A(12));
a.push_back(A(10,5,2));
.... but you should know that you are restricted to such usage. So
something like { static const vector<A> a(N); } that could be a nice
optimization in most cases, becomes useless.
Gianguglielmo
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
David Abrahams
Guest
|
| Posted: Fri Dec 17, 2004 3:08 pm Post subject: Re: Use of an init() function |
|
|
msalters wrote:
| Quote: | H Davies wrote:
I have a class which needs two things to be fully operational.
1) A few essential parameters.
2) The loading of a large tree structure from a DB.
If I provide a constructor which takes the essential parameters and
loads everthing from the DB then this would mean clients could not
take a lazy instantiation approach. I.e create object then perform
the
lengthy initialisation at a later time. I could delay the loading of
the data to an Init() function which is called at a later date, but
then what if someone uses the default constructor to create the
object. They then have no way to pass the essential parameters needed
for the init() method (I would also have the common problem with
using
an init function). I could provide them with a way of setting these
parameters, but it would mean a lot of extra "Set" methods, and a lot
of checking of parameters in the init() function itself. At the
moment
I am inclined to take the following approach.
1) Have the constructor take all the essential parameters, check all
of them and throw an exception if any are invalid.
2) Have a loadData() method to do the loading from the DB.
3) To force clients to use the constructor in 1), make the default
one
private.
1 Sounds like a good idea. That is a common pattern, and users will
understand it.
|
I agree with most of what Michiel is written, but you should be wary of
throwing an exception in response to invalid arguments. If your
function's (constructor's) documentation describes the validity
requirements, it it almost always better to assert() validity rather
than checking and throwing. Assert normally captures the program state
for debugging at the point the problem was detected. Exception
unwinding can have side-effects that destroy valuable debugging
information, not least the call stack. Furthermore, if the caller has
violated the requirements of the function, you generally have to assume
the program state is *broken*. Unwinding with an exception is really
only appropriate in those circumstances where some kind of reasonable
recovery is possible, but what can you really do with a broken program
state?
So I suggest
0.5) Have the constructor take all the essential parameters, and check
all of them and assert() their invalidity.
--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
heath.davies@surfcontrol.
Guest
|
| Posted: Mon Dec 20, 2004 10:35 am Post subject: Re: Use of an init() function |
|
|
Thank you all for your suggestions. I did try and implement an Init()
function, but discovered that if I provided the following constructors
Foo(int x, int y) ;
Foo() ;
Then I also had to provide two init functions to cover all possible
construction/initialisation scenarios, i.e
Init() ;
Init(int x, int y) ;
This led to a lot of checking and complexity. In the end I decided, as
most of you suggested, to omit the declaration of the default
constructor, thus forcing clients to provide the necessary parameters
for the object to be in the correct state. I also added a lazy
parameter to allow for lazy initialisation, like so
Foo(int x, int y, bool bLazy = false) ;
This does mean I have to check on every member function to see whether
the object is initialised. The only problems anyone will have with not
having a default constructor is if you want to decalare a C style array
i.e
Foo array[10] ; // error
Also if your class is a base class and you wish to virtually inherit
from it, you must provide the default constructor. Luckily both of
these errors will be picked up at compile time, which means I can
always change the class if the situation arises.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Daniel Krügler (ne Spange
Guest
|
| Posted: Mon Dec 20, 2004 10:36 am Post subject: Re: Use of an init() function |
|
|
Good morning James Kanze,
[email]kanze (AT) gabi-soft (DOT) fr[/email] schrieb:
| Quote: | GianGuz wrote:
You should take care of setting private the default
constructor. If you need to operate with stl containers you
probably need to have it public.
Why? None of the STL containers use the default constructor.
std::vector<A> a(10);
The problem here is that you are using a default parameter.
Hmmh, as far as I read the standard (especially as I interprete |
17.4.4.4/2, which says
"An implementation can declare additional non-virtual member function
signatures within a class:
— by adding arguments with default values to a member function
signature;172) The same latitude does not
extend to the implementation of virtual or global or non-member
functions, however.
— by replacing a member function signature with default values by two or
more member function signatures
with equivalent behavior;
— by adding a member function signature for a member function name."
) it is implementation-defined whether it uses a default parameter or not.
Or doesn't 17.4.4.4/2 apply in this case (i.e. is overruled by something
more special) ?
Greetings,
Daniel
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
kanze@gabi-soft.fr
Guest
|
| Posted: Tue Dec 21, 2004 12:50 am Post subject: Re: Use of an init() function |
|
|
GianGuz wrote:
| Quote: | "Sections 20.1.4 and 23.1 of the C++ standard are quite clear: to be
used in a container, an object must be copy constructable and
assignable, but..."
the point is that you can manage Classes with a private Default
Constructor in containers ...
|
Or even without default constructors at all.
| Quote: | (i.e. your example )
std::vector<A> a;
a.push_back(A(12));
a.push_back(A(10,5,2));
... but you should know that you are restricted to such usage. So
something like { static const vector<A> a(N); } that could be a nice
optimization in most cases, becomes useless.
|
I'm not quite sure I follow. When would it be an optimization to
create
a vector filled with objects you cannot use? For that matter, I cannot
think of a single case where I would want a static const vector
initialized with all elements the same value, even if I had a default
constructor. Every time I've needed a static const standard container,
it has been initialized using the two iterator form of the constructor,
copying (possibly with conversion) from a C style array, e.g.:
static const A initA[] = { A( 12 ), A( 10, 5, 2 ) ... } ;
static const std::vector< A > a( begin( initA ), end( initA ) ) ;
(I am assuming the pseudo-standard begin and end functions for C style
arrays, which return a pointer to the first element and a pointer to
one
behind the last element.)
--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Francis Glassborow
Guest
|
| Posted: Tue Dec 21, 2004 12:52 am Post subject: Re: Use of an init() function |
|
|
In article <1103532972.016786.288370 (AT) c13g2000cwb (DOT) googlegroups.com>,
[email]heath.davies (AT) surfcontrol (DOT) com[/email] writes
| Quote: | Thank you all for your suggestions. I did try and implement an Init()
function, but discovered that if I provided the following constructors
Foo(int x, int y) ;
Foo() ;
Then I also had to provide two init functions to cover all possible
construction/initialisation scenarios, i.e
Init() ;
Init(int x, int y) ;
|
It is generally a poor idea to provide an init() function unless it is a
private member and only called by the relevant ctors. If you have only
one ctor, there is little purpose in factoring work into an init()
function because that is exactly what a ctor is supposed to do. Because
currently you cannot forward from one ctor to another, it may be useful
to factor common code form multiple ctors into a single (private)
init().
However if you have a case where there is a real problem with creating a
default initialised instance of a type you need to address the issue of
the default copy ctor. Whether we like it or not, given a definition of
mytype that supports a copy ctor (either implicit or explicit and
public)
mytype mt(mt);
is syntactically valid even though it works by self-copying.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
