This being the case, with all due respect, I don't think you are qualified to discuss matters of coding style. You just don't have an opinion on one of the coding style tenets of C/C++ programming.Originally Posted by rcgldr
This being the case, with all due respect, I don't think you are qualified to discuss matters of coding style. You just don't have an opinion on one of the coding style tenets of C/C++ programming.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
Perhaps a poor choice of wording which was qualified in my later statement, that if some aspect of programming doesn't have a significant impact on being able to maintain, enhance, or reuse (I'm adding this now) code, it's not that important of an issue. What I meant was that my opinion on this is neutral. When I consider what are good or bad programming practices, coding style is way down on my list of issues, and the original thread asking for help for a specific program was not the place to start a debate about typedefs for pointers or all upper case typedefs, which how this thread got spawned.
The statement that I was specifically disputing what that using typedefs for pointers or all upper case typedefs were bad programming practices. I'm not claiming they are good programming practices, just that they are not bad programming practices.
Hungarian notation came up because I pointed out the fact that the windows API uses typedefs for poitners (so do other coding styles) and all upper case typedefs. Even linux / posix / unix uses the struct typedef FILE.
Last edited by rcgldr; 05-13-2013 at 06:45 PM.
Usually when a lot of people, especially knowledgeable people, all agree that specific code is not all that good, it starts to become bad practice. Some people on this board also believe in some of these so called bad practices. You are simply going to have to accept that people will complain about style issues that they consider bad practice (and some things which the community as a large consider bad practice).
In case you don't want to start a discussion like this, don't disagree
And when you lose an argument, to stop typing next, in my experience, is the most graceful exit.
Despite the best efforts of our lawmakers, code is meant to be shared. Even if only by the members of a small cult. Other times by large communities. So, can you imagine if the Bible read "Yeah, then the bigLORD bossGod created man out of dirt and coughed life up his nose" (King James Bible, Genesis 2-7)?
Coding style matters, Hungarian notation sucks and all caps will meet their judgment on the last days.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
Just because Windows does something doesn't make it correct. They have made many mistakes, one of those "mistakes" was the adoption of Hungarian notation. Along with the adoption of Hungarian notation came pointer typedefs, to match.Hungarian notation came up because I pointed out the fact that the windows API uses typedefs for poitners (so do other coding styles) and all upper case typedefs.
When converting Windows 16 bit code to 32 bit code came many of the same problems we are seeing today with the 32 to 64 bit migration, poor assumptions about the sizes of variables. This migration lead to the use of macros in the Windows 32bit API to replace C's integer types. The use of all upper case for macros is considered the norm by many programmers, so things like DWORD, a macro, being all upper case is "normal". Today this would probably be replaced with C's exact-width integer types (int8_t).
FILE is a macro, hence is all upper case.Even linux / posix / unix uses the struct typedef FILE.
From the April 12, 2011 draft standard, section 7.21
1. The header <stdio.h> defines several macros, and declares three types and many
functions for performing input and output.
2. The types declared are size_t (described in 7.19);
FILE
which is an object type capable of recording all the information needed to control a
stream, including its file position indicator, a pointer to its associated buffer (if any), an
error indicator that records whether a read/write error has occurred, and an end-of-file
indicator that records whether the end of the file has been reached; and
Jim
That is not required anywhere - not even in that extract from the draft you quoted.
That said, FILE being a macro is also not disallowed. Practically, FILE is effectively an opaque type - we know it represents a type capable of keeping track of all information need to control a stream, but the standard says nothing about how that information is organised.
