coding style
Locked
coding style
 
|
Hi all,
You may have noticed that I have done some changes in the inclusions yesterday. The goal was to include less header files in the header files (to avoid cascading inclusion). To do so I have removed uneeded or too general inclusions. I have also used forward declarations and now I have doubts about the relevancy this trick. Indeed I have the feeling that it simply moves some inclusions to the client code. So one way or another compiler will have parsed the same amount of header files to compile a client file... Any thoughts? Another one, what about refactoring the QL folders hierarchy since we are using svn? François ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
|
|
On Thu, 2007-04-05 at 12:46 +0200, DU VIGNAUD DE VILLEFORT FRANCOIS
GASAPRD PHI wrote: > You may have noticed that I have done some changes in the inclusions > yesterday. The goal was to include less header files in the header > files (to avoid cascading inclusion). To do so I have removed uneeded > or too general inclusions. I have also used forward declarations and > now I have doubts about the relevancy this trick. Indeed I have the > feeling that it simply moves some inclusions to the client code. So > one way or another compiler will have parsed the same amount of header > files to compile a client file... Any thoughts? Possibly. At the end of the day, the client code must instantiate all needed classes, so it's likely that it includes everything. However, the advantage is in compilation times for the library. On the one hand, the overall time can decrease as each source file might include less headers. On the other hand, and more importantly, incremental compilations are faster since changing a header file might cause less source files to be recompiled. This said, I'd love to see experimental data on compilation times before and after the changes... > Another one, what about refactoring the QL folders hierarchy since we > are using svn? Sure. Any ideas? Luigi ---------------------------------------- Blessed is the man who, having nothing to say, abstains from giving wordy evidence of the fact. -- George Eliot ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
Re: coding style
|
|
In reply to this post by DU VIGNAUD DE VILLEFORT FRANCOIS GASAPRD PHI
>Possibly. At the end of the day, the client code must instantiate all >needed classes, so it's likely that it includes everything. >However, the advantage is in compilation times for the library. On the >one hand, the overall time can decrease as each source file might >include less headers. On the other hand, and more importantly, >incremental compilations are faster since changing a header file might >cause less source files to be recompiled. Well, since all classes are compiled in the library, they also must have access sooner or later to the actual definition of the classes they are depends on. IMHO the actual improvement (if any) is that it reduces the number of redundant inclusions. It should make no difference thanks to include guards. However Lakos recommands in his book (Large-Scale C++ Software Design) the use of redundant include guards to detect redundant inclusion earlier. (It keeps the compiler from parsing header files to look for include guards limits.) >> Another one, what about refactoring the QL folders hierarchy since we >> are using svn? >Sure. Any ideas? I would move some existing folders and files as follows math: optimization randomnumbers solver1D time:(new) calendars daycounters (schedule.*, BDC, weekday, ...) methods:(new) finitedifferences montecarlo lattices termstructures: Volatilities I would also create the following subfolders: math: integrals distributions interpolations instruments: swaps bonds options termstructures: yieldCurve volatilities François ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
|
|
On Thu, 2007-04-05 at 15:10 +0200, DU VIGNAUD DE VILLEFORT FRANCOIS
GASAPRD PHI wrote: > >Possibly. At the end of the day, the client code must instantiate all > >needed classes, so it's likely that it includes everything. > >However, the advantage is in compilation times for the library. On the > >one hand, the overall time can decrease as each source file might > >include less headers. On the other hand, and more importantly, > >incremental compilations are faster since changing a header file might > >cause less source files to be recompiled. > > Well, since all classes are compiled in the library, they also must > have access sooner or later to the actual definition of the classes > they are depends on. Non necessarily. Let's say we have: - a class Foo declared in foo.hpp and implemented in foo.cpp; - a class Bar that stores, say, a pointer to Foo. In bar.hpp, we only need a forward declaration of Foo. In bar.cpp (where the Foo object is manipulated) we need to include foo.hpp. - a class Baz which takes a pointer to Foo as argument, passes it to a Bar, and stores (and possibly manipulates) the resulting Bar. Since Baz is not going to use Foo directly, baz.cpp does not need to include its definition---the forward declaration in bar.hpp is enough---and can be compiled successfully without including foo.hpp. > >> Another one, what about refactoring the QL folders hierarchy since we > >> are using svn? > > >Sure. Any ideas? > > I would move some existing folders and files as follows > > math: > optimization > randomnumbers > solver1D > > time:(new) > calendars > daycounters > (schedule.*, BDC, weekday, ...) > > methods:(new) > finitedifferences > montecarlo > lattices > > termstructures: > Volatilities > > > I would also create the following subfolders: > math: > integrals > distributions > interpolations > > instruments: > swaps > bonds > options > > termstructures: > yieldCurve > volatilities yieldcurves, you mean. Plural and lowercase. About instruments, I'm not so sure. But all the others seem ok to me. Any other votes, anybody? Later, Luigi ---------------------------------------- The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise. -- W.E. Dijkstra ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
Re: coding style
|
|
In reply to this post by DU VIGNAUD DE VILLEFORT FRANCOIS GASAPRD PHI
>Non necessarily. Let's say we have:
>- a class Foo declared in foo.hpp and implemented in foo.cpp; >- a class Bar that stores, say, a pointer to Foo. In bar.hpp, we > only need a forward declaration of Foo. In bar.cpp (where the > Foo object is manipulated) we need to include foo.hpp. >- a class Baz which takes a pointer to Foo as argument, passes it > to a Bar, and stores (and possibly manipulates) the resulting Bar. >Since Baz is not going to use Foo directly, baz.cpp does not need to >include its definition---the forward declaration in bar.hpp is >enough---and can be compiled successfully without including foo.hpp. Ok you win me over, thanks for this detailled explanation. Regards, François ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
|
|
On Thu, 2007-04-05 at 15:59 +0200, DU VIGNAUD DE VILLEFORT FRANCOIS
GASAPRD PHI wrote: > Ok you win me over It's not a match :) However, I just checked out a revision of the library prior to your changes and tried some tests. Full compilation times vary of just a few seconds (which might well be attributed to my computer checking RSS feeds during the compilation.) Recompilation times (i.e., time to recompile the library starting from a fully compiled one and touching ql/yieldtermstructure.hpp) were about 5% smaller for the new version. So there is some effect, but nothing very exciting... Later, Luigi ---------------------------------------- feature, n: A surprising property of a program. Occasionally documented. To call a property a feature sometimes means the author did not consider that case, and the program makes an unexpected, though not necessarily wrong response. See BUG. "That's not a bug, it's a feature!" A bug can be changed to a feature by documenting it. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
«
Return to quantlib-dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |