    <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  :: Student Code Critique Competition 30</title>
        <link>https://members.accu.org/index.php/journals/702</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>


        <h2>Journal Articles</h2>


<div class="xar-mod-head"><span class="xar-mod-title">CVu Journal Vol 16, #5 - Oct 2004 + Student Code Critiques from CVu journal.</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/journals/">All</a>

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

                     &gt;                         <a href="https://members.accu.org/index.php/journals/c77/">CVu</a>

                     &gt;                         <a href="https://members.accu.org/index.php/journals/c100/">165</a>
                    (13)
<br />

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

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

                     &gt;                         <a href="https://members.accu.org/index.php/journals/c183/">Code Critique</a>
                    (70)
<br />

                                            <a href="https://members.accu.org/index.php/journals/c100-183/">Any of these categories</a>

                    -                        <a href="https://members.accu.org/index.php/journals/c100+183/">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;Student Code Critique Competition 30</h1>
<p><strong>Author:</strong>&nbsp;</p>
<p>
<strong>Date:</strong> 06 October 2004 13:16:08 +01:00 or Wed, 06 October 2004 13:16:08 +01:00</p>
<p><strong>Summary:</strong>&nbsp;</p>
<p><strong>Body:</strong>&nbsp;<div class="sect1" lang="en">
<div class="titlepage">
<h2><a name="d0e22" id="d0e22"></a></h2>
</div>
<p><span class="bold"><b>Prizes provided by Blackwells Bookshops
&amp; Addison-Wesley</b></span></p>
<p class="c2"><span class="remark">Please note that participation
in this competition is open to all members. The title reflects the
fact that the code used is normally provided by a student as part
of their course work.</span></p>
<p class="c2"><span class="remark">This item is part of the
Dialogue section of C Vu, which is intended to designate it as an
item where reader interaction is particularly important. Readers'
comments and criticisms of published entries are always
welcome.</span></p>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<h2><a name="d0e33" id="d0e33"></a>Before We
Start</h2>
</div>
<p>It seems that praying for more participation among members is
giving good results, but anyway, let's hope I don't have to repeat
the plea issue after issue. Please note that you can participate
not only by submitting critiques, but also by contributing code
snippets you came across which attracted your attention. Remember
that you can get the current problem set on the ACCU website
(<a href="http://www.accu.org/journals/" target=
"_top">http://www.accu.org/journals/</a>). This is aimed at people
living overseas who get the magazine much later than members in the
UK and Europe.</p>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<h2><a name="d0e41" id="d0e41"></a>Student Code
Critique 29 Entries</h2>
</div>
<p>Looks like an ordinary snippet, doesn't it? Amazingly, it
contains various mistakes for such a few lines. Please provide a
correct version.</p>
<pre class="programlisting">
#include &lt;iostream&gt;
using std::cout;
using std::endl;

#include &lt;list&gt;
using std::list;

int main() {
  list&lt;double&gt;::iterator it;
    list&lt;double&gt; lst;
  *it = 34;
  *++it = 45;
    *++it = 87;
    it = lst.begin();
    for (;it &lt; lst.end(); ++it){
      cout &lt;&lt; it &lt;&lt; '\t' &lt;&lt; *it &lt;&lt; endl;
  }
    system(&quot;pause&quot;);
  return 0;
}
</pre>
<div class="sect2" lang="en">
<div class="titlepage">
<h3><a name="d0e48" id="d0e48"></a>From Tony Houghton
<tt class="email">&lt;<a href=
"mailto:h@realh.co.uk">h@realh.co.uk</a>&gt;</tt></h3>
</div>
<p>There are three errors preventing the program from compiling.
The first is that <tt class="literal">&lt;</tt> is not a valid
operator for an iterator and needs to be replaced with <tt class=
"literal">!=</tt>. Then it can not be printed to <tt class=
"classname">cout</tt>; we could print the the address of the data
it references, but that's a useless piece of information in this
context, so I think it's better to introduce a second variable
called <tt class="varname">n</tt> showing the numerical position
we've reached in the list. This is only meaningful as a cue for the
user.</p>
<p>I've chosen to initialise it outside the loop and increment it
in the loop body rather than in the loop statement to emphasise
that the loop is iterating through the list and <tt class=
"varname">n</tt> is supplemental. The final compile error is that
we haven't included <tt class="filename">&lt;cstdlib&gt;</tt> so
<tt class="function">system</tt> is undefined. The pause command is
not portable anyway, and C++ makes such a meal of waiting for a
user to press Enter that I've just deleted that line and left it up
to the user to run the program in a shell or IDE that will give
them a chance to read the output.</p>
<p>Even though it will now compile the code is still badly bugged
and likely to crash. We're derefencing <tt class="varname">it</tt>
without initialising it. Not only that, it is not possible to add
elements to a list by writing off the end of it. We need to
explicitly create a new element by appending to the list with its
<tt class="methodname">push_back</tt> method.</p>
<p>Here is my version of the code:</p>
<pre class="programlisting">
#include &lt;iostream&gt;
using std::cout;
using std::endl;
#include &lt;list&gt;
using std::list;

int main() {
  list&lt;double&gt; lst;
  lst.push_back(34);
  lst.push_back(45);
  lst.push_back(87);
  int n = 0;
  for(list&lt;double&gt;::iterator it = lst.begin();
      it != lst.end(); ++it)
    cout &lt;&lt; n++ &lt;&lt; '\t' &lt;&lt; *it &lt;&lt; endl;
  return 0;
}
</pre></div>
<div class="sect2" lang="en">
<div class="titlepage">
<h3><a name="d0e90" id="d0e90"></a>From Roger Orr
<tt class="email">&lt;<a href=
"mailto:rogero@howzatt.demon.co.uk">rogero@howzatt.demon.co.uk</a>&gt;</tt></h3>
</div>
<p>The problem posed is to provide a correct version of the
code.</p>
<p>The first question which needs answering is what is the purpose
of this code? It looks very much like someone's first experiment
with STL collections and iterators - but they don't really
understand what they're trying to do.</p>
<div class="sect3" lang="en">
<div class="titlepage">
<h3><a name="d0e99" id="d0e99"></a>Solution one:</h4>
</div>
<pre class="programlisting">
#include &quot;Josuttis/The C++ Standard
                            Library/Chapter 5&quot;
</pre>
<p>There's little point simply fixing the code since the basic
misunderstanding seems so great; a good tutorial/reference is
probably the best place to start. However, if you insist...</p>
</div>
<div class="sect3" lang="en">
<div class="titlepage">
<h3><a name="d0e106" id="d0e106"></a>Input</h4>
</div>
<p>The code seems to be trying to fill a list using an iterator and
then print out the list to verify that it filled properly.</p>
<pre class="programlisting">
11   *it = 34;
12   *++it = 45;
13   *++it = 87;
</pre>
<p>Unfortunately, although a list can be populated with an
iterator, a standard <tt class="classname">list::iterator</tt> is
not the right sort! There are classes of iterators which are
designed to allow insertion, so we need one of those to insert
either at the back or the front of the list. I'll pick a back
iterator since that means the items will be printed in the order
they're inserted, which seems more intuitive. So let's replace
these lines with:</p>
<pre class="programlisting">
back_insert_iterator&lt;list&lt;double&gt; &gt; ins_it(lst);
*ins_it = 34;
*++ins_it = 45;
*++ins_it = 87;
</pre>
<p>This code is perfectly OK, but there is a potential performance
issue with using pre-increment. It's probably not worth worrying
the writer of the code with this just yet (but you could refer them
to one of the Effective C++ books...)</p>
<p>Now we'll need to include another header file, &lt;iterator&gt;,
to be compliant with the standard and add a using <tt class=
"classname">std::back_insert_iterator</tt>.</p>
<p>On that note, programmers vary on their attitude to using.
Again, I wouldn't worry this programmer too much about it at this
point (unless company coding rules apply!) Now the code.</p>
</div>
<div class="sect3" lang="en">
<div class="titlepage">
<h3><a name="d0e129" id="d0e129"></a>Output</h4>
</div>
<p>The code to output the list relies on <tt class=
"methodname">operator&lt;</tt> for the iterator - this pretty well
implies that the iterator is a random access iterator, such as an
iterator over a vector. The normal paradigm for iterators in STL is
to use <tt class="literal">!=</tt> for the loop condition.</p>
<p>The loop can be coalesced: currently we have 3 parts to the loop
control structure:</p>
<div class="orderedlist">
<ol type="a">
<li>
<p>Declaration</p>
<pre class="programlisting">
list&lt;double&gt;::iterator it;
</pre></li>
<li>
<p>Initialisation</p>
<pre class="programlisting">
it = lst.begin();
</pre></li>
<li>
<p>Condition and update expression</p>
<pre class="programlisting">
it != lst.end(); ++it
</pre></li>
</ol>
</div>
<p>I'd recommend putting these all into the for statement
<tt class="literal">for</tt> clarity and to reduce the scope of
<tt class="varname">it</tt>:</p>
<pre class="programlisting">
for(list&lt;double&gt;::iterator it = lst.begin();
    it != lst.end(); ++it)
</pre>
<p>or, since we're trying to output from the list only,</p>
<pre class="programlisting">
for(list&lt;double&gt;::const_iterator it
                                = lst.begin();
    it != lst.end(); ++it)
</pre>
<p>Again, more advanced techniques to avoid the for loop completely
are possible but would be likely to simply confuse the programmer
at this point. Now, what are we actually outputting inside the
loop? The code as written tries to print the iterator itself and
then its contents. By analogy with 'iterator is a generalised
pointer' I guess the purpose is to display the address of each item
and its value. However there's not a standard <tt class=
"methodname">operator&lt;&lt;</tt> defined to do this - the easiest
solution is to use the <tt class="literal">&amp;</tt> operator:</p>
<pre class="programlisting">
cout &lt;&lt; &amp;*it &lt;&lt; '\t' &lt;&lt; *it &lt;&lt; endl;
</pre>
<p>or possibly, for clarity, use a helper variable:</p>
<pre class="programlisting">
const double &amp;value = *it;
cout &lt;&lt; &amp;value &lt;&lt; '\t' &lt;&lt; value &lt;&lt; endl;
</pre>
<p>Now we're almost done... on a Microsoft compiler on Windows
anyway :-) The last statement, <tt class=
"literal">system(&quot;pause&quot;)</tt>, is target environment dependent.
This might be fine and if so I've no problem with do the job like
this. I might like to include <tt class=
"filename">&lt;cstdlib&gt;</tt> of course, since <tt class=
"function">system</tt> currently works because, on my version of
the standard library, one of the other header files is pulling in
<tt class="filename">&lt;cstdlib&gt;</tt>.</p>
<p>If the code has to be portable then you'd need to replace it
with something equivalent (or nearly so) from the C++ library. I'm
assuming the code is fine on the target OS. And that's it - to get
the code working anyway. Explaining the changes - and in particular
the two types of iterators needed - might be a little more
work!</p>
</div>
</div>
<div class="sect2" lang="en">
<div class="titlepage">
<h3><a name="d0e202" id="d0e202"></a>From Roger Leigh
<tt class="email">&lt;<a href=
"mailto:rleigh@whinlatter.ukfsn.org">rleigh@whinlatter.ukfsn.org</a>&gt;</tt></h3>
</div>
<p>Overall, the intentions of the author are obvious, but it is
clear that some misunderstandings over the use of containers and
iterators resulted in non-functional code. The use of headers and
<tt class="literal">using</tt> statements was fine, and the general
structure of the code was also acceptable, bar two lines that
required more indentation.</p>
<p>The first major error is with the use of iterators. When
assigning values to the list, the iterator is not initialised and
so is invalid (cannot be dereferenced). To compound the error, on
the second and third assignments, the iterator is incremented in
addition to dereferencing. All these mistakes will result in
undefined behaviour.</p>
<p>The <tt class="methodname">push_back()</tt> method is probably
what the student wants. It looks like there is some confusion over
how iterators work. The student needs to understand that iterators
&quot;point&quot; to items within a container, and that they are not by
themselves responsible for inserting values. Likewise, while an
iterator can be incremented, this is only useful when there is a
next element in the container, and error checking should be done to
check that the new iterator is valid. Like pointers, they need to
point to a valid location, and only then may they be dereferenced
to access the contained value. For insertion, an iterator would
typically only be used when inserting in a specific location in the
list (used with the <tt class="methodname">insert()</tt> methods),
or when using an insert iterator, neither of which are applicable
in this case.</p>
<p>The <tt class="literal">for</tt> loop iterator is initialised
outside the <tt class="literal">for</tt> statement. While valid,
it's not necessary and is bad style. Also, the <tt class=
"literal">for</tt> loop conditional uses <tt class="literal">it
&lt; lst.end()</tt> rather than <tt class="literal">it !=
lst.end()</tt>. Not all iterators implement <tt class=
"methodname">operator&lt;</tt>, but all implement <tt class=
"methodname">operator==</tt> and <tt class=
"methodname">operator!=</tt>. We only need to know if we are at the
end of the list. When outputting the list contents, the iterator is
output to an <tt class="classname">ostream</tt>, which is not
possible (the operator is not implemented). Iterators do not have a
(user-visible) index or a meaningful address, and so if the
elements should be numbered, a suitable container should be used
(e.g. a vector, which allows access by index), or the numbering
should be done &quot;by hand&quot;. <tt class="classname">std::endl</tt> is
used after outputting each element. This adds a newline and flushes
the <tt class="classname">ostream</tt>. The flushing is
unnecessary, and would have a negative impact on performance when
outputting the contents of a larger container. '<tt class=
"literal">\n</tt>' is adequate here. A more general issue is the
use of <tt class="classname">list&lt;double&gt;</tt>. The numbers
could more easily be stored in an <tt class="type">int</tt>, or
<tt class="type">short int</tt>. I would also have used a
<tt class="classname">vector&lt;int&gt;</tt> myself, given that the
additional features a list provides are not used, and impose a
greater overhead than a <tt class="classname">vector</tt> (e.g.
memory usage).</p>
<p>Lastly, <tt class="literal">system(&quot;pause&quot;)</tt> is both
system-dependent (non-portable) and mostly useless. I've only come
across its use in Windows environments in order to stop the
terminal window closing on program exit. This won't work on
platforms without a pause command (e.g. UNIX), and is a terminal
configuration issue, not something to &quot;fix&quot; in the program code
itself. The solution is to configure the terminal window not to
close on exit, or to run the program directly from the shell. A
version of the code rewritten to take the above into consideration
follows:</p>
<pre class="programlisting">
#include &lt;iostream&gt;
using std::cout;
using std::endl;
#include &lt;vector&gt;
using std::vector;

int main() {
  vector&lt;int&gt; coll;
  vector&lt;int&gt;::iterator pos;
  coll.push_back(34);
  coll.push_back(45);
  coll.push_back(87);

  int n = 0;
  for(pos = coll.begin(); pos != coll.end();
      ++n, ++pos)
    cout &lt;&lt; n &lt;&lt; '\t' &lt;&lt; *pos &lt;&lt; '\n';

  return 0;
}
</pre></div>
<div class="sect2" lang="en">
<div class="titlepage">
<h3><a name="d0e282" id="d0e282"></a>From Nevin Liber
<tt class="email">&lt;<a href=
"mailto:nevin@eviloverlord.com">nevin@eviloverlord.com</a>&gt;</tt></h3>
</div>
<p>Where to begin, where to begin...</p>
<div class="sect3" lang="en">
<div class="titlepage">
<h3><a name="d0e291" id="d0e291"></a>Syntax error
#1:</h4>
</div>
<pre class="programlisting">
cout &lt;&lt; it
list&lt;double&gt;::iterator it;
//...
cout &lt;&lt; it //...
</pre>
<p><tt class="varname">it</tt> is an iterator, not a pointer, and
there is no standard way to output <tt class="varname">it</tt> to a
stream. Guessing here that the intent was to display the address of
the element in question, the following will work:</p>
<pre class="programlisting">
cout &lt;&lt; &amp;*it //...
</pre>
<p>The dereference <tt class="methodname">operator*()</tt> is
called on the iterator, returning a reference to the element. Then
the address-of <tt class="methodname">operator&amp;()</tt> is
called upon that, yielding the address of the element. Note: if the
container were of a user defined type instead of <tt class=
"type">double</tt>, this idiom might not work if the user defined
type overloaded <tt class="methodname">operator&amp;()</tt>.</p>
</div>
<div class="sect3" lang="en">
<div class="titlepage">
<h3><a name="d0e319" id="d0e319"></a>Syntax error
#2:</h4>
</div>
<pre class="programlisting">
system(&quot;pause&quot;)
</pre>
<p><tt class="function">system()</tt> is not a built in function.
One way to get its function prototype would be to <tt class=
"literal">#include</tt> a header which contained it, such as
<tt class="literal">#include&lt;cstdlib&gt;</tt>. Typically,
<tt class="literal">system(&quot;pause&quot;)</tt> would call another program
called pause. While not a syntax error, my computer does not
contain such a program, and rather than guess at its semantics
(wait for a certain amount of time, wait for a key to be pressed,
wait for a signal, etc.), I'm going to leave it out for the rest of
this discussion.</p>
</div>
<div class="sect3" lang="en">
<div class="titlepage">
<h3><a name="d0e337" id="d0e337"></a>Syntax error
#3:</h4>
</div>
<pre class="programlisting">
it &lt; lst.end()
</pre>
<p>Iterators are not pointers. list in particular has bidirectional
iterators, and should only be compared for equality (<tt class=
"methodname">operator==()</tt>) or inequality (operator!=()). Note:
not all compilers will catch this at compile time, depending on how
its particular implementation of <tt class=
"classname">list&lt;T&gt;::iterator</tt> was written. Whether or
not it is a syntax error, it is definitely a semantic error, and
the fix is</p>
<pre class="programlisting">
it != lst.end()
</pre>
<p>Now that we are done with syntactical errors, on to the purely
semantic ones.</p>
</div>
<div class="sect3" lang="en">
<div class="titlepage">
<h3><a name="d0e354" id="d0e354"></a>Semantic error
#1: what list does it refer to?</h4>
</div>
<p>Looking at our declaration:</p>
<pre class="programlisting">
list&lt;double&gt;::iterator  it;
list&lt;double&gt;            lst;
</pre>
<p><tt class="varname">it</tt> does not refer to any particular
list. I'll actually fix this later, since it won't be needed in the
fix for the next three lines of code anyway...</p>
</div>
<div class="sect3" lang="en">
<div class="titlepage">
<h3><a name="d0e365" id="d0e365"></a>Semantic error
#2: *it does not synthesize space in the list</h4>
</div>
<pre class="programlisting">
*it = 34;
*++it = 45;
*++it = 87;
</pre>
<p>This is one of the most common errors I've seen when people
start using the standard containers. I believe the intent here is
to have a list of three items. However, <tt class=
"varname">*it</tt> is illegal, not only because it doesn't refer to
<tt class="varname">lst</tt>, but even if it did, <tt class=
"varname">lst</tt> started out empty, and the dereference of any
iterator into an empty collection is illegal.</p>
<p>Since there are only three elements, the simplest way to create
this is:</p>
<pre class="programlisting">
lst.push_back(34);
lst.push_back(45);
lst.push_back(87);
</pre>
<p>Where <tt class="methodname">push_back()</tt> places the element
on the very end of the list. Note: there is an implicit conversion
of each of these numbers from type <tt class="type">int</tt> to
<tt class="type">double</tt>, which may or may not happen at
compile time.</p>
<p>Since <tt class="varname">it</tt> isn't actually needed until
the <tt class="literal">for</tt> loop, just declare it there.</p>
<p>Before doing so, I'm going to add the following <tt class=
"literal">typedef</tt> to the beginning of <tt class=
"function">main()</tt> for a little bit of defensive
programming:</p>
<pre class="programlisting">
typedef list&lt;double&gt; Collection;
</pre>
<p>The reason is that the iterator always has to match the type of
the collection, so if you need to change this, it only has to be
changed in one place. Now, one should pick a better name than
<tt class="classname">Collection</tt>; however, better names will
not include the word list or double, as that is what we are trying
to abstract away. Names should reflect what something is for, not
how it is implemented.</p>
<p>The <tt class="literal">typedef</tt> is placed inside <tt class=
"function">main()</tt> itself because no one outside of <tt class=
"function">main()</tt> cares about it. Always limit scope as much
as possible.</p>
<p>Putting this all together:</p>
<pre class="programlisting">
#include &lt;iostream&gt;
using std::cout;
using std::endl;
#include &lt;list&gt;
using std::list;
#include &lt;cstdlib&gt;  // for system(char const*)

int main() {
  typedef list&lt;double&gt; Collection;
  Collection lst;
  lst.push_back(34);
  lst.push_back(45);
  lst.push_back(87);

  for(Collection::iterator it = lst.begin();
      it != lst.end(); ++it)
    cout &lt;&lt; &amp;*it &lt;&lt; '\t' &lt;&lt; *it &lt;&lt; endl;

  system(&quot;pause&quot;);
  return 0;
}
</pre></div>
<div class="sect3" lang="en">
<div class="titlepage">
<h3><a name="d0e434" id="d0e434"></a>Planning for a
reasonable future</h4>
</div>
<p>At this point, we could be done. The above code works, is simple
and straightforward, and does the job requested.</p>
<p>However, if this were the foundation of a bigger project, I
might add a little more complexity for future flexibility. This is
ultimately a judgement call; do too little, and you have under
engineered the solution; do too much, and you have over engineered
it. That is why I say plan for a reasonable future, and not all
futures.</p>
</div>
<div class="sect3" lang="en">
<div class="titlepage">
<h3><a name="d0e441" id="d0e441"></a>Future: Data
driven initialization of <tt class="varname">lst</tt></h4>
</div>
<p>A future that I consider reasonable is one where the number of
initial elements may be larger than 3. <tt class=
"methodname">push_back()</tt> works fine for 3 elements. But what
about 30? Or 300?</p>
<p>Making it data driven is more scaleable. The data driven way is
to initialize the list from an array, as in:</p>
<pre class="programlisting">
static const Collection::value_type 
initialElements[] = {34, 45, 87,};
Collection lst(initialElements, 
initialElements + 3);
</pre>
<p>Note: I prefer using <tt class=
"varname">Collection::value_type</tt> over <tt class=
"type">double</tt> for the type of the elements in the array to
emphasize that the type here should correspond to the type of the
elements in <tt class="varname">lst</tt>. By <tt class=
"literal">typedef</tt>ing <tt class="classname">Collection</tt>, I
have self-documented that there is a relation between <tt class=
"varname">initialElements</tt>, <tt class="varname">lst</tt>, and
<tt class="varname">it</tt>. While iterators are not (necessarily)
pointers, pointers can be used in place of iterators, and
<tt class="classname">list</tt> has a templated constructor that
can take any type of input iterator. There still is the matter of
<tt class="literal">initialElements + 3</tt>. It is less error
prone to have the computer count the number of elements than for me
to count it. Using a C idiom:</p>
<pre class="programlisting">
Collection lst(initialElements,
        initialElements
          + sizeof initialElements
                 / sizeof initialElements[0]);
</pre>
<p>While I can do this without any helper functions, it is still
error prone. If <tt class="varname">initialElements</tt> was a
pointer instead of an array (which could happen if this code had
changed to pass in a pointer to an array of initial values), the
calculation would be wrong, yet the code would still compile and
run. To solve this, I have a set of templates that always gets this
calculation right:</p>
<pre class="programlisting">
#include &lt;cstddef&gt;  // for size_t
template &lt;typename T, size_t N&gt;
inline size_t size(T (&amp;)[N]) { return N; }
template &lt;typename T, size_t N&gt;
inline T* begin(T (&amp;a)[N]) { return a; }
template &lt;typename T, size_t N&gt;
inline T* end(T (&amp;a)[N]) { return a + N; }
</pre>
<p>Basically, they make an array look like a collection, with
<tt class="methodname">begin()</tt>, <tt class=
"methodname">end()</tt>, and <tt class="methodname">size()</tt>
functions (although they are free functions, not member functions).
The array is passed in by reference to these functions, and uses
template argument deduction to determine the number of elements in
the array. Note: if we pass in a pointer instead of an array, it is
a compile time error. In this case, they are used as follows:</p>
<pre class="programlisting">
Collection lst(begin(initialElements),
               end(initialElements));
</pre>
<p>Note: technically, instead of <tt class=
"literal">begin(initialElements)</tt> as the first iterator, I
could have passed in <tt class="varname">initialElements</tt>
directly, as the array will decay into a pointer when passed by
value. I prefer the former, both as it is self-documenting, and I
get an extra level of checking that <tt class=
"varname">initialElements</tt> is an array. Combining all of this,
we get the following solution:</p>
<pre class="programlisting">
#include &lt;iostream&gt;
using std::cout;
using std::endl;
#include &lt;list&gt;
using std::list;
#include &lt;cstdlib&gt;  // for system(char const*)
#include &lt;cstddef&gt;  // for size_t
template &lt;typename T, size_t N&gt;
inline size_t size(T (&amp;)[N]) { return N; }
template &lt;typename T, size_t N&gt;
inline T* begin(T (&amp;a)[N]) { return a; }
template &lt;typename T, size_t N&gt;
inline T* end(T (&amp;a)[N]) { return a + N; }

int main() {
  typedef list&lt;double&gt; Collection;
  static const Collection::value_type initialElements[] = {34, 45, 87,};
  Collection lst(begin(initialElements), end(initialElements));
  for(Collection::iterator it = lst.begin(); it != lst.end(); ++it)
    cout &lt;&lt; &amp;*it &lt;&lt; '\t' &lt;&lt; *it &lt;&lt; endl;
  system(&quot;pause&quot;);
  return 0;
}
</pre></div>
</div>
<div class="sect2" lang="en">
<div class="titlepage">
<h3><a name="d0e522" id="d0e522"></a>From Mick Brooks
<tt class="email">&lt;<a href=
"mailto:michael.brooks@physics.ox.ac.uk">michael.brooks@physics.ox.ac.uk</a>&gt;</tt></h3>
</div>
<p>This is my first attempt at an SCC solution, so I may learn more
than our student. Anyway, here goes:</p>
<p>Trying to compile your code, GCC flags the line with the for
loop as an error. Trying to evaluate <tt class="literal">it &lt;
lst.end()</tt> is the problem, since the <tt class=
"classname">list::iterator</tt> is a bidirectional iterator, and so
doesn't have the less-than operation defined. It would work if we
used a vector container instead of the list, since <tt class=
"classname">vector::iterator</tt> is a random-access iterator which
is more powerful, and has more operations defined for it, including
one for less-than. In order to make this loop do what was intended,
we can look to a C++ idiom for help: use <tt class=
"literal">!=</tt> as the loop condition check. This operation is
defined for all of the five iterator categories, and so will work
for iterators over any of the standard container types. The loop
still looks unusual, because the idiomatic style is to make use of
the initialiser part of the <tt class="literal">for</tt>-loop
syntax. The maintenance programmer (which could be you in about 6
months) will see that combination of <tt class="literal">(;</tt>
and will needlessly have to wonder if that's a mistake. Make it
explicit, and put in the initialization. This has the wonderful
side-effect of limiting the scope of the <tt class=
"varname">it</tt> variable. While we are here, we can notice that
you don't modify the value pointed to by the iterator <tt class=
"varname">it</tt>, and can make that explicit in the code by using
a <tt class="classname">const_iterator</tt> instead. So now the
loop looks like this:</p>
<pre class="programlisting">
for(list&lt;double&gt;::const_iterator it = lst.begin();
    it != lst.end(); ++it)
cout &lt;&lt; it &lt;&lt; '\t' &lt;&lt; *it &lt;&lt; endl;
</pre>
<p>which is made much clearer to a C++ programmer through its use
of the standard idioms.</p>
<p>Unfortunately, the code still won't compile; this time because
there is no output operator (<tt class="literal">&lt;&lt;</tt>)
defined for the <tt class="classname">const_iterator</tt> type. I
assume that the intention of <tt class="literal">cout &lt;&lt;</tt>
it was to print the address of the object pointed to by the
iterator. This might just happen to work if list iterators were
actually pointers, but they are more complicated than that. What I
think you want here is <tt class="literal">&amp;*it</tt>, which is
the address-of operator applied to the result of dereferencing the
iterator, and gives us the memory address of the double that is
pointed to by the iterator.</p>
<p>Well, now the code will compile, but running it gives a
segmentation fault on my Linux machine, which tells us that we
aren't finished yet. This is due to using an iterator to access
memory that we don't own, and means that there's some work to be
done on understanding how to create our list. In the first line of
<tt class="function">main()</tt>, you define the iterator
<tt class="varname">it</tt> but don't give it a value, which leaves
it in an unknown state. Trying to dereference that iterator is a
big mistake, which causes the segfault. The iterator would have to
be made to point to a valid member of a list before we can use it,
but there are no valid members of an empty list. We have to find
another way of populating the list. My preferred solution would be
to use <tt class="methodname">push_back</tt> on the list and drop
the iterator altogether, which leaves us with the following working
code:</p>
<pre class="programlisting">
#include &lt;iostream&gt;
using std::cout;
using std::endl;
#include &lt;list&gt;
using std::list;

int main() {
  list&lt;double&gt; lst;
  lst.push_back(34);
  lst.push_back(45);
  lst.push_back(87);

  for(list&lt;double&gt;::const_iterator it = lst.begin();
      it != lst.end(); ++it)
    cout &lt;&lt; &amp;*it &lt;&lt; '\t' &lt;&lt; *it &lt;&lt; endl;

  system(&quot;pause&quot;); // if we must...
  return 0;
}
</pre>
<p>As an aside, if you really want to use an iterator interface to
do the job, you'll have to learn about Insert Iterators. A
<tt class="classname">back_insert_iterator</tt> will call
<tt class="methodname">push_back</tt> for you, and you can then
fill the list with the iterator interface, like this:</p>
<pre class="programlisting">
#include &lt;iterator&gt;
using std::back_insert_iterator;
// other includes, as before

int main() {
  list&lt;double&gt; lst;
  back_insert_iterator&lt;list&lt;double&gt; &gt; it(lst);
  *it = 34;
  *it++ = 45;
  *it++ = 87;
  // ... as before
</pre>
<p>I'm not sure what this buys you though, except that you get to
learn about the added confusion that <tt class="literal">it++</tt>
and <tt class="literal">++it</tt> are no-ops, and so both the
increments in that snippet could be dropped.</p>
</div>
<div class="sect2" lang="en">
<div class="titlepage">
<h3><a name="d0e607" id="d0e607"></a>From Terje
Sletteb&oslash; <tt class="email">&lt;<a href=
"mailto:tslettebo@broadpark.no">tslettebo@broadpark.no</a>&gt;</tt></h3>
</div>
<p>First, some comments about style, before we examine correctness.
The program starts with:</p>
<pre class="programlisting">
#include &lt;iostream&gt;
using std::cout;
using std::endl;
#include &lt;list&gt;
using std::list;
</pre>
<p>Now, in this case, for a source file (not header file), it's
generally safe to do:</p>
<pre class="programlisting">
using namespace std;
</pre>
<p>instead of the using-declarations. Any name clashes will be
flagged by the compiler, and you may save yourself considerable
amounts of typing this way. I know this is a hot topic, but anyway.
Another alternative is explicit qualification of the names in the
code: <tt class="literal">std::cout &lt;&lt; it</tt>.</p>
<p>The code has a weird indentation, with some lines indented a
couple of places for no apparent reason at all. This gives the code
a messy/untidy look, and clarity is important; unclear code is a
good breeding ground for bugs. Moving beyond pure layout, there are
some other general comments that can be made:</p>
<div class="orderedlist">
<ol type="1">
<li>
<p>It's a good idea to initialise the variables at the point of
declaration, if possible. This avoids the chance of accidentally
accessing an uninitialised variable. This is actually happening in
the code (and that's just one of the bugs): <tt class=
"varname">it</tt> is declared but not initialised, and then
subsequently used, leading to undefined behaviour.</p>
</li>
<li>
<p>Also, you should not &quot;reuse&quot; a variable for a different purpose,
as the variable <tt class="varname">it</tt> is in the code (it's
reused for the loop) (this is a bad case of reuse. ;) ).</p>
</li>
<li>
<p>Keep scopes as small as possible. If <tt class="varname">it</tt>
is declared in the <tt class="literal">for</tt>-loop, it only
exists in the loop, and you avoid accidentally using it after it
should no longer be used.</p>
</li>
<li>
<p>Moreover, you may want to use <tt class=
"classname">const_iterator</tt>, rather than <tt class=
"classname">iterator</tt>, when the code doesn't alter the
container (despite what Scott Meyers may say about preferring
<tt class="classname">iterator</tt>).</p>
</li>
<li>
<p>The naming used in the code is not very good, to say the least.
Names should generally be chosen based on the role of the variable,
not its type (although some Hungarian Notation like <tt class=
"varname">..._ptr</tt> might be acceptable, as it reminds us that
it requires a different usage). In the code, the words <tt class=
"varname">lst</tt> and <tt class="varname">it</tt> are used. Avoid
acronyms and abbreviations, unless the name might be rather long
without it, or the acronym or abbreviation is well-known. However,
this code doesn't just have bad style, it also have some real bugs
(including the one mentioned in point 1, above):</p>
</li>
<li>
<p>When the iterator it is assigned to, even if it had been a valid
iterator to the start of the container, the container is empty, so
the iterator is the past-the-end iterator. Assigning to and
incrementing <tt class="varname">it</tt> leads again to undefined
behaviour.</p>
<p>The problematic assumption in the code seems to be that the
programmer thinks assigning to the iterator, and incrementing the
iterator, will insert the values into the container. It is not so.
You have to explicitly insert the values using the container
object, for example with <tt class="methodname">push_back</tt>:</p>
<pre class="programlisting">
lst.push_back(34):
lst.push_back(45);
lst.push_back(87);
</pre></li>
<li>
<p>One small thing to note here is that there's an integer to
floating point conversion when the values are inserted, but it
gives the expected behaviour. To avoid it (and its possible
overhead), you might use values of type double, instead: 34.0,
etc.</p>
</li>
<li>
<p>The list iterator doesn't have the less-than operator defined,
only equal and not equal, so the program won't compile as it is. It
may be recommended to always use not equal, even for containers
supporting less-than, for consistency, and stronger post-conditions
to the loop (detecting bugs earlier).</p>
</li>
<li>
<p>The body of the <tt class="literal">for</tt> loop tries to print
out the iterator, which fails, as there isn't a stream operator
defined for it. The intention was possibly to write out the index
of each element. This isn't available from the list, so you have to
track it separately, if you need it.</p>
</li>
<li>
<p>One final point to note is that <tt class=
"function">system()</tt> is not a standard C++ function (and
there's no other header to include it in the program), so even if
the right header was included, the program wouldn't be portable to
systems lacking that function.</p>
</li>
<li>
<p><tt class="classname">endl</tt> is a manipulator that, in
addition to writing a newline to the stream, also flushes it, and
you may want to avoid needless flushing, especially if it's done a
lot. The output stream is flushed before any input, anyway. (Ok, so
<span class="bold"><b>this</b></span> was the final note.) Let's
say the list is a list of percentages. Here's a possible corrected
version of the program (the using part has several correct
possibilities, as mentioned):</p>
<pre class="programlisting">
#include &lt;iostream&gt;
#include &lt;list&gt;
int main() {
  std::list&lt;double&gt; percent_list;
  percent_list.push_back(34.0);
  percent_list.push_back(45.0);
  percent_list.push_back(87.0);
  for(percent_list_type::const_iterator it
                       = percent_list.begin();
      it!=percent_list.end(); ++it)
    std::cout &lt;&lt; *it &lt;&lt; '\n';
}
</pre></li>
</ol>
</div>
<p>This corrects the problems mentioned in points 1-11.</p>
<p>If you thought I would stop here, you don't know me well enough.
;) Let's step back, and try to see what is the intent of the code.
The code should express the <span class="bold"><b>intent</b></span>
as clearly as possible. Well, does it? Let's find out. The code
inserts few values into a list, and then prints them out. The code
above says quite a bit more than this. One thing that is commonly
mentioned is to use <tt class="function">for_each</tt>, rather than
<tt class="literal">for</tt>, in such situations. However, using
only the standard library, you need to then create another class to
do the printing. This isn't necessarily an improvement, as you
can't define the class at the point of use. However, as Kevlin
Henney shows in his &quot;Omit Needless Code&quot; article, there are several
alternatives to printing out the values. One is to use stream
iterators:</p>
<pre class="programlisting">
typedef std::ostream_iterator&lt;double&gt; out;
std::copy(percent_list.begin(),
          percent_list.end(),
          out(std::cout,&quot;\n&quot;));
</pre>
<p>This makes it rather more succinct. Now, the code focuses on
<span class="bold"><b>what</b></span> to do - printing or copying
the values to the output stream - rather than <span class=
"bold"><b>how</b></span> to do it.</p>
<p>If you need more advanced formatting (such as enclosing each
value in braces), this won't do, though. Fortunately, there are
libraries that allow us to create function objects on the fly,
usable with algorithms, such as Boost.Lambda [1]. With it, we may
substitute the above with:</p>
<pre class="programlisting">
std::for_each(percent_list.begin(),
              percent_list.end(),
              std::cout &lt;&lt; _1 &lt;&lt; &quot;\n&quot;);
</pre>
<p>That takes care of the printing. What about the insertion of
values? That looks rather repetitive, doesn't it? Well, Boost can
again help us, here, with the Assignment library [2]:</p>
<pre class="programlisting">
percent_list+=34.0,45.0,87.0;
</pre>
<p>Here's the last revised version of the code:</p>
<pre class="programlisting">
#include &lt;iostream&gt;
#include &lt;list&gt;
#include &lt;algorithm&gt;
#include &lt;boost/assign/std/list.hpp&gt;
#include &lt;boost/lambda/lambda.hpp&gt;
using boost::assign::operator+=;
using boost::lambda::_1;

int main() {
  std::list&lt;double&gt; percent_list;
  percent_list+=34.0, 45.0, 87.0;
  std::for_each(percent_list.begin(),
                percent_list.end(),
                std::cout &lt;&lt; _1 &lt;&lt; &quot;\n&quot;);
}
</pre>
<p>Now, there's no fluff; the code states what it does (at least
when you learn the abstractions involved). A further improvement
might be if there were overloaded versions of the standard
algorithms taking containers, rather than iterators:</p>
<pre class="programlisting">
std::for_each(percent_list,
              std::cout &lt;&lt; _1 &lt;&lt; &quot;\n&quot;):
</pre>
<p>David wasn't kidding when he said the code contains &quot;various
mistakes for such a few lines&quot;... This small snippet also turned
out to be a good opportunity to demonstrate some software
development fundamentals, as well as more advanced techniques.</p>
<p>[1] <a href="http://www.boost.org/libs/lambda/doc/index.html"
target=
"_top">http://www.boost.org/libs/lambda/doc/index.html</a></p>
<p>[2] Available in the CVS, but not yet in the current
release.</p>
</div>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<h2><a name="d0e761" id="d0e761"></a>The Winner of
SCC 29</h2>
</div>
<p>The editor's choice is: <span class="bold"><b>Mick
Brooks</b></span></p>
<p>Please email <tt class="email">&lt;<a href=
"mailto:francis@robinton.demon.co.uk">francis@robinton.demon.co.uk</a>&gt;</tt>
to arrange for your prize.</p>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<h2><a name="d0e773" id="d0e773"></a>Francis'
Commentary</h2>
</div>
<pre class="programlisting">
#include &lt;iostream&gt;
using std::cout
using std::endl

#include &lt;list&gt;
using std::list;
</pre>
<p>Let me start with a small style issue. I do not like
interspersing using declarations and headers. I like to see all the
<tt class="literal">#include</tt>s up front. Preferably I like to
see any user header files first (in alphabetical order) followed by
the necessary standard headers (also in alphabetical order).
Placing the user header files first avoids accidentally masking a
dependency that should have been in visible in the user header.
Placing the includes in alphabetical order just makes it easier to
check whether one has or has not been included.</p>
<p>While I notice, <tt class="classname">std::endl</tt> is not
required to be declared as a consequence of <tt class=
"literal">#include &lt;iostream&gt;</tt>, it usually is but only
because <tt class="classname">iostream</tt> normally drags in
<tt class="classname">ostream</tt>.</p>
<p>When it comes to <tt class="literal">using</tt> declarations and
using directives I think we should tend to use fully elaborated
names (i.e. do not use either <tt class="literal">using</tt>
directives or <tt class="literal">using</tt> declarations) until
the user knows enough to understand the implications of each. I
know this is contrary to what I did in 'You Can Do It!' but the
motive in that book was to get inexperienced programmers writing
code so I was willing to make some sacrifices. However, even there
I started with fully elaborated names and required that they be
used in all reader written header files.</p>
<pre class="programlisting">
int main() {
  list&lt;double&gt;::iterator it;
    list&lt;double&gt; lst;
</pre>
<p>I cannot say that I am enamoured by the choice of <tt class=
"varname">it</tt> as a name for an iterator but I can live with it,
but the choice of <tt class="varname">lst</tt> as a variable is
beyond my tolerance levels (well it is today). And what is that
extra indent for? Indents without purpose only serve to
confuse.</p>
<p>Up until now, I have just being cantankerous. Now it is about to
get serious:</p>
<pre class="programlisting">
*it = 34;
</pre>
<p>Do you know if <tt class=
"classname">list&lt;T&gt;::iterator</tt> has a default constructor?
No, neither do I and I do not care to take time to look it up.
Whether it does or not, <tt class="literal">*it</tt> is surely
introducing undefined behaviour because <tt class="varname">it</tt>
has never been initialised to point to any storage.</p>
<p>And now it gets worse:</p>
<pre class="programlisting">
*++it = 45;
  *++it =87;
</pre>
<p>More purposeless indentation coupled with incrementing what is,
at best, an iterator that points nowhere. And only now does the
student make any attempt to relate it to <tt class=
"varname">lst</tt>. Had the program no had multiple instances of
undefined behaviour the next line would have been perfectly OK,
just not exactly the idiomatic way to do it.</p>
<pre class="programlisting">
it = list.begin();
</pre>
<p>Time to wind back to the beginning and write the code properly
by avoiding early or unnecessary declarations.</p>
<pre class="programlisting">
#include &lt;iostream&gt;
#include &lt;list&gt;

typedef std::list&lt;double&gt; list_of_double;

int main() {
  list_of_double data;
</pre>
<p>Note that there are no using declarations, but I have used a
typedef. That is often a much more useful tool, and one that
provides a modicum of documentation. In fact it is the exact
reverse of <tt class="literal">using</tt> declarations because it
adds information (not much in this case, but the problem is pretty
abstract) rather than removing it (the library that a name belongs
to).</p>
<p>Next the list starts empty so there is nowhere to store values.
My preferred choice is to use <tt class=
"methodname">push_back()</tt>, however we could have created the
object data is bound to with three default initialised nodes by
changing the definition to <tt class="literal">list_of_double
data(3);</tt>. Sticking with my preferred option we get:</p>
<pre class="programlisting">
  data.push_back(34);
  data.push_back(45);
  data.push_back(87);
</pre>
<p>The reason that I prefer this option is because it makes it very
clear to even the rawest novice that data has nothing in it until
we start pushing things in. If teaching, I would break off here and
have a brief discussion as to what <tt class=
"methodname">push_back()</tt> does.</p>
<p>Having created a list of values, I am ready to write them
out:</p>
<pre class="programlisting">
  for(list_of_double::iterator iter
                                = data.begin()
      iter != data.end(); ++iter) {
</pre>
<p>You did notice that the student had used the wrong comparison?
<tt class="classname">std::list::iterator</tt> is not a random
access iterator and so values of it are not ordered. We simply
cannot use a less than comparison. The only thing that will work is
to keep going until equality with the end marker is achieved. Less
than will work for most of the sequence containers but not for this
one. Comparison for inequality is idiomatic for C++, those that
want to do something else should understand why sticking with
idioms is helpful.</p>
<pre class="programlisting">
    std::cout &lt;&lt; &amp;*iter &lt;&lt; '\t' &lt;&lt; *iter
              &lt;&lt; '\n';
</pre>
<p>I am guessing that the student wants to see the address used to
store the value. If he didn't then he is completely out of luck
because there is no requirement that a value of a <tt class=
"classname">std::list::iterator</tt> object be acceptable to an
<tt class="classname">ostream</tt> object. The standard technique
for getting the address of an object in a container is to apply the
address-of operator to the dereferenced value of the iterator for
the object; another idiom of modern C++.</p>
<p>Another feature is that I do not use <tt class=
"classname">std::endl</tt> unless I actually want to force both an
end-of-line and a flush to output. I only need an end-of-line so I
use the correct character for that; <tt class=
"literal">'\n'</tt>.</p>
<p>Now to finish:</p>
<pre class="programlisting">
  }
  std::cout.flush();
  std::cin.get();
  return 0;
}
</pre>
<p>Now I force the flush by calling the correct function. I don't
want to hunt around to see which header declares <tt class=
"function">system()</tt> and I certainly do not want to introduce
that kind of system dependence into my code unless I really have
to.</p>
<p>There are several other things that I might do to polish this
program a bit, but I think the above will do. Now I wonder how the
rest of you got on, and how many things I missed. The sad thing
about much of the code we see here is that it shows just how badly
instructors are explaining what is happening. Most of the code we
publish comes from students who really want to get it right rather
than ones who went to sleep during the lectures. The kind of errors
they make expose fundamental misunderstanding of C, C++ etc.</p>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<h2><a name="d0e906" id="d0e906"></a>Student Code
Critique 31</h2>
</div>
<p>(Submissions to <tt class="email">&lt;<a href=
"mailto:scc@accu.org">scc@accu.org</a>&gt;</tt> by November
10th)</p>
<p>Here is a program Francis collected which is riddled with poor
design, naming, etc. as well as the actual problem:</p>
<p><span class="emphasis"><em>I'm getting a &quot;parse error before
<tt class="literal">else</tt>&quot; at the line indicated by the
arrow</em></span></p>
<pre class="programlisting">
void IS_IT_A_DDR(string&amp; mtgrec,
                 string&amp; temprec,int&amp; ddrrc) {
  string Day2=&quot;SunMonTueWedThuFriSat&quot;;
  string Daytoken=&quot;0123456&quot;;
  int badday=0;
  if (mtgrec.size() &lt; 8) {
    ddrrc=0;
    return;
  }
  for (int i=0; i &lt;= 6; i++) {
    if (mtgrec.substr(0,3)
                == Day2.substr((i+1)*3-3,3)) {
      if ((mtgrec.substr(3,1) == &quot;0&quot;)
             || (mtgrec.substr(3,1) == &quot;1&quot;)) {
        if ((mtgrec.substr(7,1)).
          find_first_of(&quot;BCLMOPSTW*&quot;) != -1) {
      temprec=Daytoken.substr(i,1)
                           + mtgrec.substr(1);
      ddrrc=1;
      return;
      }
        else {
      ddrrc=2;
      return;
      }
    else { &lt;&lt;&lt; compiler diagnostic
      ddrrc=3;
      return;
    }
    }
  }
  else badday++;
  }
  if (badday == 7) {
    ddrrc=4;
    return;
  }
  else ddrrc=5;
  return;
}
</pre></div>
</p>
<p><strong>Notes:</strong>&nbsp;</p>
<p><em>More fields may be available via dynamicdata ..</em></p>
</div>
</channel>
</rss>
