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
