Journal Articles

CVu Journal Vol 16, #1 - Feb 2004 or Letters to the Editor

Browse in :

All > Journals > CVu > 161 (8)
All > Journal Columns > LettersEditor (132)
All of these categories

Options:: View Article Map; View Archives

Note: when you create a new publication type, the articles module will automatically use the templates user-display-[publicationtype].xt and user-summary-[publicationtype].xt. 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/yourtheme/modules/articles . The templates will get the extension .xt there.

do...while

Site Administrator

07 February 2004 19:37:48 +00:00

What can be said about C’s everyday do...while loop? It just does something while some condition holds. End of story, right?

No, of course not. That would make the title of this small article silly, so let’s cover two topics.

Code in Comments

Site Administrator

01 February 2004 19:38:18 +00:00

We have all seen comments in source files which look more like executable code than documentation.

The first line in the body of the for loop below is such a comment: you might expect to be able to remove the leading slashes and have code which compiles and runs, but functions slightly differently.

What did the author of this comment intend?

Example 0

for (Surfaces::iterator sf = surfaces.begin();
     sf != surfaces.end();
     ++sf) {
  // std::cout << "Drawing: " << *sf << "\n";
  sf->draw();
}

OK, I’m being disingenuous. I’m aware that the comment isn’t really a comment, it’s commented-out code. And, like any tolerant and capable programmer, by examining the surrounding context I can guess why this code has been commented out.

This article examines how to comment out code, then describes various problems which lead to code being commented out, before finally arguing that there’s often a better solution to these problems.

Comment on “Problem 11”

Site Administrator

01 February 2004 19:38:02 +00:00

The first step here in finding problems in the code is to identify the problem the code is trying to solve. The discussion in the C Vu article is basically about curiosities in the way in which the C++ standard library std::istream is defined, but I will make the perhaps unwarranted assumption that what the problem the code is really about is not the uses of std::istream, but rather, more generally, how to write a read routine that can effectively and safely capture data from an input stream. Actually as the first problem below illustrates neither of these issues can be effectively addressed without the other.

Student Code Critique Competition 26

Letter To The Editor

Administrator

26 June 2002 17:46:10 +01:00

The Wall

Administrator

03 June 2002 13:15:52 +01:00

Sort by Date Title