Re: [htdig-dev] c++, '::', scoping and object instantiation

[Neal R. <ne...@ri...>]

> I believe this class is intended as a singleton. Both pointers
> end up pointing to the same instance of an HtConfiguration object
> that is in fact a static member of the HtConfiguration class. The
> intent of such a design is that there only ever be one instance
> of the class.

	Sure and it's referenced all over.  I understand its
utility for the CGIs and util executables.

	Multiple config objects are useful in a libhtdig setting... see
below.

> As a singleton, the class is not intended to be used in this way.
> If the static _config member is NULL when config() is called, an
> instance is created. Otherwise the existing instance is returned.

	It may be nice to have a tester function that will return TRUE or
FALSE about if _config == NULL.

	This is in in the context of the code rework as 'libhtdig':

	The problem was that consecutive calls to htdig_xxxx
[for indexing] then htfuzzy_xxx caused problems since both functions try
and reinitialize the config object with the defaults.  This was causing
program hang!

	Before the calls to htfuzzy_xxx, a call to htdig_close was issued
that attempted to destroy the config object.  Even though the destructor
is empty, C++ is doing something by default to the object.

	The next call (inside htfuzzy_xxx) to

	config->Defaults(&defaults[0]);

	hung the program.

> Generally you don't want to destroy the instance since no one
> really owns it.


	True, when HtDig is used as a stand alone executable.. the
system takes care of it when the process exits.  In the 'libhtdig'
setting, a destructor may be useful as part of a cleanup method.

	If libhtdig were ever used in a server choices would need to be
made about the procedure for opening and closing and existence of multiple
configurations.

	What if libhtdig is being used to operate on two separate and
independent indexes?  Two configurations exist there.

	Similar to one MySQL server operating on two separate databases
with different schemas.

	Ideally this would be useful:

	1) libhtdig contains an array of all necessary global
	   objects/vars.
	2) calls to htdig_open() return an indicator value, like a SQL
		indicator
	3) subsequent calls to any libhtdig functionality pass in the
	   indicator.  This is used as the index to the global
	   object arrays
	4) calls to htdig_close(int) destroy those global objects in the
	   array... like sql_free in MySQL.

As it stands can you think of any other objects besides config using the
'singleton design'?  This is definitely a gotcha for libhtdig.

Thanks!

-- 
Neal Richter 
Knowledgebase Developer
RightNow Technologies, Inc.
Customer Service for Every Web Site