After my introduction to logging it became clear to me that I needed to improve the initial ideas. As a process, the enhancements couldn't be achieved all at once, but gradually, step by step, according to the Natural laws :-) More specifically, I tried to address points 1, 2 and 4 from my initial attempt.
A new abstract type is to provide a general interface for all kinds of logging devices, not only file-system as firstly attempted. With this in mind, a log just need to be opened, written-to and finally closed when done. I tried to reflect such a model as shown next.
Wednesday, May 17, 2017
Tuesday, May 16, 2017
A CSS styling tool
I've been writing some code for my blog posts and every time I need to insert some excerpts of these codings it's a somewhat painful task to format it the precise way I'd like to. So I reached a threshold point where it would be worthy to set aside some time to look for some tool to help me achieve my goal. Fortunately, NetBeans, the IDE I've been using more frequently leads me half-way to where I want, by providing a Print to HTML... option:
But, unfortunately, this option does a nice job that goes beyond what I need. And the problem is that by going beyond it turns itself useless to address my current needs. It's true that it offers a tiny bit of flexibility:
But it is insufficient. The problem is that the syntax-highlighting is formatted via CSS internal styles of type text/css within a HTML comment within the well-known <style> tag. What is supposed to reflect the syntax-highlighting is within <span> tags of specific classes. Hence, I can't use it like that (not even portions of it) right away here in Blogger as I want:
<!DOCTYPE ... >
<html>
<head>
<title>framework.hxx</title>
<meta ... >
<style type="text/css">
<!--
body {...}
pre {...}
table {...}
.highlight-caret-row {...}
.ST1 {...}
.preprocessor {...}
.comment {...}
.literal {...}
.pragma-omp-keyword-directive {...}
.ST0 {...}
-->
</style>
</head>
<body>
...
11 <span class="literal">virtual</span>
~<span class="ST1">file</span>() {}
...
That is, not even portions of the above produce:
(unless with a completely inviable bit-by-bit editing)
But, unfortunately, this option does a nice job that goes beyond what I need. And the problem is that by going beyond it turns itself useless to address my current needs. It's true that it offers a tiny bit of flexibility:
But it is insufficient. The problem is that the syntax-highlighting is formatted via CSS internal styles of type text/css within a HTML comment within the well-known <style> tag. What is supposed to reflect the syntax-highlighting is within <span> tags of specific classes. Hence, I can't use it like that (not even portions of it) right away here in Blogger as I want:
<!DOCTYPE ... >
<html>
<head>
<title>framework.hxx</title>
<meta ... >
<style type="text/css">
<!--
body {...}
pre {...}
table {...}
.highlight-caret-row {...}
.ST1 {...}
.preprocessor {...}
.comment {...}
.literal {...}
.pragma-omp-keyword-directive {...}
.ST0 {...}
-->
</style>
</head>
<body>
...
11 <span class="literal">virtual</span>
~<span class="ST1">file</span>() {}
...
That is, not even portions of the above produce:
(unless with a completely inviable bit-by-bit editing)
11 virtual ~file() {}
Thursday, May 11, 2017
Logging - Basics #1
Logging is an important aspect of computer science as it provides a way of tracing back exactly or approximately to some degree what have happened in relation to a certain computation in-between a certain time interval. Of course there are many kinds of log with respect to what, where and how the operation is done and what, where and how its results are archived for later retrieval and analysis. This definition should suffice for a quick startup :-)
Depending on the system there may be different kinds of logging support and facilities but I don't know of a single system that doesn't provide at least one kind of logging per each of its subsystems. But that is of course strongly platform dependent, thus not easily or possibly portable. Because of this it is generally useful for an application (or program) to also plan its own logging features that will work across any platform it supports.
On this post I present one very simple solution consisting on a mixed strategy of encapsulating an old-style (C) logging in a C++ object. It's definitely not a final and optimal solution. There is a long way to perfect it, but nevertheless it's a start. As having traces of an old-style logging it suffers from typical problems from the past related to the care that must be taken with respect to printf-like functions and its formatting strings and respective variadic parameters. As being a helper C++ concrete object the logging interface could be more elaborated and generalized by a new interface layer consisting of an abstract C++ class factoring out the most fundamental aspects of logging. But for now it's just as it is, and it works despite of these main deficiencies.
The implementation here is target at a 64-bit Unix system but it should be easily ported to another platform such as a Windows system. The log is recorded to a standard line-oriented file where each record begins with a simple timestamp marker. Each line is "freely" composed by means of an encapsulated standard C printf-like call. Let's see how...
Depending on the system there may be different kinds of logging support and facilities but I don't know of a single system that doesn't provide at least one kind of logging per each of its subsystems. But that is of course strongly platform dependent, thus not easily or possibly portable. Because of this it is generally useful for an application (or program) to also plan its own logging features that will work across any platform it supports.
On this post I present one very simple solution consisting on a mixed strategy of encapsulating an old-style (C) logging in a C++ object. It's definitely not a final and optimal solution. There is a long way to perfect it, but nevertheless it's a start. As having traces of an old-style logging it suffers from typical problems from the past related to the care that must be taken with respect to printf-like functions and its formatting strings and respective variadic parameters. As being a helper C++ concrete object the logging interface could be more elaborated and generalized by a new interface layer consisting of an abstract C++ class factoring out the most fundamental aspects of logging. But for now it's just as it is, and it works despite of these main deficiencies.
The implementation here is target at a 64-bit Unix system but it should be easily ported to another platform such as a Windows system. The log is recorded to a standard line-oriented file where each record begins with a simple timestamp marker. Each line is "freely" composed by means of an encapsulated standard C printf-like call. Let's see how...
Saturday, May 6, 2017
Studio under Solaris
I already talked about NetBeans under Solaris which is great together with GCC, but even greater is the Solaris / Developer Studio and its native optimizing compiler and tools. By the time of this writing the current version is 12.5 (developerstudio-125 is the pkg5 name) which by now (finally!) virtually includes full (regression: locales don't work!) support to C++ 11 and already some selected features of C++ 14.
Appart from the lenghty download from the Oracle public release Internet repository, my installation notes on the links above present some more powerful considerations that the graphical Package Manager cannot offer, so check it out!
NOTE
Appart from the lenghty download from the Oracle public release Internet repository, my installation notes on the links above present some more powerful considerations that the graphical Package Manager cannot offer, so check it out!
NOTE
NOTEThe public release Internet address is https://pkg.oracle.com/solarisstudio/release but you'll only be able to access if you first register at http://pkg-register.oracle.com/ and later generate a PKCS12(1openssl) a.k.a. a PFX file to install on your browser.
After launching Solaris / Developer Studio for the very first time, it may be convenient to adjust the default project folder much the same as its done for NetBeans. Instead of looking for the projectui.propeties file at ~/.netbeans, do so at ~/.solstudio or ~/.oracledevstudio.
Monday, May 1, 2017
Formatting issues
Stream formatting is very cool in C++ but with the power and flexibility comes the complexity. It's true that many limitations of the traditional C-style I/O were addressed by the streams framework and new I/O operators (put-to and get-from), manipulators and much more. But that didn't happen on a blink-of-an-eye. It's been evolving since many years, sometimes being completely revamped. A sad legacy is that in some (or many?) circumstances, backward compatibility takes precedence over some "fixes" or adjustments. Then it's not rare to have to carry on with some old "misbehavior" at some corners.
For example, consider the following output:
(I could argue that it has "unexpected" behavior; disregard the "[" and "]")
Formatting flags ... // OK
*******Hello, there! // OK; better if left aligned
Number 1: .........e // OK
Number 2: c^^^ // "Should be" [12^^]
Number 3: 14 // "Should be" [20]
Floating 1: 8.33^^^^^^ // "Should be" [ 8.33]
Floating 2: 1.83 // "Should be" [ 1.83]
Floating 3: 3.33^^^^^^ // "Should be" [ 3.333]
Going home...^^ // "Should be" [**Going home...]
I mean "should be" assuming that:
But as you can see that's not the case and there's no even a "congruent misbehavior". Some member functions and manipulators (fill(), hex, left) permanently change behavior, others (width(), setw()) temporarily override, yet others misbehave strangely as precision (which should affect only how many decimal places to use and not the integral part as well!). In essence each situation is very simple, but when mixed on code, things can become quickly strange, perhaps a nightmare. A programmer can become quickly stressed and choose a less than optimal quick way out! But that's bad in the long run; that's not quality programming. Even the most simple programs such as rc-03 or the one listed below (which generated the above output) can face such annoyances when trying to print formatted output.
For example, consider the following output:
(I could argue that it has "unexpected" behavior; disregard the "[" and "]")
Formatting flags ... // OK
*******Hello, there! // OK; better if left aligned
Number 1: .........e // OK
Number 2: c^^^ // "Should be" [12^^]
Number 3: 14 // "Should be" [20]
Floating 1: 8.33^^^^^^ // "Should be" [ 8.33]
Floating 2: 1.83 // "Should be" [ 1.83]
Floating 3: 3.33^^^^^^ // "Should be" [ 3.333]
Going home...^^ // "Should be" [**Going home...]
I mean "should be" assuming that:
- member function calls would permanently change the formatting state
- manipulators calls would temporarily override the formatting state
But as you can see that's not the case and there's no even a "congruent misbehavior". Some member functions and manipulators (fill(), hex, left) permanently change behavior, others (width(), setw()) temporarily override, yet others misbehave strangely as precision (which should affect only how many decimal places to use and not the integral part as well!). In essence each situation is very simple, but when mixed on code, things can become quickly strange, perhaps a nightmare. A programmer can become quickly stressed and choose a less than optimal quick way out! But that's bad in the long run; that's not quality programming. Even the most simple programs such as rc-03 or the one listed below (which generated the above output) can face such annoyances when trying to print formatted output.
Subscribe to:
Posts (Atom)