The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
Finally someone said what I felt. I ended up making my own way simpler logger than using the prebuilt ones. They were supposed to be easy, but no, you have to spend way too much time on learning their API and structure.
Nothing is wrong with that "at the most basic level", but when you're in a heavily multithreaded/concurrent/async/parallel environment with extreme demands for low latency and high throughput, you need a logging system that doesn't negatively affect the required functionality of the application, doesn't block anything, and doesn't garble data due to likely concurrent logging resource access.
As your basic example is written, it will surely "work" for most simple desktop user scenarios where the time it takes for the user to make a mouse click is 10 times higher than the time to complete a call to Logger::Info(), and nothing complicated is happening concurrently.
That said, it would *never* work in a game, in a VoIP app, in a high-grequency stock trading app.
Time you enjoy wasting is not wasted time - Bertrand Russel
What happens when you start the second instance of the program? What happens when you run it as a service? How do you look at the log remotely, while the program is running locally?
Windows already has event logging that work well, using WMI. Remotely accessible, fits in with enterprise operations management frameworks, no file droppings in local directories, no need to reinvent the wheel.
Log4Net et al. are solutions that fit problems when logging expands to larger enterprise systems. Silly log files quickly break down when complexity increases.
Funny co-incidence! I _just_ got done dealing with existing log4net code that wasn't set up to work with multiple threaded entities (the way it was being used in our project) ...so my choices were to:
1) learn the overly complex log4net API and add add even more external dependencies to our several DLLs that were using it
2) write about 30 lines of code to create a thread safe generic logging API that did the same thing
...I saved a bunch of time and removed an external dependency by going with option 2
The problem really isn't with the logger, but with the documentation (and I'm including article here on CodePRoject in that).
For log4net (and for most other loggers, and most add-in libraries in general for that matter), there are:
- things you do every time you want to log something.
- things you do once for every class which logs something.
- things you do once for each application which logs something.
- things you do once in your lifetime.
To understand how you use the logger, they should be explained in that order -- the thing you do the most taught first and with the most text.
However, most go with a chronologic order -- exactly the reverse -- so you are bogged down with pages & pages of "configuration" documentation --- which in a real application will result one line of code.
I think its been mentioned before but this is ok if you have a single thread running. Any GUI based app with more than the main thread is going to be problematic. Loggin shouldn't be wasting time on the main thread running the program. You should wrap up a logging task, then fire it off onto another thread and forget about it. It can take ages (relatively) to open a file and append a log entry to it. And if you use locking (mutex) to make sure logging is thread safe, then all the threads wanting to log, end up waiting etc.
Then there is the problem of multiple teams/modules writing to the log. It's nice to filter/partition log entries etc. Or use colour coding (then you need a log file reader !)
So at home on my robotics projects (www.roboticsfordreamers.com) I use a simple - file open and writer - for simple projects (I always use small simple programs linked together with 0MQ anyway, so logging is always on a separate single thread !)
I do agree though, that mostly this area is over-engineered, the people who look after these projects see them as in need of improving with additional functionality. What is nice, is when you have two approaches you can use in a software system. The super fast, lightweight, low functionality solution, and the complete bells and whistles solution. Maybe software (especially SDKs) should be developed in this way, then users can chose the trade off between functionality and speed.
Well, I enjoyed all the Terry Pratchett books.
And I think David Eddings is a good author as well.
But I'd avoid all of Dan Brown's output: he writes a short story into 600 pages.
As far as autobiographies go, Ranulph Fiennes is a professional lunatic, and Carrie Fisher was an addict - but they both wrote well (even if Carrie's books seemed rather short). And if you can get hold of a copy of Brian Shul's "Sled driver - flying the World's Faster Jet" then that's well worth a read.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
a senior developer would be able to come up with a few without asking...
I was wondering many times most of our mentors, the way of answering for a questions in codeproject or stact overflow. Its inspired me, I would like to become them (technically).So I eagerly looking forward for some guidance.