Subject: External header guards (was: In the Works: New OOo
C++ Coding Standards) - msg#00155

Previous Message by Date:

API problem on 64 bit system

Hi, We're using the Open Office API in one of our projects, and on a 64bit OS (Windows Server 2003 Standard x64 Edition) we encounter the following exception:"System.BadImageFormatException: is not a valid Win32 application.(HRESULT: 0x800700C1)". Our code is written in C# (using .Net Framework 2.0), and this exception is raised on m_xContext = uno.util.Bootstrap.bootstrap();. Is there something we can do to prevent this? I originally sent this email to users@xxxxxxxxxxxxxx, and been instructed to forward it to dev. Best regards, Murariu Catalin Software Developer Skype ID: katahlyn Yahoo ID: katahlyn Phone: +40742176729

Next Message by Date:

Re: In the Works: New OOo C++ Coding Standards

Jan Holesovsky wrote: Hi Thorsten, On Monday 18 December 2006 11:46, Thorsten Behrens wrote: Aah. Let me rephrase. Are -you- really sure the external include guard optimization provides enough benefit on all the compilers we are using to make it worthwhile to degrade readability by adding noise? Ie. is this a modest gain in machine time compared to a perhaps much costlier loss of human time? Can you provide some numbers to support this optimization or should we perhaps be conservative and not use it? ;-) ok, seems we've deadlocked here. ;-) Point is, the vast majority of the code uses that idiom as of today, and I'm reluctant to advice people of the contrary (as long as there are build time degradations on at least one prominent platform, at least when building on a network volume). Rather sooner than later, all used compilers will perform this optimization by themselves, and I'd say let's add the rule then. I'm relatively indifferent about this, though - if people think it's ok to start removing external header guards right now (because it will take years to clean them up anyway), I'd be fine with that, too. I hate them that much that I am willing to do a script that would do the removal ;-) What is the platform/compiler that probably needs this, please? Any volunteer to do a comparison of the "with" and "without" compilation times? AFAIK GCC and SunStudio know about the "include guard optimization" and do not need this. These platforms also do have no problem with caching a few files even if they are served from a remote volume, so it hardly wouldn't matter anyway. The one remaining compiler is Microsoft Visual Studio. There are varying reports if this compiler has a build-in "include guard optimization" or not. The acid test would be a build on Windows vs. a remote Samba or NFS volume (some people have such a setup). If the compile speed drops no more than - say - 5 to 10% we IMHO could do away with these ugly things. Heiner

Previous Message by Thread:

Re: In the Works: New OOo C++ Coding Standards

Hi Eric, you wrote: > Let's imagine I'm a new dev willing to contribute to OpenOffice.org : > > [H] : like common people who want to help, I do have C/C++ background > ( something like 3 to 10 years of coding something somewhere) > > - first question : where are things ? How is organized > OpenOffice.org code ?( build OpenOffice.org can really help here ) > > - second question: what is the design of the feature I want to > contribute ? > > [snip] > > Facts: because I didn't find the answer to the first question(s), I > do like 1 developers over 2 did -> I give up > > For Mac OS X port, we lost 1 over 2 new devs, willing to help us, > this way, and I have to use a lot of energy and must take care every > day about that. > You are right - and the problem is, there's no easy fix for that. It's a multi-dimensional optimization problem, and maximizing one aspect might pessimize other. I agree with you that the barrier for entry is high for new devs, but efforts to improve on this are ongoing (build times, integration of ooo-build build system ease-of-use, lightweight spec processes, unit tests etc). High-level design documentation is sorely missing for most modules, but: OOo is too big, and internal stuff changes much too frequently, that static design description would really cut it (except it's _really_ high level, like the module manifestos on the source code directories wiki page). I guess a mix of problem-specific HowTo entries (like e.g. adding a new menu entry, a new import filter, etc.), knowing where to ask (->irc, dev list), and tooling (lxr, bonsai, refactoring toolkit) has the best chance of being up-to-date, and at the same time avoiding to frustrate people too much. > -1 for a new C++ list of best practices : I already got the > Stroustrup's book (and will continue to learn it) > I'd really hope that the best practice examples from the coding standards pages are more than what you could glean from the Stroustrup book (it should rather be a distilled extract from a lot of sources, including gurus like Stroustrup). Besides, it's less to read. ;-) > To complete, as suggestion, we should add keywords (or sub- > categories) in the wiki description like : > > - knowledge only > - practical > - tips ( good examples in the code ) > - autonomy ( idea to improve ) > - tools ( interaction between code and tools, how compile and test > my code ... ) > - resources ( people, code snippets , where/how find/join us, > bibliography ... ) > - (complete) > Would you like to add some of them? > But don't forget the first point: we currently continue to lose new > devs regularly ... > We don't forget - but please bear in mind that OOo is one of the largest and most complex OSS projects (maybe /the/ largest), and in contrast to e.g. Linux kernel, there's no such clean separation between device drivers and core kernel (because of the vastly different problem domain, I'd assume). So, a certain survival-of-the-fittest preselection should be accepted (in fact, necessary), but I'm with you that we haven't reached the sweet spot here. Cheers, -- Thorsten

Next Message by Thread:

Re: External header guards (was: In the Works: New OOo C++ Coding Standards)

Hi Thosten, On Tuesday 19 December 2006 21:40, Thorsten Behrens wrote: > you wrote: > > I hate them that much that I am willing to do a script that would do > > the removal ;-) > > > > What is the platform/compiler that probably needs this, please? Any > > volunteer to do a comparison of the "with" and "without" compilation > > times? > > That would be msvc 7.1 > > Go ahead with the script (I'd take that anyway, once we switch to 8.0) > - I can do the timings. So - everything is ready ;-) http://www.go-oo.org/ooo-build/bin/strip-guards is the script to run over your sources (give it path to them as a parameter). http://www.go-oo.org/ooo-build/patches/src680/strip-guards-additions.diff is a patch to be applied over that (ooe680-m6), and finally http://www.go-oo.org/ooo-build/patches/src680/fast-mkdepend.diff is a fix for the mkdepend slowness with sources that do not have the external guards. (BTW, makedepend is an unbelievable piece of software ;-) It's optimized for everything - but for what it should be optimized for. This patch should fix that, it cuts thousands [maybe millions?] of unnecessary descents through the structure to find that the symbol is really not defined [+ a better structure for holding the symbols].) Please test - I'm eager to see the results with msvc ;-) Merry Christmas, and a Happy New Year! Thank you, Jan