Constructor problem - help needed urgently to resolve this

[Alfonso Morra]

Hi,

I have some code from an example, that I want to retrofit into my
project. The code from the example has the following line:

SharedAppenderP tr myAppender( new RollingFileAppe nder("MyAppende r"))
I want to move this line of code to a constructor in a wrapper class, so
that I can determine the appropriate Appender name during the object's
construction.

I have done the ff:

declared a privariate variable in my wrapper class as ff:
SharedAppenderP tr m_Appender ;

In my (wrapper class) constructor, I have the following code:

.....
m_Appender = new RollingFileAppe nder(log_file_n ame)
.....
However, I am getting linking errors (unresolved external symbol). I was
obviously wrong in thinking that I could use copy assignment in this
way. This is the actual liker error I'm getting (Although I am using MS
tools in this instance, I don't believe its a MS specific problem).

Auditor error LNK2019: unresolved external symbol "__declspec(dll import)
public: class log4cplus::help ers::SharedObje ctPtr<class
log4cplus::Appe nder> & __thiscall
log4cplus::help ers::SharedObje ctPtr<class
log4cplus::Appe nder>::operator =(class log4cplus::Appe nder *)"
(__imp_??4?$Sha redObjectPtr@VA ppender@log4cpl us@@@helpers@lo g4cplus@@QAEAAV 012@PAVAppender @2@@Z)
referenced in function "public: __thiscall Auditor::Audito r(int,int)"
(??0Auditor@@QA E@HH@Z)

Any helpful suggestions (or better still, an actual solution to the
problem) will be greatly appreciated.

MTIA

[Alf P. Steinbach]

* Alfonso Morra:

Here is the complete code of an example that I am using to write my
wrapper class:

int main( ) {
SharedAppenderP tr myAppender( new RollingFileAppe nder("myLogFile .log")) ;
myAppender->setName("myApp enderName") ;
std::auto_ptr<L ayout> myLayout = std::auto_ptr<L ayout>(new
log4cplus::Patt ernLayout("%d{% Y-%m-%d %a %H:%M:%S} %-5p [%t]: %m%n"));
myAppender->setLayout( myLayout );
Logger myLogger= Logger::getInst ance("myLoggerN ame") ;
myLogger.addApp ender(myAppende r);
myLogger.setLog Level ( INFO_LOG_LEVEL );
myLogger.log( INFO_LOG_LEVEL, "Info Level Message") ;
myLogger.log( TRACE_LOG_LEVEL , "Trace Level Mesage") ;
}

As you can see, the variables are all local variables that go out of
scope after main has ceased. What I am doing is wrapping up the
functionality provided by main, into a wrapper class (lets call this
LogWriter). It is clear from the code above, that I will need variables
(or pointers to objects) of type SharedAppenderP tr, Layout, LogLevel and
Logger at the very least. So armed with these facts, I proced as follows:

class LogWriter {
public:
LogWriter(int,L ogLevel);
virtual ~LogWriter() ;

LogMsg(const string&) ;
setLogLevel(Log Level) ;
...

private:
/* Keep hidden from prying eyes*/
LogWriter(const LogWriter&);
LogWriter& operator=(const LogWriter&);
Presumably this assignment operator is not implemented, and if so, good.

Otherwise, if it's implemented it won't fly if SharedAppenderP tr doesn't
provide an assignment operator.

But it's possible that you just haven't #included the source for that
operator implementation, or not linked with the appropriate object file or
library.

/* Variables */
SharedAppenderP tr m_Appender ; //Default ctor invoked
log4cplus::tstr ing m_AppenderName ;
log4cplus::tstr ing m_LoggerName ;
log4cplus::tstr ing m_logFilename ;
std::auto_ptr<L ayout> m_Layout ; //Default ctor invoked
LogLevel m_lvl ;
Logger m_Logger ; //Default ctor invoked
bool m_debugOn ;

/*Methods */
log4cplus::tstr ing getLogNameByMod uleId( int ) ;

};
Since we have m_Appender, m_Layout and m_Logger already constructed
(default ctors),

Here's the thing: you do not have them already constructed.

If you don't initialize them in a constructor initializer list they'll be
default constructed, and that's what you're currently experiencing.

The way to avoid that is to use a constructor initializer list. ;-)

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Alfonso Morra]

Alf P. Steinbach wrote:

* Alfonso Morra:

Here is the complete code of an example that I am using to write my
wrapper class:

int main( ) {
SharedAppenderP tr myAppender( new RollingFileAppe nder("myLogFile .log")) ;
myAppender->setName("myApp enderName") ;
std::auto_ptr<L ayout> myLayout = std::auto_ptr<L ayout>(new
log4cplus::Pa tternLayout("%d {%Y-%m-%d %a %H:%M:%S} %-5p [%t]: %m%n"));
myAppender->setLayout( myLayout );
Logger myLogger= Logger::getInst ance("myLoggerN ame") ;
myLogger.addApp ender(myAppende r);
myLogger.setLog Level ( INFO_LOG_LEVEL );
myLogger.log( INFO_LOG_LEVEL, "Info Level Message") ;
myLogger.log( TRACE_LOG_LEVEL , "Trace Level Mesage") ;
}

As you can see, the variables are all local variables that go out of
scope after main has ceased. What I am doing is wrapping up the
functionali ty provided by main, into a wrapper class (lets call this
LogWriter). It is clear from the code above, that I will need variables
(or pointers to objects) of type SharedAppenderP tr, Layout, LogLevel and
Logger at the very least. So armed with these facts, I proced as follows:

class LogWriter {
public:
LogWriter(int,L ogLevel);
virtual ~LogWriter() ;

LogMsg(const string&) ;
setLogLevel(Log Level) ;
...

private:
/* Keep hidden from prying eyes*/
LogWriter(const LogWriter&);
LogWriter& operator=(const LogWriter&);

Presumably this assignment operator is not implemented, and if so, good.

Otherwise, if it's implemented it won't fly if SharedAppenderP tr doesn't
provide an assignment operator.

But it's possible that you just haven't #included the source for that
operator implementation, or not linked with the appropriate object file or
library.

/* Variables */
SharedAppenderP tr m_Appender ; //Default ctor invoked
log4cplus::tstr ing m_AppenderName ;
log4cplus::tstr ing m_LoggerName ;
log4cplus::tstr ing m_logFilename ;
std::auto_ptr<L ayout> m_Layout ; //Default ctor invoked
LogLevel m_lvl ;
Logger m_Logger ; //Default ctor invoked
bool m_debugOn ;

/*Methods */
log4cplus::tstr ing getLogNameByMod uleId( int ) ;

};
Since we have m_Appender, m_Layout and m_Logger already constructed
(default ctors),

Here's the thing: you do not have them already constructed.

If you don't initialize them in a constructor initializer list they'll be
default constructed, and that's what you're currently experiencing.

The way to avoid that is to use a constructor initializer list. ;-)

Ok, two things spring to mind ... my first guess was that the assignment
operator was not implemented but I discounte this straight away because
of the "rule of three". After all, the authors of the library are
experienced C++ programmers - plus because it is open sourced, someone
would have spotted such an oversight straight away.

As you will see from my code comments, I pointted that the variables
will be constructed via their "default ctors". The point which (you
still seem to be missing) is taht there is valuable information passed
to the LogWriter ctor - and I do not have this information at the point
of the declaration/definition of the private variables. So the question
must remain, How do I create (for example), an instance of a
SharedAppender pointer, using the pointer returned by the expression "
new RollingFileAppe nder("myLogFile .log")" ?

This is what I have been trying to find out all along. thanks

[Alf P. Steinbach]

* Alfonso Morra:

The point which (you
still seem to be missing) is taht there is valuable information passed
to the LogWriter ctor - and I do not have this information at the point
of the declaration/definition of the private variables.
As you write, you have it when your LogWriter constructor is called.

So the question
must remain, How do I create (for example), an instance of a
SharedAppender pointer, using the pointer returned by the expression "
new RollingFileAppe nder("myLogFile .log")" ?
Use a constructor initializer list.

This is what I have been trying to find out all along. thanks

Why don't you just try it (and, why haven't you)?

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Howard]

"Alfonso Morra" <sw***********@ the-ring.com> wrote in message
news:dd******** **@nwrdmz03.dmz .ncs.ea.ibs-infra.bt.com...

Here's the thing: you do not have them already constructed.

If you don't initialize them in a constructor initializer list they'll be
default constructed, and that's what you're currently experiencing.

The way to avoid that is to use a constructor initializer list. ;-)

Ok, two things spring to mind ... my first guess was that the assignment
operator was not implemented but I discounte this straight away because of
the "rule of three". After all, the authors of the library are experienced
C++ programmers - plus because it is open sourced, someone would have
spotted such an oversight straight away.

As you will see from my code comments, I pointted that the variables will
be constructed via their "default ctors". The point which (you still seem
to be missing) is taht there is valuable information passed to the
LogWriter ctor - and I do not have this information at the point of the
declaration/definition of the private variables. So the question must
remain, How do I create (for example), an instance of a SharedAppender
pointer, using the pointer returned by the expression " new
RollingFileAppe nder("myLogFile .log")" ?

This is what I have been trying to find out all along. thanks

Having the declaration of an object in your class does _not_ "default
construct" the object. Member objects are constructed at run-time, during
the construction of the object containing them. And you can control that
construction by adding them to an initialization list in your LogWriter
constructor. They are only default constructed if you _don't_ put them in
the initializer list. (And even the, it's during the run-time construction
of an instance of the LogWriter object.) You might want to read up on
initializer lists, especially how they are used for member object and base
class object construction.

Also, if for some reason you _do_ need to create members _after_
construction of the containing object, then make them member pointers, not
member objects, and add appropriate new and delete calls.

One more thing: notice that m_Appender appears to be a pointer. When the
LogWriter object is constructed, no construction takes place of any object
for it unless you write the code to do so (via a call to new), despite your
code comment that it's default constructed at that point.

-Howard

[Alfonso Morra]

Howard wrote:

"Alfonso Morra" <sw***********@ the-ring.com> wrote in message
news:dd******** **@nwrdmz03.dmz .ncs.ea.ibs-infra.bt.com...

Here's the thing: you do not have them already constructed.

If you don't initialize them in a constructor initializer list they'll be
default constructed, and that's what you're currently experiencing.

The way to avoid that is to use a constructor initializer list. ;-)

Ok, two things spring to mind ... my first guess was that the assignment
operator was not implemented but I discounte this straight away because of
the "rule of three". After all, the authors of the library are experienced
C++ programmers - plus because it is open sourced, someone would have
spotted such an oversight straight away.

As you will see from my code comments, I pointted that the variables will
be constructed via their "default ctors". The point which (you still seem
to be missing) is taht there is valuable information passed to the
LogWriter ctor - and I do not have this information at the point of the
declaration/definition of the private variables. So the question must
remain, How do I create (for example), an instance of a SharedAppender
pointer, using the pointer returned by the expression " new
RollingFileAp pender("myLogFi le.log")" ?

This is what I have been trying to find out all along. thanks

Having the declaration of an object in your class does _not_ "default
construct" the object. Member objects are constructed at run-time, during
the construction of the object containing them. And you can control that
construction by adding them to an initialization list in your LogWriter
constructor. They are only default constructed if you _don't_ put them in
the initializer list. (And even the, it's during the run-time construction
of an instance of the LogWriter object.) You might want to read up on
initializer lists, especially how they are used for member object and base
class object construction.

Also, if for some reason you _do_ need to create members _after_
construction of the containing object, then make them member pointers, not
member objects, and add appropriate new and delete calls.

One more thing: notice that m_Appender appears to be a pointer. When the
LogWriter object is constructed, no construction takes place of any object
for it unless you write the code to do so (via a call to new), despite your
code comment that it's default constructed at that point.

-Howard

For some reason, its all begining to make sense to me now. Although you
are saying pretty much what Alf said earlier, possibly, it was your more
verbose explanation that rammed the message home. Many thanks to both of
you. I believe I have enough insight now to tackle the problem. Thanks

[Alfonso Morra]

Howard wrote:

"Alfonso Morra" <sw***********@ the-ring.com> wrote in message
news:dd******** **@nwrdmz03.dmz .ncs.ea.ibs-infra.bt.com...

Here's the thing: you do not have them already constructed.

If you don't initialize them in a constructor initializer list they'll be
default constructed, and that's what you're currently experiencing.

The way to avoid that is to use a constructor initializer list. ;-)

Ok, two things spring to mind ... my first guess was that the assignment
operator was not implemented but I discounte this straight away because of
the "rule of three". After all, the authors of the library are experienced
C++ programmers - plus because it is open sourced, someone would have
spotted such an oversight straight away.

As you will see from my code comments, I pointted that the variables will
be constructed via their "default ctors". The point which (you still seem
to be missing) is taht there is valuable information passed to the
LogWriter ctor - and I do not have this information at the point of the
declaration/definition of the private variables. So the question must
remain, How do I create (for example), an instance of a SharedAppender
pointer, using the pointer returned by the expression " new
RollingFileAp pender("myLogFi le.log")" ?

This is what I have been trying to find out all along. thanks

Having the declaration of an object in your class does _not_ "default
construct" the object. Member objects are constructed at run-time, during
the construction of the object containing them. And you can control that
construction by adding them to an initialization list in your LogWriter
constructor. They are only default constructed if you _don't_ put them in
the initializer list. (And even the, it's during the run-time construction
of an instance of the LogWriter object.) You might want to read up on
initializer lists, especially how they are used for member object and base
class object construction.

Also, if for some reason you _do_ need to create members _after_
construction of the containing object, then make them member pointers, not
member objects, and add appropriate new and delete calls.

One more thing: notice that m_Appender appears to be a pointer. When the
LogWriter object is constructed, no construction takes place of any object
for it unless you write the code to do so (via a call to new), despite your
code comment that it's default constructed at that point.

-Howard

Many Thanks Howard (and Alf), I finally solved it (yes - by using
initializer lists). Makes for some pretty terse looking statements - but
it works !

Many thanks for your expertise and patience !