>I'm not sure I understand what you mean here... Maybe you could show a
>very brief example of the structure of your code?
> trigger() { m_Name=""; };
> setName(string &N) {m_Name=N;};
> setConn(connection &C) {
> m_Conn.RemoveTrigger(this);
> m_Conn=C;
> m_Conn.AddTrigger(this);
> };
you can add also somethin like this (If user wants to swith off the trigger
temporarily):
switch_off() {m_Conn.RemoveTrigger(this);};
switch_on() {m_Conn.AddTrigger(this);};
For example I making such class
TMyApplication : pqxx::trigger
and I want my own constructor, something like this:
TMyApplication(char ini_file) {
// getting Conn string and trigger name
...
// making some memory allocations
...
// activate the trigger
setName(N);
setConn(C);
};
~TMyApplication()
{
// clear memory
...
}
>Initializing objects with multiple method invocations like this introduces
>opportunities for bugs: what if you accidentally call setName() on an
>object that has already been setConn()'ed? What if you don't set a name?
>What if you call setName() more than once before the setConn()? What if
>you forget to call setConn()? What if you mistakenly passed a connection
>and name to the constructur *and* called setName() and/or setConn()
>afterwards?
I don't see any problem here: old code will continue to work as it is and new
one will get some new opportunities. I looked through you code: there is no
problem if m_Name is not set or differs - get_notifs() method just will not
call the trigger::operator()(int) - trigger is switched off. The same thing
on m_Conn.
Aleksey.
_______________________________________________
Libpqxx-general mailing list
[email protected]
http://gborg.postgresql.org/mailman/listinfo/libpqxx-general
