OK Simple reason: Visual Studio complains about that stuff and it is annoying. I changed that everywhere. It doesn't do any arm, and for you it is free. Why you just do not accept it?
And the same goes for the keywords "new" and "delete". On the contrary the keyword "bool" as I already mentioned interferes with macro definition on "bool" in the C201X STD. The K&R STD function style was not only in the file I mentioned, but as I mentioned is present also one or two more places in the codebase, so feel free to check my archive and do a diff. If all this C/C++ compatibility is so "crazy" and "non-sense" how come there's an option in gcc checking for a common subset? I do not know if you are aware of the MISRA-C rules (Guidelines for the use of C language in critical systems - http://en.wikipedia.org/wiki/MISRA_C); I do cause I work on this stuff - my bread and butter. Well in the 1998 version of this standard there was this rule: Rule 44 - Redundant explicit casts should be not used. But in the 2004 version of the standard this rule has been "rescinded", not by me, but by the authors of the standard, because for some people it was controversial and for some others it did not make any sense. Anyhow. All of this in not really important. I do not want to be annoyed by Visual Studio. I will use my version of the codebase. Want to use it? Please do, you are very welcome. Want to keep the original version, it is ok too. Hope it helps, Maurizio -----Original Message----- From: Jeff Rogers [mailto:dv...@diphi.com] Sent: 17 October 2012 07:26 To: Maurizio Martignano Cc: naviserver-devel@lists.sourceforge.net Subject: Re: [AOLSERVER] Naviserver Win-64 Sources Hi Maurizio, I appreciate your efforts on the windows portability and build front; but on the issue of c++ acceptability, I think you are trying to do something that really doesn't need doing. naviserver/aolserver is written in C. C is not C++. C++ is not "new C" or "a better C" - it is C++. Making the code look a little more palatable to programmers who know C++ but not C is asking for more trouble. I would expect an enthusiastic young C++ programmer to see all those casts from ns_malloc and ask "why is this using old-fashioned casts and malloc, when it should be using type-safe new?" And the answer is that C is not C++; in ansi C casting from a void * to another data pointer type is explicitly a safe operation. The cast is unnecessary noise. Many C++ programmers will tell you that casts are a sign of poor design. In C++ that may be true. C is not C++. Similarly, aolserver/naviserver is not hello.c. I don't mean to turn away new programmers - on the contrary, I think the code is very clean and understandable, but it is still complicated; if a programmer is going to get confused by seeing "new" as a variable name instead of a reserved word then they're going to be utterly baffled trying to understand race conditions in rapid thread creation or the lifecycle of conn threads. So what this really amounts to is a suggestion to change the coding standards and build/warning flags for the project. That is a valid topic of discussion. I personally don't think they need changing, but I speak for me and not for anyone else involved, and as I'm sure you're well aware coding standards are things that holy wars are made of so there's likely to be no shortage of opinion on it. If you wish to change the coding standards, it should be brought up as such, and not under the guise of windows portability, which it has nothing to do with. -J PS: re: tclxkeylist.c - ok, perhaps not so surprising there. I suspect that code was imported verbatim around 1998 and updated very little since then. I wonder how much this functionality is still used, or if it would make sense to move it into a separate loadable module (could users just use a complete tclx, or would that interact badly with signal handling or other bits?), since I would expect most new code to use dict instead. Maurizio Martignano wrote: > Dear Jeff, > Thank you very much for your remarks. I would like to share what I > think. > > 2.a > Of course we are talking about C files and not C++ files, so any > compiler will accept the sources as they are (at least till now). But > the point here I believe is making the codebase easy to read and > maintain. Nowadays programmers (unlike us I am afraid - I am 52 years > old) are used to C++ more than C; so trying to use the common subset > between ISO C e C++ standard make sense. If I take gcc and I compile > the code with the option "-Wc++-compat" I get a warning for every ISO > C construct that is outside of the common subset of ISO C and ISO C++, > e.g. request for implicit conversion from void * to a pointer to non-void type. > So that is an effort in making the code easily readable by programmers > (not > compilers) with C++ background. > > 2.b > Shocking? Have a look at the file "tclXkeylist.c"... The same > construct is used here and there in other places (look at the diffs). > > 2.c > Well the new STD 201X defines as keyword (see section 6.4.1) "_Bool", > but there's a macro definition converting "bool" to "_Bool" . For > "new" and "delete" the point is once again avoiding mismatches between > C and C++, causing confusion to a reader/programmer/maintainer with a C++ mindset. > > Summing up: > 1. I have done a static code analysis of all the codebase. > 2. I have identified these discrepancies and corrected all of them 3. > This makes the overall system easier to read and to maintain > > BTW: 90% of my current business (bread and butter) comes from doing > this type of analysis on various systems. Most of the time it is for > embedded systems used in avionics applications. There the language is > mostly Ada and not C or C++. > > Hope it clarifies my point, > Maurizio > > > -----Original Message----- > From: Jeff Rogers [mailto:dv...@diphi.com] > Sent: 16 October 2012 01:38 > To: Maurizio Martignano > Cc: aolserver-t...@lists.sourceforge.net > Subject: Re: [AOLSERVER] Naviserver Win-64 Sources > > Maurizio Martignano wrote: > >> 2.A set of necessary cosmetics/make up changes to the overall code >> base to make it more compliant with nowadays C STDs, and therefore >> more "acceptable" to nowadays C compilers, they are: >> >> a.I have made explicit all type conversions (with explicit casts) >> >> b.I have modified all functions defined in K&R C STD, changing them >> into ANSI C STD >> >> c.I have removed from the code base all reserved words, e.g.: new, >> delete, bool . > > Are you building with a C compiler or a c++ compiler? new, delete, > and bool are not reserved words in any dialect of C that I'm aware of. > C++ is also pickier about casting; in C you should be able to cast any > pointer to or from a void* without a cast. > > The K&R definitions can go; It's somewhat shocking there would be any > still around. > > -J > ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct _______________________________________________ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
