Member Discussions

my_log(my_log.DEBUG) << "Server::NewUser" << "Greet" << "Unable to greet socket " << newsock.id() << ctl::END;

// Alternative syntax, calls are equivalent
my_log.debug() << "Server::NewUser" << "Greet" << "Unable to greet socket " << newsock.id() << ctl::END;

template <class ProcessingModel>
class InputModel: public ProcessingModel
...

#include "default_log.h"

// Creating a default log object
st_log_type my_log("info");

// Creating a critical-messages-only log object
// 'log' is the facade for the entire collection of Models,
// 'single_queue' is InputModel, 'direct' is OutputModel,
// 'formatting' is ProcessingModel, 'log_base' is BaseModel
// and ctl::CRITICAL defines the minimum priority level.
mesh::elflog::log<single_queue<direct<formatting<log_base<> > >, ctl::CRITICAL> > c_log("critical");

my_log.channel(std::cerr);

<< Inform  >>   11:51:34 28.07.03  [Network::Server .:. TCPIPModel::Constructor]
                -- The protocol model has been initialized. This text is here just
                   to show how the text can (and will) be formatted. As you may
                   notice, the idea is to have a line length and an offset from
                   the beginning of the line.

// &e3;     -- Maximum of 3 arguments (any extra ones appended to 3rd)
// &a0..2;  -- Put argument number 0, 1, 2 here
// &k ;     -- A 'konstant', a single space character  
my_log.format("&e3;&a0;&k ;&a1;&k ;&a2;");

// my_log.debug() invokes the logger
// Arguments are passed like to std::cout with op<<
// ctl::END means the end of the message, flush the buffer (like std::endl)
my_log.debug() << "Your hp: " << char.hp() << ctl::END;

// This message is 'NEGLIGIBLE' (notice the function is lowercase)
my_log.negligible() << "Blah blah blah...

// So is this (notice the parm is uppercase)
my_log(my_log.NEGLIGIBLE) << "Blah blah blah...

// Bring into view
#include "default_log.h"
...

// Create a log object
st_log_type logger("info");
...

// Use it
logger.negligible() << "Network::Server"
                    << "TCPIPServer::Shutdown"
                    << "The server exploded! Approximately "
                    << CalculateCasualties(sys::EXPLOSION)
                    << " dead or injured!"
                    <<ctl::END
...

The actual feature set seems pretty nice, though, on the condition that you add all sorts of insane logging output models at some point.

  logger l;
  l.add_output(new ostream_output());
  l.add_output(new filter_output(ERROR,
               new ostream_output(new default_format("%{0} --> %{1}"))));
  l << "abc" << "def" << logger::end; // written as rubbish
  l(ERROR) << "Not enough templates!" << logger::end; // error

[Sun Jul 18 20:53:49 2004 RUBBISH] abcdef
[Sun Jul 18 20:53:49 2004 ERROR] Not enough templates!
ERROR --> Not enough templates!

struct point {
  point(int a_x, int a_y): x(a_x), y(a_y) {}
  int x;
  int y;
};

ostream &operator<<(ostream &lhs, const point &rhs) {
  lhs << "(" << rhs.x << ", " << rhs.y << ")";
  return lhs;
}

int main(int argc, char **argv) {
  logger<> global_log;
  ofstream outfile("my_log.txt", ios::app);
  // All messages get sent to stdout
  global_log.add_output(new ostream_output());
  // Info and higher gets sent to my_log.txt
  global_log.add_output(new filter_output(logger_base::INFO,
                        new ostream_output(new default_format(), outfile)));
  // Errors get sent to localhost:10000. We initialize this one last
  // so we have somewhere to send the error
  try {
    global_log.add_output(new filter_output(logger_base::ERROR,
                          new network_output("localhost", 10000)));
  } catch (ufx::networkConnectionError &e) {
    global_log(logger_base::ERROR) << "Can't connect to logging host.";
  }
  global_log() << "This text is completely superfluous"; // defaulted
  global_log(logger_base::ERROR) << "Network logging for errors";
  global_log(logger_base::INFO) << "This is some information. Yeah.";
  // Also defaulted
  global_log << "to_str uses ostringstream. Observe: " << point(3,2) << ".";
  { // We can accumulate the long way
    log_accum a(global_log, logger_base::INFO);
    a << "Foo ";
    a << "Bar ";
    a << "Baz ";
  }
}

Not only do I gripe at the mass amount of templates (all C++ programmers should know about templates and compiler errors/warnings), --

I guess I just wonder about the overall design. It looks like a logger, it acts like a logger, but the code makes me wonder if the logger's design has a bit more functionability that is really worthwhile to the common programmer.

Using the ufxlib network routines I could add network logging in about 30 lines of code.

As for defensiveness: the only problem I have with the logger is that oversized code really irks me; there are a lot of excellent libraries that I don't like using just because they're too large.

Oh yes, one more thing I didn't see any way to accomplish with elflog: sending output from one logger to multiple destinations.

multithreading?

That is the one thing that kills about this logger. While it is of some convience, I almost wonder if that is streching the purpose of a logger.

the compiler will completely optimize away any log invocations that are below the defined logging level, which I consider to be a really nice feature for debugging.

Really? Out of curiosity, did you intentionally design this, or is this a compiler trick?

I guess my view of C++ templates is that they are really esoteric features of C++. Most C++ programmers I know are comfortable using the STL, using templates to parameterize types and constructing function objects. However beyond that I know very few C++ programmers that go into the abstractions of concepts, modeling and refinement.

That might be another interesting discussion. How people really approach solving problems.

std::string trace() {
  void *funcs[1024];
  std::string result;
  char **res_c;
  int i;
  i = backtrace(funcs, 1024);
  res_c = backtrace_symbols(funcs, i);
  if (res_c == NULL)
    return "<BACKTRACE UNAVAILABLE>";
  for (int j = 0; j < i; ++j) {
    result.append(res_c[j]);
    result.append("\n");
  }
  free(res_c);
  return result;
}

./a.out(_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_c+0x164) [0x804a564]
./a.out(strftime+0xb30) [0x804ac20]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xfa) [0x401237da]

Setting up multiple output models using compile time polymorphism (just in case you're wondering, I did not mean output to multiple streams, I meant output to multiple models) would be an excruciating exercise in Alexandrescuism, and I'm not sure how you would do it with traditional methods in your framework, because everything is resolved at compile time. Please enlighten me.

Everything doesn't have to be resolved compile-time. Outputting to multiple models is simple; just create a new model that can aggregate an arbitrary amount of simple models and iterate.

Furthermore, it is not "completely" optimized away -- the log arguments are still evaluated, even if the actual logging is optimized out.

Not necessarily; even the argument evaluation can be optimized out -even a function, particularly if it only uses local variables and returns a value.

Granted, generally I wouldn't put a log statement in a performance-critical section either (more likely just before and after).

Now this is not really a very expensive function, so I wasn't going to use it as an example, but I tried plugging it into your logger and the formatter hung, used all my memory and crashed.

Where did you plug it in? Did you just run it as a part of a statement or did you put it in the internals? I'll certainly check it out.

That [templates] obfuscate code is nearly undeniable.

I'd like to deny that. The only obfuscation, when templates are being used properly, comes from unfamiliarity.

.

The problem is that your models are not polymorphic at runtime.

In a log statement. Just "./" also did the trick. Actually, a . followed by any non-valid_eol character seems to do it. It was the paragraph-formatted argument. Also, you might want to consider not using a ^ delimiter internally - or at least document it =)

Policy classes are one thing that I really don't like, not because it's a bad idea but because C++ doesn't provide adequate facilities for expressing their relations and ensuring their correctness.

-- is single_queue supposed to be thread safe or not? If not, why does _queue_mutex exist? If so, forgetting the ctl::END token will result in the mutex never being unlocked, which of course will create interesting bugs at essentially arbitrary locations.

There is if you're going to aggregate arbitrary, heterogenous models at runtime.

C++ does not provide adequate facilities for expressing these relations to the programmer. Inheritance through a template parameter, for example, provides no information on the expected signature of said parameter.

Furthermore, this sort of inheritance often completely breaks the normal is-a relationship normally associated with inheritance.

Obviously it will only occur the next time the logger is called, but that could be anywhere in a multithreaded system.

There's need for polymorphism, yes, but the models need not exhibit such so long as the combining container does. A naive implementation would simply have a PolymorphicOutputFunctor class subclassed for each type (which should be simple since the interface needs to be the same).

There is absolutely nothing "simple" about that. Try it out sometime. If it's more than 0 lines of code, it's not simple, because it should be completely unnecessary.

Loosely typed and untyped languages don't generally have this sort of subtyping problem, for reasons which should be painfully obvious. Inheritance from Object is completely unrelated and I have no idea why you brought it up.

Policy inheritance tends to produce unconventional inheritance. Put simply, it is "backwards". Saying that some type is a subtype of every type (which is basically what you're doing when you inherit from an unconstrained template parameter) is, well, unconventional. And wrong (as your compiler will tell you very verbosely if instantiated with an incompatible type).

What is your reasoning behind policy-based design discouraging unusual inheritance? Your own logger design is a pretty solid example of the exact opposite.

class output_base {
public:
  virtual bool write_output(logger_base::log_level level,
                            logger_base::arg_list &args) = 0;
  virtual ~output_base() {}
};