Your magazine needs you!
If you look at the contents of this issue of Overload you’ll see that most of the feature content has been written by the editorial team.You might even notice that the remaining article is not new material. To an extent this is a predictable consequence of the time of year: many of the potential contributors are busy preparing for the conference.
However, as editor for the last couple of years I’ve noticed that there is a worrying decline in proposals for articles from authors. Many of the great articles you’ve enjoyed over the last year have only arisen because I’ve happened to be talking to someone about a problem they have encountered developing software and the way they solved it. When I suggest that they write it up the usual response is “no-one would find that interesting” – but those that have gone ahead and written an article will attest that people are interested in these things. We belong to a community that enjoys solving the problems of software development and in hearing about the experience of others.
One of the things about a community is that it is strengthened by sharing, all of you have stories to tell – and the purpose of Overload is here to help you tell them. The team of advisors listed at the front of Overload are not here to write the magazine for you, they are here to help with the selection of the best stories to publish and to work with the authors to ensure that their stories are told well. And after the advisors’ efforts to fill the pages of Overload this time I’m going to enforce a rest. I will not be accepting any articles from the advisors for the next issue of Overload. (If the next issue consists only of an editorial then you’ll know why.)
I know, because I’ve heard the stories, that several of you could write about “Proving Brookes’ Law” (the industry clearly needs more evidence); or “A Pair Programming experience report” (that may be better written jointly– when you are talking to each other once more); or “Doing the Right Thing” (when judgment and policy disagree). I’m sure that others I’ve not talked to could also contribute to these or other stories.
Make an effort to contribute to the magazine. If you are willing but “don’t have anything to write” then seek me (or one of the advisers) out at the ACCU conference, at XtC, at SomethingInNottingham, or by email – every one of you has a story to share, you just might not realise it yet. It doesn’t have to be a success story: “cautionary tales” are as informative as “happy endings” (and sometimes more useful).
Remember, I’m not going to let the advisors write Overload 73 for you. It is your magazine and you need to make an effort.
More on WG14
Last time I commented on the fact that I was hearing conflicting information about the WG14 technical report on “safe” alternatives to the standard library function. This has led to an email from the Convener of WG14 (John Benito jb@benito.com ):
Reading the editorial in the February 2006 edition of the Overload magazine written by you, Exhibit 3. WG14 is indeed working on a Technical Report that will define more resilient library functions (we are staying away from “secure”, “safe” and that ilk). This work was first brought to WG14 by Microsoft, but to indicate it would have Microsoft specific extensions embedded is just ridiculous and a statement like that would only come from the misinformed. Chris Hills indeed was the Chair of the UK C Panel, but attended (or partially attended) just one (yes one) WG14 meeting his entire tenure as UK C Panel convener, and should not be used as a reference to what is happening within the Working Group. If you want to know what is going on in WG14, ask me, or Francis Glassborow, or at the very least ask someone that actually attends the meetings.
I would also like to point out that using statements like “later this year if WG14 (article has WG13) accepts this” makes it seems as if you do not understand the ISO process. WG14 generated an NP for this work in 2003, this NP was balloted at the SC22 level, passed and WG14 officially started work on the project. Since then the TR has been through the Registration ballot phase and is ready for the next ballot in the process. Again, if you are not sure of this process ask. Also implying anyone can write a Technical Report because we are all volunteers is misleading and just not the case. There is a process, and the process is followed.
I am not trying to harsh in any way, but I really do not want WG14 misrepresented to the Community.
Thank you. John Benito (WG14 Convener)
I hope that clarifies the situation. I apologise for implying that due process is not being followed and only intended to observe that, typically, national bodies do not actively oppose work that they themselves don’t wish to spend time on.
More on C++/CLI
I’ve also had an email about C++/CLI. Mark Bartosik mbartosik@yahoo.com writes:
Alan, I’ve just read your editorial in Overload. A lot of what you said rang very true with me.
I’ve got a reasonable degree of competence in C++ (attended ACCU conference for about ten years, and speaking this year). I say this to place into context my following comments...
When I first heard from Herb a couple of years ago what Microsoft were doing to bind C++ to CLI it sounded cool. However, when I now look at what it has evolved into I too feel like it is a different language, for me it is the attributes and keywords where library code might have done the job.
Now for the important comment that is also an embarrassment....
When I read some of the Visual Studio 2005 / MSDN documentation, I did think that I had lost track of what was happening to the C++ standard. I thought that some of what were in reality C++/CLI features were C++ features that were in TR2 and I had somehow got confused about what was in TR2. No it was just that the documentation is highly misleading, and it mislead me. Not for long, but I’m sure that many of my coworkers would have been completely fooled.
I have no experience in C++/CLI, indeed I’ve only read some of the documentation, but I was fooled by the documentation for at least a short time. The documentation does make it feel like a different language but also gives the impression that some features are C++, some are plausible features (attributes are obviously not).
Nice editorial, Mark
The issue that should concern us as developers is the confusion that Mark highlights regarding which semantics belong to C++ and which to C++/CLI. However, ECMA’s response to the issues raised by BSI dismisses this:
There is no reason to expect that programmers will mistake C++/CLI features for ISO C++ features any more than they occasionally mistake extensions in specific compilers (e.g., Borland, Gnu, and Microsoft) for ISO C++ features. Rather, having these extensions as a named standard instead of unnamed vendor extensions serves to help distinguish them more clearly from ISO C++.
This confusion of language semantics would not arise with a library based “binding” to the CLR – or with language extensions to add semantics. The difficulty of doing this is discussed in Herb Sutter’s excellent paper “A Design Rationale for C++/CLI”: to achieve the design goals that the C++/CLI group set themselves language support for a radically different programming model is necessary.
Those involved in the “C++/CLI Language Specification” have done a good job of solving the problems set by integrating C++ into a platform with a radically different object model: C++/CLI is better thought out than comparable technologies like Microsoft’s “managed C++” or Borland’s VCL. It does look like a good and useful addition to the curly-brace family of languages! (And C++/CLI is definitely “on topic” for Overload – so don’t be shy of writing articles that use it.)
In any case, it seems likely that around the time you are reading this, there will be more developments on this front. Both BSI representatives and Microsoft representatives will be present at a WG21 meeting in Berlin and we can expect that a constructive dialogue will ensue.
More on the Safe Standard C++ Library
A great deal of effort has been expended explaining to the Microsoft representatives that others may have a different security model than they do (and, therefore, different vulnerabilities), that other concerns dominate in other organisations (which make the suggested “solution” unacceptable), that the diagnostics may be issued for manifestly correct code, that changing code to fix the diagnostic can result in incorrect code, and that the choice of wording creates a misleading impression regarding the authority of the diagnostics.
Obviously, there are limitations to what Microsoft can do with software that has already shipped, and even to what they can change in a service pack. But clearly things have been happening within Microsoft, because Herb Sutter (yes, he’s been busy) recently came back to the WG21 reflector seeking feedback on their current plans for addressing this in a service pack. In particular, the wording has been changed to avoid implying that the advice is standards based, and to make it easier for library vendors to suppress the diagnostics appropriately. While there are concerns that have not been addressed by this proposal it is a big improvement.
Probably the most significant concern is due to a lot of the diagnostics produced being false positives. It is still easy to envisage scenarios where correct code is flagged as being “unsafe” resulting in a developer spending time to fix the “problem” and, in the process, producing “safe” code that is incorrect. While I accept that scenarios like this should be rare, they will be noticed: “you broke it because the compiler said it was wrong? That doesn’t happen with
In Conclusion
Each of us can only do so much to uphold the values we espouse. But we have a solemn duty not only to do what we think is right, but to recognise what others are achieving. Sometimes the latter may not be obvious but, given the history of Microsoft, does anyone believe that there would be any progress towards resolving the above issues without considerable internal resistance?
I hope to see you at the conference!
Alan Griffiths overload@accu.org
References
- ACCU conference: http://www.accu.org/conference/
- XtC: http://www.xpdeveloper.net/xpdwiki/Wiki.jsp?page=XtC
- SomethingInNottingham: http://www.xpdeveloper.net/ xpdwiki/Edit.jsp?page=SomethingInNottingham
- ECMA’s response: http://www.octopull.demon.co.uk/ editorial/ECMA_comments_on_ISO_IEC_DIS_26926_ C++_CLI_Language_specification001.pdf
- “A Design Rationale for C++/CLI”, Herb Sutter http://www.gotw.ca/publications/C++CLIRationale.pdf
- “C++/CLI Lanaguage Specification” -http://www.ecmainternational.org/publications/files/ECMA-ST/ECMA 372.pdf
