    <rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:sy="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:content="http://purl.org/rss/1.0/modules/content/">
     <channel>
        <title>ACCU  :: Editorial: Doing What You Can</title>
        <link>https://members.accu.org/index.php/articles/1991</link>
        <description>Professionalism in Programming</description>
        <dc:language>en-us</dc:language> 
        <dc:creator>Administrator</dc:creator> 
        <admin:generatorAgent rdf:resource="http://www.xaraya.org" /> 
        <admin:errorReportsTo rdf:resource="mailto:webeditor@accu.org" />
       <sy:updatePeriod>hourly</sy:updatePeriod>
       <sy:updateFrequency>1</sy:updateFrequency>
       <docs>http://backend.userland.com/rss</docs>




<div class="xar-mod-head"><span class="xar-mod-title">Journal Editorial + Overload Journal #72 - Apr 2006</span></div>

<table border="0" cellpadding="1" cellspacing="0">
    <tbody>
    <tr>
        <td valign="top">
            Browse in :
       </td>
       <td valign="top">

                                            <a href="https://members.accu.org/index.php/articles/">All</a>

                     &gt;                         <a href="https://members.accu.org/index.php/articles/c184/">Journal Columns</a>

                     &gt;                         <a href="https://members.accu.org/index.php/articles/c185/">Editorial</a>
<br />

                                            <a href="https://members.accu.org/index.php/articles/">All</a>

                     &gt;                         <a href="https://members.accu.org/index.php/articles/c76/">Journals</a>

                     &gt;                         <a href="https://members.accu.org/index.php/articles/c78/">Overload</a>

                     &gt;                         <a href="https://members.accu.org/index.php/articles/c140/">72</a>
<br />

                                            <a href="https://members.accu.org/index.php/articles/c185-140/">Any of these categories</a>

                    -                        <a href="https://members.accu.org/index.php/articles/c185+140/">All of these categories</a>
<br />
</td>
   </tr>
   </tbody>
</table>




<div class="xar-error">
   <p>
 <strong>Note:</strong> when you create a new publication type,
the articles module will automatically use the templates
<em>user-display-[publicationtype].xt</em>
and <em>user-summary-[publicationtype].xt</em>.
If those templates do not exist when you try to preview or display a new article,
you'll get this warning :-)  Please place your own templates in themes/<em>yourtheme</em>/modules/articles . The templates will get the extension .xt there. </p>
</div>
<div class="xar-norm xar-standard-box-padding">
   <h1><strong>Title:</strong>&nbsp;Editorial: Doing What You Can</h1>
<p><strong>Author:</strong>&nbsp;Martin Moene</p>
<p>
<strong>Date:</strong> 06 April 2006 10:47:52 +01:00 or Thu, 06 April 2006 10:47:52 +01:00</p>
<p><strong>Summary:</strong>&nbsp;</p>
<p><strong>Body:</strong>&nbsp;<p>Your magazine needs you! </p>
<p>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. </p>
<p>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. </p>
<p>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.) </p>
<p>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. </p>
<p>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). </p>
<p>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. </p>
<h2>More on WG14 </h2>
<p>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 <a href="mailto:jb@benito.com">jb@benito.com</a>): </p>
<blockquote>
<p>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. </p>
<p>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. </p>
<p>I am not trying to harsh in any way, but I really do not want WG14 misrepresented to the Community. </p>
<p>Thank you. John Benito (WG14 Convener) </p>
</blockquote>
<p>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. </p>
<h2>More on C++/CLI </h2>
<p>Iâ€™ve also had an email about C++/CLI. Mark Bartosik <a href="mailto:mbartosik@yahoo.com">mbartosik@yahoo.com</a> writes: </p>
<blockquote>
<p>Alan, Iâ€™ve just read your editorial in Overload. A lot of what you said rang very true with me. </p>
<p>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... </p>
<p>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. </p>
<p>Now for the important comment that is also an embarrassment.... </p>
<p>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. </p>
<p>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). </p>
<p>Nice editorial, Mark </p>
</blockquote>
<p>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: </p>
<blockquote>
<p>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++. </p>
</blockquote>
<p>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. </p>
<p>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.) </p>
<p>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. </p>
<h2>More on the Safe Standard C++ Library</h2>
<p>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. </p>
<p>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. </p>
<p>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 &lt;insert random=&quot;&quot; programming=&quot;&quot; language=&quot;&quot; here=&quot;&quot;&gt;â€. Once a few stories like this start â€œgoing aroundâ€ the facts will become irrelevant â€“ like the idea that C++ programs have memory management problems and that Java programs donâ€™t. &lt;/insert&gt;</p>
<h2>In Conclusion </h2>
<p>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? </p>
<p>I hope to see you at the conference! </p>
<p>Alan Griffiths 
overload@accu.org </p>
<p>References </p>
<ol>
<li>ACCU conference: http://www.accu.org/conference/ </li>
<li>XtC: http://www.xpdeveloper.net/xpdwiki/Wiki.jsp?page=XtC </li>
<li>SomethingInNottingham: 	http://www.xpdeveloper.net/ xpdwiki/Edit.jsp?page=SomethingInNottingham </li>
<li>ECMAâ€™s response: http://www.octopull.demon.co.uk/ editorial/ECMA_comments_on_ISO_IEC_DIS_26926_ C++_CLI_Language_specification001.pdf </li>
<li>â€œA Design Rationale for C++/CLIâ€, Herb Sutter 
http://www.gotw.ca/publications/C++CLIRationale.pdf </li>
<li>â€œC++/CLI Lanaguage Specificationâ€ -http://www.ecmaÂ­international.org/publications/files/ECMA-ST/ECMAÂ­
372.pdf </li></p>
<p><strong>Notes:</strong>&nbsp;</p>
<p><em>More fields may be available via dynamicdata ..</em></p>
</div>
</channel>
</rss>
