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:

SharedAppenderPtr myAppender( new RollingFileAppender("MyAppender"))


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:
SharedAppenderPtr m_Appender ;

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

.....
m_Appender = new RollingFileAppender(log_file_name)
.....


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(dllimport)
public: class log4cplus::helpers::SharedObjectPtr<class
log4cplus::Appender> & __thiscall
log4cplus::helpers::SharedObjectPtr<class
log4cplus::Appender>:perator=(class log4cplus::Appender *)"
(__imp_??4?$SharedObjectPtr@VAppender@log4cplus@@@helpers@log4cplus@@QAEAAV012@PAVAppender@2@@Z)
referenced in function "public: __thiscall Auditor::Auditor(int,int)"
(??0Auditor@@QAE@HH@Z)



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

MTIA

 

[Alf P. Steinbach]

* Alfonso Morra:

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

....
m_Appender = new RollingFileAppender(log_file_name)
....

Don't. Use a constructor initializer list. Initialization is not
assignment.

 

[Alfonso Morra]

* Alfonso Morra:



Don't. Use a constructor initializer list. Initialization is not
assignment.

I thoink you're missing the point I'm making. TThe point being this: The
private variable is declared somewhere else (meaning default construct
is invoked). THEN I have to create an instance using the parameters
passed in the constructor. One way round this may be to declare ptrs
return pointers to the objects instead of the objects themselves - just
a guess, I would like to hear from a more experienced C++ person though,
if this is a good way to overcome this issue.

 

[Alf P. Steinbach]

* Alfonso Morra:

I thoink you're missing the point I'm making. TThe point being this: The
private variable is declared somewhere else (meaning default construct
is invoked).

Either it's a member variable, or not. If it isn't, make it one. When it
is a member variable, it's only default constructed if you don't initialize
it in a constructor initializer list.

I would like to hear from a more experienced C++ person though,
if this is a good way to overcome this issue.

You already got that.

 

[Alfonso Morra]

* Alfonso Morra:



Either it's a member variable, or not. If it isn't, make it one. When it
is a member variable, it's only default constructed if you don't initialize
it in a constructor initializer list.

I have no doubt that you know what you're talking about. But honestly,
how does a comment such as the one help me to solve my problem?. What I
want to know, is a practical way to solve the problem - possibly, a one
line or two line code/pseudocode segment that show me how to solve the
problem, not generalized theories or rules from the C++ book (as other
people have tended to do). Sure, this may be asking a lot, but if you
don't have the time to answer my "basic questions", then please simply
don't reply to my posts.

You already got that.

Hear we go with the ego again (sigh) ...

 

[Howard]

I thoink you're missing the point I'm making. TThe point being this: The
private variable is declared somewhere else (meaning default construct is
invoked). THEN I have to create an instance using the parameters passed in
the constructor. One way round this may be to declare ptrs return pointers
to the objects instead of the objects themselves - just a guess, I would
like to hear from a more experienced C++ person though, if this is a good
way to overcome this issue.

I don't understand what you're saying.

1) You say "the private variable is declared somewhere else". It's a
pointer, declared as a member, right?

2) Whose "default construct" is invoked?

3) And THEN you have to create an instance....of what? If you're creating
an instance of the wrapper, using the parameters passed in its constructor,
then why can't you have an initializer list in that constructor, and create
your member object there?

4) This part I _really_ don't understand: "...to declare ptrs return
pointers to the objects instead of the objects themselves". What's "ptrs"?
What objects? And who's returning something?

5) Perhaps if you showed more of the actual code you're using, we could
figure out where you're doing what, and what might be missing or wrong.
Your one-line code samples and (somewhat vague) descriptions really aren't
giving us enough information.

-Howard

 

[Shezan Baig]

Auditor error LNK2019: unresolved external symbol "__declspec(dllimport)
public: class log4cplus::helpers::SharedObjectPtr<class
log4cplus::Appender> & __thiscall
log4cplus::helpers::SharedObjectPtr<class
log4cplus::Appender>:perator=(class log4cplus::Appender *)"
(__imp_??4?$SharedObjectPtr@VAppender@log4cplus@@@helpers@log4cplus@@QAEAAV012@PAVAppender@2@@Z)
referenced in function "public: __thiscall Auditor::Auditor(int,int)"
(??0Auditor@@QAE@HH@Z)



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

MTIA

Sounds like there is a bug in the library you are using. From the
error
message, it looks like the "log4cplus::helpers::SharedObjectPtr" class
declares an assignment operator, but never defines it. Either that, or
you are not linking the correct libraries. You should probably contact
whoever maintains this library and ask them for help.

-shez-

 

[Alf P. Steinbach]

* Alfonso Morra:

I have no doubt that you know what you're talking about. But honestly,
how does a comment such as the one help me to solve my problem?

You could try it out -- that's what I and others expect.

You should put in some effort yourself, such as at least trying.

What I
want to know, is a practical way to solve the problem - possibly, a one
line or two line code/pseudocode segment that show me how to solve the
problem, not generalized theories or rules from the C++ book (as other
people have tended to do). Sure, this may be asking a lot, but if you
don't have the time to answer my "basic questions", then please simply
don't reply to my posts.

Don't fear, I even help folks who badmouth their helpers instead of trying
anything on their own.

Here's an example of a class using a constructor initializer list instead of
assignment:

class Point
{
private:
int myX;
int myY;
public:
Point( int x, int y ): myX( x ), myY( y ) {}
// other member functions
};

Now try that out, and post some code if you can't get it to work.

 

[Adrian]

I have done the ff:

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

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

....
m_Appender = new RollingFileAppender(log_file_name)
....

Assuming your wrapper class is named SharedAppenderPtrWrapper you should
initialize m_Appender as bellow:

class SharedAppenderPtrWrapper
{
SharedAppenderPtr m_Appender ;
/*other members*/
public:
SharedAppenderPtrWrapper(const char *log_file_name) :
m_Appender(new RollingFileAppender(log_file_name)), -->call it's
constructor instead of calling the assignment operator
/*other initializers*/
{
/*other init code*/
}
/*other methods*/
};

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(dllimport)
public: class log4cplus::helpers::SharedObjectPtr<class
log4cplus::Appender> & __thiscall
log4cplus::helpers::SharedObjectPtr<class
log4cplus::Appender>:perator=(class log4cplus::Appender *)"
(__imp_??4?$SharedObjectPtr@VAppender@log4cplus@@@helpers@log4cplus@@QAEAAV0
12@PAVAppender@2@@Z)
referenced in function "public: __thiscall Auditor::Auditor(int,int)"
(??0Auditor@@QAE@HH@Z)

This may be a name resolution issue specific to MSVC since the classes
appear to be in different namespaces.

 

[Alfonso Morra]

* Alfonso Morra:



You could try it out -- that's what I and others expect.

You should put in some effort yourself, such as at least trying.





Don't fear, I even help folks who badmouth their helpers instead of trying
anything on their own.

Here's an example of a class using a constructor initializer list instead of
assignment:

class Point
{
private:
int myX;
int myY;
public:
Point( int x, int y ): myX( x ), myY( y ) {}
// other member functions
};

Now try that out, and post some code if you can't get it to work.

Didn't mean to get up your nose Alf, and sorry about all the typos,
which probably didn't help my case much either. I am familiar with
constructor initializer list but they won't help (at least I can't see
how they can) in this case.

I am wrapping up the wonderful log4cplus code into a more managable
class. However, there is no documentation (the documentation is the
code) and I am using a provided example as the base of my wrapper class.

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

int main( ) {
SharedAppenderPtr myAppender( new RollingFileAppender("myLogFile.log")) ;
myAppender->setName("myAppenderName") ;
std::auto_ptr<Layout> myLayout = std::auto_ptr<Layout>(new
log4cplus:atternLayout("%d{%Y-%m-%d %a %H:%M:%S} %-5p [%t]: %m%n"));
myAppender->setLayout( myLayout );
Logger myLogger= Logger::getInstance("myLoggerName") ;
myLogger.addAppender(myAppender);
myLogger.setLogLevel ( 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 SharedAppenderPtr, Layout, LogLevel and
Logger at the very least. So armed with these facts, I proced as follows:

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

LogMsg(const string&) ;
setLogLevel(LogLevel) ;
...

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

/* Variables */
SharedAppenderPtr m_Appender ; //Default ctor invoked
log4cplus::tstring m_AppenderName ;
log4cplus::tstring m_LoggerName ;
log4cplus::tstring m_logFilename ;
std::auto_ptr<Layout> m_Layout ; //Default ctor invoked
LogLevel m_lvl ;
Logger m_Logger ; //Default ctor invoked
bool m_debugOn ;

/*Methods */
log4cplus::tstring getLogNameByModuleId( int ) ;

};


Since we have m_Appender, m_Layout and m_Logger already constructed
(default ctors), I need to know how to "re-create" (for lack of a better
word, so that I can use the variables passed to the ctor of LogWriter. I
(obviously) can't use the code in the example above main() function
verbatim and copy into the ctor of LogWriter, becaue all the variables
will be local to the ctor and after the ctor went out of scope, so will
be the local variables (local to LogWriter::LogWriter()) and all the
private variables will be left unitialised, or at ;least initialised
with values other than that speciifed in the constructor.

So my question then was (and is): how can I initialise my LogWriter
class so that the private variables are assigned the values passed in
the LogWriter ctor? (basically, all I want to do is to replicate the
functionality I havce provided in my main function above.

Armed with some (hopefully more useful information), I hope you will be
able to shed some light on how to solve this - it is not for the lack of
trying, I can assure, you.

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( ) {
SharedAppenderPtr myAppender( new RollingFileAppender("myLogFile.log")) ;
myAppender->setName("myAppenderName") ;
std::auto_ptr<Layout> myLayout = std::auto_ptr<Layout>(new
log4cplus:atternLayout("%d{%Y-%m-%d %a %H:%M:%S} %-5p [%t]: %m%n"));
myAppender->setLayout( myLayout );
Logger myLogger= Logger::getInstance("myLoggerName") ;
myLogger.addAppender(myAppender);
myLogger.setLogLevel ( 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 SharedAppenderPtr, Layout, LogLevel and
Logger at the very least. So armed with these facts, I proced as follows:

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

LogMsg(const string&) ;
setLogLevel(LogLevel) ;
...

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 SharedAppenderPtr 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 */
SharedAppenderPtr m_Appender ; //Default ctor invoked
log4cplus::tstring m_AppenderName ;
log4cplus::tstring m_LoggerName ;
log4cplus::tstring m_logFilename ;
std::auto_ptr<Layout> m_Layout ; //Default ctor invoked
LogLevel m_lvl ;
Logger m_Logger ; //Default ctor invoked
bool m_debugOn ;

/*Methods */
log4cplus::tstring getLogNameByModuleId( 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. ;-)

 

[Alfonso Morra]

* Alfonso Morra:

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

int main( ) {
SharedAppenderPtr myAppender( new RollingFileAppender("myLogFile.log")) ;
myAppender->setName("myAppenderName") ;
std::auto_ptr<Layout> myLayout = std::auto_ptr<Layout>(new
log4cplus:atternLayout("%d{%Y-%m-%d %a %H:%M:%S} %-5p [%t]: %m%n"));
myAppender->setLayout( myLayout );
Logger myLogger= Logger::getInstance("myLoggerName") ;
myLogger.addAppender(myAppender);
myLogger.setLogLevel ( 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 SharedAppenderPtr, Layout, LogLevel and
Logger at the very least. So armed with these facts, I proced as follows:

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

LogMsg(const string&) ;
setLogLevel(LogLevel) ;
...

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 SharedAppenderPtr 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 */
SharedAppenderPtr m_Appender ; //Default ctor invoked
log4cplus::tstring m_AppenderName ;
log4cplus::tstring m_LoggerName ;
log4cplus::tstring m_logFilename ;
std::auto_ptr<Layout> m_Layout ; //Default ctor invoked
LogLevel m_lvl ;
Logger m_Logger ; //Default ctor invoked
bool m_debugOn ;

/*Methods */
log4cplus::tstring getLogNameByModuleId( 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 RollingFileAppender("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 RollingFileAppender("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)?

 

[Howard]

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
RollingFileAppender("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]

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]

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 !