Can't think straight, is this hypocrisy or what, (intended flame war of languages) :P
-
"The problem with the preprocessor approach is that it provides an easy way for programmers to inadvertently add unnecessary complexity to a program. Many programmers using the #define and #typedef directives end up inventing their own sublanguage within the confines of a particular project. This results in other programmers having to go through the header files and sort out all of the #define and #typedef information to understand a program, which makes code maintenance and reuse almost impossible. An additional problem with the preprocessor approach is that it is very weak when it comes to type checking and validation. Java does not have a preprocessor. It provides similar functionality (#define, #typedef, and so on) to that provided by the C++ preprocessor, but with far more control. Constant data members are used in place of the #define directive, and class definitions are used in lieu of the #typedef directive. The end result is that Java source code is much more consistent and easier to read than C++ source code. Additionally, Java programs don't use header files; the Java compiler builds class definitions directly from the source code files, which contain both class definitions and method implementations. " I have spotted so much obvious biased statements towards java in this one book that I'm about to write a letter to the author asking him has he ever used C++ other than for Hello World programs || maybe did he just suck at it. IM PROUD TO BE A GMAIL;
-
"The problem with the preprocessor approach is that it provides an easy way for programmers to inadvertently add unnecessary complexity to a program. Many programmers using the #define and #typedef directives end up inventing their own sublanguage within the confines of a particular project. This results in other programmers having to go through the header files and sort out all of the #define and #typedef information to understand a program, which makes code maintenance and reuse almost impossible. An additional problem with the preprocessor approach is that it is very weak when it comes to type checking and validation. Java does not have a preprocessor. It provides similar functionality (#define, #typedef, and so on) to that provided by the C++ preprocessor, but with far more control. Constant data members are used in place of the #define directive, and class definitions are used in lieu of the #typedef directive. The end result is that Java source code is much more consistent and easier to read than C++ source code. Additionally, Java programs don't use header files; the Java compiler builds class definitions directly from the source code files, which contain both class definitions and method implementations. " I have spotted so much obvious biased statements towards java in this one book that I'm about to write a letter to the author asking him has he ever used C++ other than for Hello World programs || maybe did he just suck at it. IM PROUD TO BE A GMAIL;
-
"The problem with the preprocessor approach is that it provides an easy way for programmers to inadvertently add unnecessary complexity to a program. Many programmers using the #define and #typedef directives end up inventing their own sublanguage within the confines of a particular project. This results in other programmers having to go through the header files and sort out all of the #define and #typedef information to understand a program, which makes code maintenance and reuse almost impossible. An additional problem with the preprocessor approach is that it is very weak when it comes to type checking and validation. Java does not have a preprocessor. It provides similar functionality (#define, #typedef, and so on) to that provided by the C++ preprocessor, but with far more control. Constant data members are used in place of the #define directive, and class definitions are used in lieu of the #typedef directive. The end result is that Java source code is much more consistent and easier to read than C++ source code. Additionally, Java programs don't use header files; the Java compiler builds class definitions directly from the source code files, which contain both class definitions and method implementations. " I have spotted so much obvious biased statements towards java in this one book that I'm about to write a letter to the author asking him has he ever used C++ other than for Hello World programs || maybe did he just suck at it. IM PROUD TO BE A GMAIL;
Actually, this is pretty much all correct and is also C++ recommended practice (e.g., See the online C++ FAQ Lite or Scott Meyers's Effective C++ series). So while the author may be biased towards Java he also happens to be right. Other OO languages are similar to Java in this respect, e.g., C# and Eiffel. C++ departs from this mainly for backward compatibility with C. Kevin
-
"The problem with the preprocessor approach is that it provides an easy way for programmers to inadvertently add unnecessary complexity to a program. Many programmers using the #define and #typedef directives end up inventing their own sublanguage within the confines of a particular project. This results in other programmers having to go through the header files and sort out all of the #define and #typedef information to understand a program, which makes code maintenance and reuse almost impossible. An additional problem with the preprocessor approach is that it is very weak when it comes to type checking and validation. Java does not have a preprocessor. It provides similar functionality (#define, #typedef, and so on) to that provided by the C++ preprocessor, but with far more control. Constant data members are used in place of the #define directive, and class definitions are used in lieu of the #typedef directive. The end result is that Java source code is much more consistent and easier to read than C++ source code. Additionally, Java programs don't use header files; the Java compiler builds class definitions directly from the source code files, which contain both class definitions and method implementations. " I have spotted so much obvious biased statements towards java in this one book that I'm about to write a letter to the author asking him has he ever used C++ other than for Hello World programs || maybe did he just suck at it. IM PROUD TO BE A GMAIL;
Check out the article on this site on adding for-each to C++ for an example of why everything this guy has said is correct. The guy who wrote C++ says that use of macros usually shows a problem with either the design, or the programmer. C++ inherited this muck from C, it was not deliberately added. I'd have to say that having header files is no bad thing. Also, constant data members exist in C++, and should be used over #define. This guy is hitting out at bad C++ programmers more than C++ as a language, IMO. I don't see the point of writing to the author, he's entitled to his opinion, if you agree or not. Why get into a flame war ? Christian Graus - Microsoft MVP - C++