Re: Logging
On Nov 15, 6:26 am, Andrea Crotti <andrea.crott...@gmail.com> wrote:
=D6=F6 Tiib <oot...@hot.ee> writes:
It looks like Log::ReportingLevel() is declared in header but it is
nowhere defined so linker does not find it.
Sure but in that example it was not declared somewhere else, and
- if I do everything in a .cpp file, I can't find the definition of the
class
- if I add a definition like
TLogLevel& Log::ReportingLevel() {
return logERROR;
}
in the .cpp file I get
Log.cpp: In static member function =91static TLogLevel& Log::ReportingL=
evel()':
Log.cpp:18: error: invalid initialization of non-const reference of typ=
e =91TLogLevel&' from a temporary of type =91TLogLevel'
Return a reference to a static variable.
What I really don't get is why he's using a function
(assigning it to something) instead of just a static
variable... What is the gain?
Managing order of initialization. If the constructor of
a static variable uses your logging facility, it might find that
the variable has not been initialized.
Of course, with an enum type like this, it doesn't matter.
A static variable would be initialized with logERROR. But the
function still allows initialization with any arbitrary default.
Not sure. It is not forbidden to write "private: private: private:" so
it is up to designer of class.
I usually organize my classes in the way that public section is first,
then comes protected and finally private.
Some have the sections sliced and slices of sections intermixed and so
when later reorganizing them then some slices with same access remain
adjacent. That is perhaps a mess, but mind of most people is a mess
most of the time.
Other reason may be style. For example designer views public type/
constant/enumerator definitions as one section and public member
declarations as other section. The redundant "public:" serves then for
visually separating the two sections.
Well I could understand if you write the multiple "public:" in
different places. It hides what's really public in the class
but well it's a different layout.
But what sense does it make to do
public:
...
...
public:
....
I normally just use an empty line to divide those parts, it's not
enough?
It doesn't change anything with regards to the compiler. If the
class is logically divided into separate sections, however, it
might make sense to respecify access for each section. I've
often duplicated private: this way, e.g.:
class Toto
{
// ...
private: // virtual functions...
virtual void f() = 0;
// ...
friend class Titi;
private: // Except for Titi...
// ...
private: // really
// ...
};
Obviously, Titi can also access "private: // really". The
comments specify intent, and are not in any way enforced by the
compiler. But somehow, I find this clearer in presentation.
--
James Kanze