Correct C++ tutorial part 4 "Decisions & conditions" available (Windows, mingw/msvc/std)

[Alf P. Steinbach]

The fourth part of my attempted Correct C++ tutorial is now available,
although for now only in Word format (use free Open Office if no Word),
and also, it's not yet been reviewed at all -- comments welcome!

"Decisions & conditions"
<url: http://home.no.net/dubjai/win32cpptut/w32cpptut_01_04.doc>

Different from before I don't expect that this part contains mental food
and technical points that we can strongly disagree about, so I'm mainly
inviting comments from those who are in the process of learning C++, or
who are thinking about starting with C++.

As before, however, the point of inviting comments is to _fix_ anything
incorrect, or the presentation, or whatever; your input is valuable,
even if you're an experienced C++ programmer! ;-)

The first two parts, "Hello, world!" and "Variables", are available
both as Word docs and HTML at

<url: http://home.no.net/dubjai/win32cpptut/html/>

The third part is referred to from that page, but only as a Word doc.

Thanks in advance,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Karthik Kumar]

Alf P. Steinbach wrote:

The fourth part of my attempted Correct C++ tutorial is now available,
although for now only in Word format (use free Open Office if no Word),
and also, it's not yet been reviewed at all -- comments welcome!

"Decisions & conditions"
<url: http://home.no.net/dubjai/win32cpptut/w32cpptut_01_04.doc>

Different from before I don't expect that this part contains mental food
and technical points that we can strongly disagree about, so I'm mainly
inviting comments from those who are in the process of learning C++, or
who are thinking about starting with C++.

As before, however, the point of inviting comments is to _fix_ anything
incorrect, or the presentation,

Here is my comment (presentation aspect) regarding the same.

In Section 3 , titled - "Use !, && and || for logical NOT, AND and OR."
here is a sample code fragment.

if( command == "H" || command == "h" || command == "?" ) {
// This is a help command.
std::cout << helpText << std::endl;
}

It would be nice, if you orient the style of putting the constant
on the l.h.s in case of a conditional expression ( as in this case).
That can obviously help trap errors out of typos of replacing '=='
by '=' , (say, command = "H" ).

That should really a really good programming tip to be mentioned
at this stage.

--
Karthik.

[Alf P. Steinbach]

* Karthik Kumar:

In Section 3 , titled - "Use !, && and || for logical NOT, AND and OR."
here is a sample code fragment.

if( command == "H" || command == "h" || command == "?" ) {
// This is a help command.
std::cout << helpText << std::endl;
}

It would be nice, if you orient the style of putting the constant
on the l.h.s in case of a conditional expression ( as in this case).
That can obviously help trap errors out of typos of replacing '=='
by '=' , (say, command = "H" ).

That should really a really good programming tip to be mentioned
at this stage.

Thanks for that suggestion.

At the very least the fact that you mention it means I should discuss
that more clearly, and/or in one place, and/or perhaps yet again in this
fourth part.

In part 3 I discussed that problem and introduced two devices that tend
to catch most of the '=' errors: a hack that ensures that an 'if' (or
'while') condition is of 'bool' type, and use of 'const'.

Of course that doesn't catch 100% of cases, and cannot even in
principle, AFAICS, catch e.g. that error in a conditional operator, and
'const' is of limited utility until user-defined functions are
discussed.

However, in my experience the problem is sufficiently reduced that
readability of the code then weights more: one shouldn't, IMO, willingly
do over and over the compiler's job, especially when readability suffers
as a result, but find some way (such as the abovementioned hack and use
of 'const') to make the compiler do the job -- to _automate_ things.

Cheers, and thanks again,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Peter Koch Larsen]

"Karthik Kumar" <ka*******************@yahoo.com> skrev i en meddelelse
news:41f3826a$1@darkstar...
[snip]

Here is my comment (presentation aspect) regarding the same.

In Section 3 , titled - "Use !, && and || for logical NOT, AND and OR."
here is a sample code fragment.

if( command == "H" || command == "h" || command == "?" ) {
// This is a help command.
std::cout << helpText << std::endl;
}

It would be nice, if you orient the style of putting the constant
on the l.h.s in case of a conditional expression ( as in this case).
That can obviously help trap errors out of typos of replacing '=='
by '=' , (say, command = "H" ).
Hi Karthlik

I find command == "H" far more readable than "H" == command and thus prefer
the first method. Most - if not all - compilers will warn you if you try to
assign rather than compare. If that was not the case, you could persuade me
to write it your way.

/Peter

That should really a really good programming tip to be mentioned
at this stage.

--
Karthik.

[Karthik Kumar]

Peter Koch Larsen wrote:

"Karthik Kumar" <ka*******************@yahoo.com> skrev i en meddelelse
news:41f3826a$1@darkstar...
[snip]

Here is my comment (presentation aspect) regarding the same.

In Section 3 , titled - "Use !, && and || for logical NOT, AND and OR."
here is a sample code fragment.

if( command == "H" || command == "h" || command == "?" ) {
// This is a help command.
std::cout << helpText << std::endl;
}

It would be nice, if you orient the style of putting the constant
on the l.h.s in case of a conditional expression ( as in this case).
That can obviously help trap errors out of typos of replacing '=='
by '=' , (say, command = "H" ).

Hi Karthlik

I find command == "H" far more readable than "H" == command and thus prefer
the first method.

I felt the same, until I was oriented to this style.

Most - if not all - compilers will warn you if you try to
assign rather than compare. If that was not the case, you could persuade me
to write it your way.

Well- here is a test code.

int main() {
int a;
if (a = 4) {
// do nothing
}

}
I primarily use the gnu c/c++ compiler, although i use intel's
compiler as well .

As can be seen below, g++ does not seem to warn me,
but icc does.

$ g++ -Wall -ansi -pedantic if_test.cpp
<< no warnings >>

$ icc -Wall if_test.cpp
if_test.cpp(3): warning #187: use of "=" where "==" may have been intended
if (a = 4) {
^

if_test.cpp(2): remark #593: variable "a" was set but never used
int a;
^

The point is, you are dependent on the compiler
to identify the error and there is at least one compiler,
that fails to help in this case. Hence for a tutorial, it
would be a nice idea to orient this practice. Now whether anyone
picks this one up is a matter of personal choice.

--
Karthik.

[Alf P. Steinbach]

* Karthik Kumar:

Well- here is a test code.

int main() {
int a;
if (a = 4) {
// do nothing
}

}

I primarily use the gnu c/c++ compiler, although i use intel's
compiler as well .

As can be seen below, g++ does not seem to warn me,
but icc does.

$ g++ -Wall -ansi -pedantic if_test.cpp
<< no warnings >>

$ icc -Wall if_test.cpp
if_test.cpp(3): warning #187: use of "=" where "==" may have been intended
if (a = 4) {
^

if_test.cpp(2): remark #593: variable "a" was set but never used
int a;
^

The point is, you are dependent on the compiler
to identify the error

Well, not in this particular case. You could use the hack introduced
in part 3 in the section that discusses this problem. OK, it's not
formally correct to redefine keywords, but...
template<typename T> inline T ifCondition( T x );
template<> inline bool ifCondition( bool x ){ return x; }
#define if( expression ) if( ::ifCondition( expression ) )

int main() {
int a;
if (a = 4) {
// do nothing
}
}
I don't have the Intel compiler, but g++ 3.4.2 then reports

x.cpp:1: warning: inline function `T ifCondition(T) [with T = int]' used
but never defined
C:\WINDOWS\TEMP/ccM5baaa.o(.text+0x39):x.cpp: undefined reference to
`int ifCondition<int>(int)'
collect2: ld returned 1 exit status

Similarly, Visual C++ 7.1. reports

x.obj : error LNK2019: unresolved external symbol "int __cdecl
ifCondition<int>(int)" (??$ifCondition@H@@YAHH@Z) referen
ced in function _main
x.exe : fatal error LNK1120: 1 unresolved externals

As a refinement you can add a compile-time assert to the mix.

And when you really do want to do the assignment you can
write 'if( !!(a = 4) ) { ... }'.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Sigurd Stenersen]

Karthik Kumar wrote:

Peter Koch Larsen wrote:

I find command == "H" far more readable than "H" == command and
thus prefer the first method.

I felt the same, until I was oriented to this style.
int a;
if (a = 4) {
}

As can be seen below, g++ does not seem to warn me,
but icc does.

$ g++ -Wall -ansi -pedantic if_test.cpp
<< no warnings >>

Does g++ have an option for increasing the warning level or something
similar ?

It seems to me that it's better to make just one change to the make file
than to rely on the programmer always remembering to use an unnatural coding
style...

And if the compiler doesn't have an option to flag this kind of error with a
warning, this is a strong indication that the compiler has plenty of other
weaknesses as well. In that case the solution is simple - use a different
compiler.
--

Sigurd
http://utvikling.com

[chris]

Karthik Kumar wrote:

Peter Koch Larsen wrote:

"Karthik Kumar" <ka*******************@yahoo.com> skrev i en
meddelelse news:41f3826a$1@darkstar...
[snip]

Here is my comment (presentation aspect) regarding the same.

In Section 3 , titled - "Use !, && and || for logical NOT, AND and OR."
here is a sample code fragment.

if( command == "H" || command == "h" || command == "?" ) {
// This is a help command.
std::cout << helpText << std::endl;
}

It would be nice, if you orient the style of putting the constant
on the l.h.s in case of a conditional expression ( as in this case).
That can obviously help trap errors out of typos of replacing '=='
by '=' , (say, command = "H" ).

Hi Karthlik

I find command == "H" far more readable than "H" == command and thus
prefer the first method.

I felt the same, until I was oriented to this style.

Most - if not all - compilers will warn you if you try to assign
rather than compare. If that was not the case, you could persuade me
to write it your way.

Well- here is a test code.

int main() {
int a;
if (a = 4) {
// do nothing
}

}
I primarily use the gnu c/c++ compiler, although i use intel's
compiler as well .

As can be seen below, g++ does not seem to warn me,
but icc does.

$ g++ -Wall -ansi -pedantic if_test.cpp
<< no warnings >>

I'm not sure which version of g++ you are using. I have 3.3.3 installed,
and I get:

temp.cc: In function `int main()':
temp.cc:3: warning: suggest parentheses around assignment used as truth
value

Chris