On Wed, 2009-04-29 at 17:25 -0500, Dick Hollenbeck wrote: [snip] > > This group has talked about using trying to use C++ features; why not > > simply start by adopting C99 features? > Yes, minus the designated initializers if not C++ compatible. > > > > I would not consider using the > > former language without a complete rewrite, > > What? It is only several days to get this project to compile with C++, > maybe several weeks to "rewrite" it. (Do we get to peek at the old > code when we "rewrite" it? If not, it would be several years.)
Having developed large projects in both languages, my approach would be different enough that they would be unrecognizable from one another. They would be two different projects. At that point, preserve this C implementation for those who want it and add a complementing/competing implementation in C++ and build it up without any legacy encumbrances. Even a fresh start in C would quickly gain the lead if developed with the experience gained from OpenOCD; however, it would take the community of existing developers using and testing it from the start. OpenOCD would effectively have to fork itself, though it would probably be called a "branch". Personally, I see Linux 2.6 as a fork of 2.4, not what most of us consider a branch. Further, 'git' shows what can be done when a large base of developers and users sets their mind on creating replacement tools. That could be done here for a next generation of OpenOCD, but I would not encourage that for reasons deserving their own thread(s). That said, I would not be opposed to seeing our C99-ish code compile with both gcc and g++, but that could be insane itself. I have a hard time imagining that they could both compile the code -- with strict warnings -- unless dubious tricks are used. C99 would be good enough. [snip] > Again, my apologies for not being specific enough. In fact I see now > that Igor did say what the problems were: > > 1) variable declarations not at the start of block > 2) designated initializers (.field = value) > 3) no unistd.h The last problem can be fixed by using the HAVE_UNISTD_H definition, but let's not forget other C99 features (some of which we already mentioned or are I know are used in the code): 4) // comments 5) new block scopes for selection and iteration statements 6) trailing comma allowed in enum declaration 7) inline functions Many or all of these features may also be supported in older compilers, but OpenOCD should consider using at least these C99 features. > > I have no love for MS VC and I have a great deal of respect for GNU > C/C++. So I hereby reverse my opinion, I am only willing to give up > designated initializers, not more. Personally, I love the new designated initializers, so I am reluctant to see those go. Nevertheless, I am not taking an official stance yet, only trying to contribute to the discussion on language feature support in OpenOCD. I think these topics have been debated off and on recently and it would be nice to put the topic to rest for a time. If Igor submits a patch, we should apply it if it moves us forward, but it would be nice to be able to update the documentation to reflect a set of current coding standards that begin to allow C99 features. I have started editing the relevant section of openocd.texi, but these issues need to work themselves out through community discussion. Cheers, Zach _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
