grumpy

I agree that Herbert Schildt's books are written in a good style, and are easy to follow. Hence they tend to get good reviews from people on the basis of their readability.

Unfortunately, the books are also technically VERY inaccurate so tend to be reviewed poorly by people who actually have experience with C or C++. They also tend to be reviewed poorly by people who attempt to actually use C or C++ (i.e. write code and send it to a compiler), as even basic examples in the books are rejected by the majority of C or C++ compilers. Some language features are described incorrectly, and examples make heavy use of vendor-specific functions and header files that have never been part of any C or C++ standard.

I've never read any of the "Teach yourself" series of books, or reviews of them, so won't comment on those.

Duck

This is not the case with the 'teach yourself' books, there is no vendor specific functions (other standard microsoft modules, like for for example those which contain strcpy/memcpy etc etc (does that even count?)), and all the code can downloaded from the website, copied into Visual Studio, and compiles perfectly.

grumpy

Duck, I don't mean to give offence, but if the level of understanding you have exhibited in this post is representative of what you have learnt from the "Teach Yourself" books, then those books are not a good learning tool.

The term "standard microsoft modules" is a contradiction in the context of C or C++. The fact you are even using such a term shows that you do not understand the role of a standard relative to a vendor's compiler. The C and C++ standards are the yardstick by which correctness of compilers (including those from Microsoft) is measured. The behaviour of compilers is not a yardstick for correctness of the standard.

strcpy() and memcpy(), as it happens, are not "standard microsoft modules". They were originally specified in early (pre-standard) C specifications, standardised in the 1989 C standard, supported by C++ by virtue of backward compatibility to the 1989 C standard, and their definitions were included in the 1999 C standard.

The statement that the code can be "copied into Visual Studio, and compiles perfectly" does not mean that the code will work with all standard-compliant compilers. I would view any book that claims on one hand that they describe standard C or C++, and then state that their sample code works with a specific compiler, with suspicion. Simply because any one compiler, no matter how good (and recent versions of Microsoft compilers are quite reasonable in terms of standard compliance), is not a valid test of code. All compilers support extensions.

Duck

grumpy. No offense taken, (although I deserve to be offended!).

Yes that was a stupid post of mine !! lol. I wrote it without thinking (very late at night), lol. I'm not quite as stupid as that post made me look lol lol lol, but pretty stupid still lol.

DaWei

One of the perennially occurring conflicts regarding the production of C/C++ code revolves around the idea of what is correct and what is not correct. The standards define correctness for the areas they address. They choose not to address all aspects (except, perhaps, by excluding them specifically). This is not a weakness, it is a strength. Languages which attempt to do otherwise are the product limited thinking.

How does one define a standard way to "clear the screen" when the "screen" may be a hard-copy device? The fact that a large number of budding programmers see only a world of desktop/laptop machines, with a tiny number (relatively speaking) of operating systems and compilers exacerbates the problem.

Compilers are built for a specific set of hardware coupled with (maybe) a specific set of tools (an OS). To accomodate this they use proprietary extensions or some form of (hopefully) successful translation (drivers).

If some use of the language has been characterized as producing unspecified or undefined behavior, then one needs to take that into account. The fact that compiler/platform set #1 produces correct results is no guarantee that the code will produce correct results on set #2. One might wind up with a machine that is a molten slag heap.

All this does not mean that one should never write non-portable code. In many instances it is absolutely necessary, since the standard deliberately doesn't cover every eventuality. The upshot is that one needs to think as rationally as possible. If one needs to write non-portable code, one needs to realize that one is doing so, and recognize it as such. Document it carefully for those who follow. If one writes code that results in undefined behavior, one should find a way to rewrite it.

If learning materials ignore these issues and plod blindly ahead on the basis of correct operation with set #1, then they are doing a disservice, regardless of how many times their author has kissed the blarney stone. The author's frequent trips to the bank to make large deposits does not guarantee readers the same result.

__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code.
Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers