Maurizio Martignano wrote: > 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?
If the problem is that VS is emitting a meaningless warning, I would first check to see if there's a way to disable that particular warning. The code change does do harm - it adds in noise - and it's not free - the stylistic change must be maintained on all future code changes. As I said before tho, I speak for myself only, and a stylistic change like this should be agreed upon (or discounted) by the community. > 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. I didn't review all your code changes, I'm just commenting on what you said you changed. I agreed with you on the K&R style definitions. That is a far less controversial change. > 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 don't recall calling it crazy or nonsense. I said I think it's not a good idea. > I do not know if you are aware of the MISRA-C rules[...] I'm not familiar with them beyond a few minutes of web searching. But from those few minutes it's pretty clear that as/ns could not possibly conform to those rules, at least the 1998 version. (break, continue, and function pointers are deal-breakers) But those rules appear to be targeted at embedded and/or realtime systems; tho we might like as/ns to be realtime, it isn't :) > 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. You asked for comments, and I offered mine. I expect others will chime in too, and they may well agree with you. Either way, we can still find some way to work together. -J > > -----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
