Title: You Write, The Editor Replies

Hi Francis,

I was interested to see Jon Jagger's article, "Compile Time Assertions in C", and your critique of it, in C Vu 11(3).

Some time ago I looked at expressing compile time assertions in C++ using templates in my /tmp/late/* series, notably "Constraining template parameter types" (Overload 12) and "Constraining template parameter values" (Overload 15). The intent is to capture, document, and enforce a constraint, encapsulating these features within a template class. Whilst there is a certain amount of trickery involved, the fact that templates retain their integrity through the compilation is key to the use of these techniques: poor as template related compiler diagnostics are, they will still lead you to the right place.

And this is the problem: the techniques in Jon's article all rely on /1/ the pre-processor, and /2/ halting compilation. Pre-processor symbols lose their identity in the process of compilation, which leads to succinct but useless messages (as opposed to the long and possibly useful ones - if only we could tell - typically provided for template related errors ;->). Thus I feel that it would lead to both forward development and maintenance problems.

However, on the plus side, I think Jon's "{yourself}" columns are valuable in stretching and exploring the limits of C, and in particular the pre-processor as a language in its own right (as well as serving a constant reminder why I am not a great fan of it!). Causing people to stop, think and ask questions is no bad thing in an industry whose attitude seems to lean increasingly toward the idea that thinking and questioning are obstacles on the critical path of any project; that they should be automated or, at the very least, given their own timesheet code for tracking and auditing; that dumbing down is a more optimal strategy than wising up.

Kevlin Henney <kevlin@two-sdg.demon.co.uk>

Thanks. As both you and Jon know, I always welcome his thoughtful and thought provoking contributions. One thing that certainly distinguishes average ACCU members from the average programmer is that they abhor dumbing down and want to learn.

Dear Francis,

how is it going? Sorry that I have been out of touch for a while but my life has been going through all sorts of changes, both in terms of career and country of habitation...

I am now living in Brussels working for a company called Styrax Associates as a Java developer and system administrator building Linux installations for dynamic web sites and all that sort of thing. All a bit hectic at the moment but looks extremely promising once the initial development has been done.

The reason that I am writing is because as well as our own projects which is all done in-house, we are also acting as an "agent" for placing programmers in external contracts in order to maintain a good cash flow for the company during the initial stages.

However, we are experiencing problems in tracking down qualified experienced programmers in several fields and I thought that with your contacts in ACCU that you might be able to point people who are currently looking for work in our direction. We are working with contracts in France, Belgium, Holland & Luxembourg and are in need of a wide range of skills including:-

and other associated fields...

If anyone is looking for work in these regions then it would be great if you could pass my email address onto them. If they want to get directly in touch with our personnel guy then they can email him directly at:-

Pierre Louvrier <pl@styrax.com>

Another thing which I noticed recently which might amuse you is that Ultra Technology have released a new range of processors that run directly in forth. I haven't had a chance to read up on it in depth but if you are interested then check out:

www.ultratechnology.com

www.forth.org

Maybe this is an excuse to brush up on my stack manipulations (which are sadly extremely rusty)...

Alex Fiennes

Alex was one of the very brightest of my students (and that makes him something very special because I had more than my share of exceptional pupils. If you are looking for work and have the requisite skills remember to mention the source of the contact if you elect to email Pierre.

Dear Francis,

In my letter in C Vu 11.3 I made a mistake about livelock. According to Jean Bacon's "Concurrent Systems" edition 2 p417, livelock is when a process indefinitely tests a condition that can never become true. Two other things to look out for are communications protocols that degenerate into "ping-pong" under load, and "resource starvation", when a process needs a lot of resources but can't find a time when they're all free.

Silas S Brown

Dear Francis,

Do you know of any online tutorials concerning Java or MFC? I found the Coronado C/C++ tutorials very good. I have read the book Thinking in Java by Bruce Eckel but found it aimed a bit higher than I would ideally like.

Hope to hear from you soon.

Saqib Shaikh School: <shaikh@rnibncw.demon.co.uk>

Home: <personal@saqib-shaikh.freeserve.co.uk>

Well can anyone help? Please remember that Saqib is 100% blind so keep email to simple text.

Hi Francis,

This is a response to your invitation for constructive criticism on the article 'All you need to know about enums'.

As I don't know what the intent of the non-appendix material of the book is, I guess I can't comment too fully on how it fits with the whole, but I guess the minutiae are something that I can address.

One question I had was whether you would be giving similar treatment to structs and unions, as there is a common base that can be factored out:

Factoring out such a section I feel could leave your enum material more focused. There is also a case to be made for a similar tour of const differences and similarities between C and C++, unless you are already covering this elsewhere.

I noted a few typos lurking:

Style issues:

Some topics I noted by omission:

Also, a comment on tone: it's conversational, but perhaps a little too subjunctive/non-committal in places: whilst it's good to raise questions from the reader, I guess I would expect a more assertive tone in a book, especially in an appendix. What do you think?

Anyway, hope this helps. I look forward to your comments on my offerings in the near future!

Kevlin Henney <kevlin@two-sdg.demon.co.uk>

Quite a number of readers responded to my request. Kevlin's was the most thorough which is why I am publishing his and the following one rather than the others. Note how much Kevlin has found to comment on. Next time you read a technical book think about how thorough a job the technical reviewers have done. Books should be far more polished than magazine articles.

Thanks to all who took the trouble to comment.

Hi Francis,

In C Vu 11.3 you wrote an article on enums. You thought some readers might be able to provide some constructive criticism...

I have a few typos...

struct programLimits { maxsize = 100 };  //??? struct --> enum
enum X { zero, one two };  // missing comma between one and two
class myInt {
     myInt(int v = 0) : value(v) {}  // missing a public: specifier
     ...
namespace mathematicalConstants {{}
    class myDouble {
        myDouble(double v = 0) : value(v) {}  // missing public: specifier
        ...
    private:
    double value;
   // };    missing here
     myDouble const int pi = 3.14159265;
};  // spurious extra ; here

Also both conversion operators should be const qualified.

I would also say that I much prefer placing each new { on its own line. Obviously this is something of a style issue, but remember the target audience are C++ newbies and visual entity separation is very important. You might also consider using initial_value instead of v as a parameter name

namespace math_Constants
{
     class my_Double
     {
     public:
          my_Double(double initial_value) : value(initial_value) { }
          operator double( ) const { return value; }
     private:
          double value;
     };
}

Jon Jagger <Jon.Jagger@qatraining.com>

Thanks. Interesting that you picked up on the conversion operators which Kevlin missed. It is theoretically possible to overload conversions on const. I wonder whether that would ever be useful. On the subject of the parameter name, I would opt for something like yours in a prototype (declaration) but would choose the short option in a definition. Layout? Well let us not get into that debate.