1 #LyX 2.0.0svn created this file. For more info see http://www.lyx.org/
6 \use_default_options true
11 \font_typewriter default
12 \font_default_family default
18 \paperfontsize default
27 \paperorientation portrait
30 \paragraph_separation indent
31 \quotes_language english
34 \paperpagestyle default
35 \listings_params "basicstyle={\footnotesize}"
36 \tracking_changes true
38 \author "Kornel Benko" Kornel.Benko@berlin.de
45 \begin_inset Newline newline
48 Rules and Recommendations
52 Rules for the code in LyX
56 \begin_layout Plain Layout
57 Updated from the C++STYLE distributed with the GNU C++ Standard.
65 \begin_layout Standard
66 The aim of this file is to serve as a guide for the developers, to aid us
67 to get clean and uniform code.
68 This document is incomplete.
69 We really like to have new developers joining the LyX Project.
70 However, we have had problems in the past with developers leaving the project
71 and their contributed code in a far from perfect state.
72 Most of this happened before we really became aware of these issues, but
73 still, we don't want it to happen again.
74 So we have put together some guidelines and rules for the developers.
81 \begin_layout Standard
82 These guidelines should save us a lot of work while cleaning up the code
83 and help us to have quality code.
84 LyX has been haunted by problems coming from unfinished projects by people
85 who have left the team.
86 Those problems will hopefully disappear if the code is easy to hand over
88 In general, if you want to contribute to the main source, we expect at
93 the most important rule first: KISS (Keep It Simple Stupid), always use
94 a simple implementation in favor of a more complicated one.
95 This eases maintenance a lot.
99 write good C++ code: Readable, well commented and taking advantage of the
101 Follow the formatting guidelines.
105 \begin_layout Itemize
106 adapt the code to the structures already existing in LyX, or in the case
107 that you have better ideas, discuss them on the developer's list before
111 \begin_layout Itemize
112 take advantage of the C++ standard library.
113 Especially don't use custom containers when a standard container is usable;
114 learn to use the algorithms and functors in the standard library.
117 \begin_layout Itemize
118 be aware of exceptions and write exception safe code.
122 \begin_layout Itemize
123 document all variables, methods, functions, classes etc.
124 We are using the source documentation program doxygen, a program that handles
125 javadoc syntax, to document sources.
126 You can download doxygen from: http://www.stack.nl/~dimitri/doxygen/
129 \begin_layout Itemize
130 we have certain code constructs that we try to follow.
134 \begin_layout Section
138 \begin_layout Standard
139 It is implicitly understood that all patches contributed to The LyX Project
140 is under the Gnu General Public License, version 2 or later.
141 If you have a problem with that, don't contribute code.
142 Also please don't just pop up out of the blue with a huge patch (or small)
143 that changes something substantial in LyX.
144 Always discuss your ideas with the developers on the developer's mailing
146 When you create the patch, please use "diff -up" since we find that a lot
147 easier to read than the other diff formats.
148 Also please do not send patches that implements or fixes several different
149 things; several patches is a much better option.
150 We also require you to provide a commit message entry with every patch,
151 this describes in detail what the patch is doing.
155 \begin_layout Section
159 \begin_layout Standard
160 We have several guidelines on code constructs, some of these exist to make
161 the code faster, others to make the code clearer.
162 Yet others exist to allow us to take advantage of the strong type checking
167 \begin_layout Itemize
168 Declaration of variables should wait as long as possible.
169 The rule is: "Don't declare it until you need it." In C++ there are a lot
170 of user defined types, and these can very often be expensive to initialize.
171 This rule connects to the next rule too.
175 \begin_layout Itemize
176 Declare the variable as const if you don't need to change it.
177 This applies to POD types like int as well as classes.
181 \begin_layout Itemize
182 Make the scope of a variable as small as possible.
185 \begin_layout Itemize
186 Make good use of namespaces.
187 Prefer anonymous namespaces to declaring "static" for file scope.
190 \begin_layout Itemize
191 Prefer preincrement to postincrement whenever possible.
194 \begin_layout Itemize
195 Preincrement has potential of being faster than postincrement.
196 Just think about the obvious implementations of pre/post-increment.
197 This rule applies to decrement too.
200 \begin_layout Itemize
205 \begin_layout Standard
206 \begin_inset listings
207 lstparams "basicstyle={\footnotesize},language={C++}"
211 \begin_layout Plain Layout
216 \begin_layout Plain Layout
226 \begin_layout Standard
230 \begin_layout Standard
231 \begin_inset listings
235 \begin_layout Plain Layout
237 T++; // not used in LyX
240 \begin_layout Plain Layout
242 U--;// not used in LyX
251 \begin_layout Itemize
252 Try to minimize evaluation of the same code over and over.
253 This is aimed especially at loops.
255 \begin_inset Newline newline
262 \begin_layout Standard
263 \begin_inset listings
267 \begin_layout Plain Layout
269 Container::iterator end = large.end();
272 \begin_layout Plain Layout
274 for (Container::iterator it = large.begin(); it != end; ++it) {
277 \begin_layout Plain Layout
282 \begin_layout Plain Layout
292 \begin_layout Standard
296 \begin_layout Standard
297 \begin_inset listings
301 \begin_layout Plain Layout
303 for (Container::iterator it = large.begin(); it != large.end(); ++it) {
306 \begin_layout Plain Layout
311 \begin_layout Plain Layout
322 \begin_layout Itemize
323 For functions and methods that return a non-POD type
327 \begin_layout Plain Layout
333 T, return T const instead.
334 This gives better type checking, and will give a compiler warning when
335 temporaries are used wrongly.
339 \begin_layout Standard
343 \begin_layout Standard
344 \begin_inset listings
348 \begin_layout Plain Layout
358 \begin_layout Standard
362 \begin_layout Standard
363 \begin_inset listings
367 \begin_layout Plain Layout
378 \begin_layout Itemize
379 Avoid using the default cases in switch statements unless you have too.
380 Use the correct type for the switch expression and let the compiler ensure
381 that all cases are exhausted.
384 \begin_layout Itemize
385 \begin_inset listings
389 \begin_layout Plain Layout
394 \begin_layout Plain Layout
399 \begin_layout Plain Layout
404 \begin_layout Plain Layout
409 \begin_layout Plain Layout
413 \begin_layout Plain Layout
418 \begin_layout Plain Layout
422 \begin_layout Plain Layout
427 \begin_layout Plain Layout
432 \begin_layout Plain Layout
437 \begin_layout Plain Layout
442 \begin_layout Plain Layout
447 \begin_layout Plain Layout
452 \begin_layout Plain Layout
454 // not needed and would shadow a wrong use of Foo
457 \begin_layout Plain Layout
462 \begin_layout Plain Layout
472 \begin_layout Section
476 \begin_layout Standard
477 Be aware of the presence of exceptions.
478 One important thing to realize is that you often do not have to use throw,
479 try or catch to be exception safe.
480 Let's look at the different types of exceptions safety: (These are taken
481 from Herb Sutter's book[ExC++]
484 \begin_layout Enumerate
485 Basic guarantee: Even in the presence of exceptions thrown by T or other
486 exceptions, Stack objects don't leak resources.
487 Note that this also implies that the container will be destructible and
488 usable even if an exception is thrown while performing some container operation.
489 However, if an exception is thrown, the container will be in a consistent,
490 but not necessarily predictable, state.
491 Containers that support the basic guarantee can work safely in some settings.
495 \begin_layout Enumerate
496 Strong guarantee: If an operation terminates because of an exception, program
497 state will remain unchanged.
498 This always implies commit-or-rollback semantics, including that no references
499 or iterators into the container be invalidated if an operation fails.
500 For example, if a Stack client calls Top and then attempts a Push that
501 fails because of an exception, then the state of the Stack object must
502 be unchanged and the reference returned from the prior call to Top must
504 For more information on these guarantees, see Dave Abrahams's documentation
505 of the SGI exception-safe standard library adaption at: http://www.stlport.org/do
506 c/exception_safety.html Probably the most interesting point here is that
507 when you implement the basic guarantee, the strong guarantee often comes
509 For example, in our Stack implementation, almost everything we did was
510 needed to satisfy just the basic guarantee -- and what's presented above
511 very nearly satisfies the strong guarantee, with little o
512 \change_inserted 0 1288157484
514 \change_deleted 0 1288157483
518 Not half bad, considering all the trouble we went to.
519 In addition to these two guarantees, there is one more guarantee that certain
520 functions must provide in order to make overall exception safety possible:
523 \begin_layout Enumerate
524 No throw guarantee: The function will not emit an exception under any circumstan
526 Overall exception safety isn't possible unless certain functions are guaranteed
528 In particular, we've seen that this is true for destructors; later in this
529 miniseries, we'll see that it's also needed in certain helper functions,
533 \begin_layout Standard
534 For all cases where we might be able to write exception safe functions without
535 using try, throw or catch we should do so.
536 In particular we should look over all destructors to ensure that they are
537 as exception safe as possible.
540 \begin_layout Section
544 \begin_layout Itemize
545 Only one declaration on each line.
549 \begin_layout Standard
553 \begin_layout Standard
554 \begin_inset listings
558 \begin_layout Plain Layout
563 \begin_layout Plain Layout
573 \begin_layout Standard
577 \begin_layout Standard
578 \begin_inset listings
582 \begin_layout Plain Layout
584 int a,b; // not used in LyX
592 \begin_layout Standard
593 This is especially important when initialization is done at the same time:
596 \begin_layout Standard
600 \begin_layout Standard
601 \begin_inset listings
605 \begin_layout Plain Layout
610 \begin_layout Plain Layout
620 \begin_layout Standard
624 \begin_layout Standard
625 \begin_inset listings
629 \begin_layout Plain Layout
631 string a = "Lars", b = "Gullik"; // not used in LyX
639 \begin_layout Standard
640 [Note that 'string a = "Lars"' is formally calling a copy constructor on
641 a temporary constructed from a string literal and therefore has the potential
642 of being more expensive then direct construction by 'string a("Lars")'.
643 However the compiler is allowed to elide the copy (even if it had side
644 effects), and modern compilers typically do so.
645 Given these equal costs, LyX code favours the '=' idiom as it is in line
646 with the traditional C-style initialization, _and_ cannot be mistaken as
647 function declaration, _and_ reduces the level of nested parantheses in
648 more initializations.]
652 \begin_layout Itemize
653 Pointers and references:
657 \begin_layout Standard
661 \begin_layout Standard
662 \begin_inset listings
666 \begin_layout Plain Layout
671 \begin_layout Plain Layout
681 \begin_layout Standard
685 \begin_layout Standard
686 \begin_inset listings
690 \begin_layout Plain Layout
692 char *p = "flop"; // not used in LyX
695 \begin_layout Plain Layout
697 char &c = *p; // not used in LyX
705 \begin_layout Standard
706 Some time ago we had a huge discussion on this subject and after convincing
707 argumentation from Asger this is what we decided.
708 Also note that we will have:
711 \begin_layout Standard
712 \begin_inset listings
716 \begin_layout Plain Layout
726 \begin_layout Standard
730 \begin_layout Standard
731 \begin_inset listings
735 \begin_layout Plain Layout
737 const char * p; // not used in LyX
746 \begin_layout Itemize
747 Operator names and parentheses
751 \begin_layout Standard
752 \begin_inset listings
756 \begin_layout Plain Layout
766 \begin_layout Standard
770 \begin_layout Standard
771 \begin_inset listings
775 \begin_layout Plain Layout
777 operator == (type) // not used in LyX
785 \begin_layout Standard
786 The == is part of the function name, separating it makes the declaration
787 look like an expression.
791 \begin_layout Itemize
792 Function names and parentheses
796 \begin_layout Standard
797 \begin_inset listings
801 \begin_layout Plain Layout
811 \begin_layout Standard
815 \begin_layout Standard
816 \begin_inset listings
820 \begin_layout Plain Layout
822 void mangle () // not used in LyX
831 \begin_layout Itemize
836 \begin_layout Standard
837 \begin_inset listings
841 \begin_layout Plain Layout
846 \begin_layout Plain Layout
851 \begin_layout Plain Layout
856 \begin_layout Plain Layout
861 \begin_layout Plain Layout
871 \begin_layout Standard
875 \begin_layout Standard
876 \begin_inset listings
880 \begin_layout Plain Layout
882 enum { one = 1, two = 2, three 3 }; // not used in LyX
890 \begin_layout Standard
894 \begin_layout Standard
895 \begin_inset listings
899 \begin_layout Plain Layout
904 \begin_layout Plain Layout
909 \begin_layout Plain Layout
914 \begin_layout Plain Layout
919 \begin_layout Plain Layout
930 \begin_layout Itemize
935 \begin_layout Standard
936 Using a plain 0 is always correct and least effort to type.
940 \begin_layout Standard
941 \begin_inset listings
945 \begin_layout Plain Layout
955 \begin_layout Standard
959 \begin_layout Standard
960 \begin_inset listings
964 \begin_layout Plain Layout
966 void * p = NULL; // not used in LyX
974 \begin_layout Standard
978 \begin_layout Standard
979 \begin_inset listings
983 \begin_layout Plain Layout
987 0'; // not used in LyX
995 \begin_layout Standard
999 \begin_layout Standard
1000 \begin_inset listings
1004 \begin_layout Plain Layout
1006 void * p = 42 - 7 * 6; // not used in LyX
1014 \begin_layout Standard
1015 Note: As an exception, imported third party code as well as code interfacing
1016 the "native" APIs (src/support/os_*) can use NULL.
1020 \begin_layout Itemize
1021 Naming rules for classes
1025 \begin_layout Itemize
1026 Use descriptive but simple and short names.
1030 \begin_layout Itemize
1031 Class names are usually capitalized, and function names lowercased.
1034 \begin_layout Itemize
1035 Enums are named like Classes, values are usually in lower-case.
1038 \begin_layout Itemize
1039 Public API is camel-case ('void setAFlagToAValue(bool)')
1042 \begin_layout Itemize
1043 Members variables are underscored ('enable_this_feature_flag_') with a final
1047 \begin_layout Itemize
1048 Private/protected functions are also camel-case
1051 \begin_layout Itemize
1052 New types are capitalized, so this goes for typedefs, classes, structs and
1057 \begin_layout Itemize
1062 \begin_layout Itemize
1063 Adapt the formatting of your code to the one used in the other parts of
1065 In case there is different formatting for the same construct, use the one
1070 \begin_layout Itemize
1071 Use existing structures
1075 \begin_layout Itemize
1077 \change_inserted 0 1288159254
1078 \begin_inset CommandInset label
1080 name "Use-string-wherever"
1086 Use string wherever possible.
1087 LyX will someday move to Unicode, and that will be easy if everybody uses
1089 Unicode strings should prefer using docstring instead of UTF-8 encoded
1093 \begin_layout Itemize
1094 Check out the filename and path tools in filetools.h
1097 \begin_layout Itemize
1098 Check out the string tools in lstring.h.
1101 \begin_layout Itemize
1102 Use the LyXErr class to report errors and messages using the lyxerr instantiatio
1104 [add description of other existing structures]
1108 \begin_layout Itemize
1113 \begin_layout Itemize
1114 Use this order for the access sections of your class: public, protected,
1116 The public section is interesting for every user of the class.
1117 The private section is only of interest for the implementors of the class
1119 [Obviously not true since this is for developers, and we do not want one
1120 developer only to be able to read and understand the implementation of
1125 \begin_layout Itemize
1126 Avoid declaring global objects in the declaration file of the class.
1127 If the same variable is used for all objects, use a static member.
1130 \begin_layout Itemize
1131 Avoid global or static variables.
1135 \begin_layout Itemize
1140 \begin_layout Standard
1141 If you create a new file, the top of the file should look something like
1145 \begin_layout Standard
1146 \begin_inset listings
1150 \begin_layout Plain Layout
1155 \begin_layout Plain Layout
1162 \begin_layout Plain Layout
1164 * This file is part of LyX, the document processor.
1167 \begin_layout Plain Layout
1169 * Licence details can be found in the file COPYING.
1172 \begin_layout Plain Layout
1177 \begin_layout Plain Layout
1184 \begin_layout Plain Layout
1189 \begin_layout Plain Layout
1191 * Full author contact details are available in file CREDITS
1194 \begin_layout Plain Layout
1205 \begin_layout Itemize
1210 \begin_layout Itemize
1211 The documentation is generated from the header files.
1214 \begin_layout Itemize
1215 You document for the other developers, not for yourself.
1218 \begin_layout Itemize
1219 You should document what the function does, not the implementation.
1223 \begin_layout Itemize
1224 in the .cpp files you document the implementation.
1228 \begin_layout Itemize
1229 Single line description (///), multiple lines description (/** ...
1230 */) see the doxygen webpage referenced above
1234 \begin_layout Section
1235 Naming rules for Lyx User Functions (LFUNs)
1238 \begin_layout Standard
1239 Here is the set of rules to apply when a new command name is introduced:
1242 \begin_layout Enumerate
1243 Use the object.event order.
1244 That is, use `word-forward' instead of`forward-word'.
1247 \begin_layout Enumerate
1248 Don't introduce an alias for an already named object.
1252 \begin_layout Enumerate
1253 Forward movement or focus is called `forward' (not `right').
1256 \begin_layout Enumerate
1257 Backward movement or focus is called `backward' (not `left').
1260 \begin_layout Enumerate
1261 Upward movement of focus is called `up'.
1264 \begin_layout Enumerate
1265 Downward movement is called `down'.
1268 \begin_layout Enumerate
1269 The begin of an object is called `begin' (not `start').
1272 \begin_layout Enumerate
1273 The end of an object is called `end'.
1276 \begin_layout Section
1277 How to create class interfaces
1280 \begin_layout Standard
1281 (a.k.a How Non-Member Functions Improve Encapsulation)
1284 \begin_layout Standard
1285 I recently read an article by Scott Meyers
1286 \change_deleted 0 1288158556
1289 , where he makes a strong case on how non-member functions makes classes
1290 more encapsulated, not less.
1291 Just skipping to the core of this provides us with the following algorithm
1292 for deciding what kind of function to add to a class interface:
1295 \begin_layout Itemize
1296 We need to add a function f to the class C's API.
1300 \begin_layout Standard
1301 \begin_inset listings
1305 \begin_layout Plain Layout
1307 if (f needs to be virtual)
1310 \begin_layout Plain Layout
1312 make f a member function of C;
1315 \begin_layout Plain Layout
1317 else if (f is operator>> or operator<<) {
1320 \begin_layout Plain Layout
1322 make f a non-member function;
1325 \begin_layout Plain Layout
1327 if (f needs access to non-public members of C)
1330 \begin_layout Plain Layout
1332 make f a friend of C;
1335 \begin_layout Plain Layout
1337 } else if (f needs type conversions on its left-most argument) {
1340 \begin_layout Plain Layout
1342 make f a non-member function;
1345 \begin_layout Plain Layout
1347 if (f needs access to non-public members of C)
1350 \begin_layout Plain Layout
1352 make f a friend of C;
1355 \begin_layout Plain Layout
1357 } else if (f can be implemented via C's public interface)
1360 \begin_layout Plain Layout
1362 make f a non-member function;
1365 \begin_layout Plain Layout
1370 \begin_layout Plain Layout
1372 make f a member function of C;
1381 \begin_layout Chapter
1385 \begin_layout Standard
1386 These are some rules for effective C++ programming.
1387 These are taken from Scott Meyers
1388 \begin_inset CommandInset citation
1394 , and are presented in their short form.
1395 These are not all the rules Meyers presents, only the most important of
1397 LyX does not yet follow these rules, but they should be the goal.
1400 \begin_layout Itemize
1401 use const and inline instead of #define
1404 \begin_layout Itemize
1405 use the same form in corresponding calls to new and delete, i.e.
1406 write delete[] obj; if new obj[n]; was used to create the object and write
1407 delete obj; if you wrote new obj; Notice strings should be std::string's
1408 instead of char *'s.
1410 \change_inserted 0 1288159280
1411 (this contradicts to
1412 \begin_inset CommandInset ref
1414 reference "Use-string-wherever"
1423 \begin_layout Itemize
1424 define a default constructor, copy constructor and an assignment operator
1425 for all classes with dynamically allocated memory that are not made noncopyable
1428 \begin_layout Itemize
1429 do not define default constructor, copy constructor and an assignment operator
1430 if the compiler generated one would do the same
1433 \begin_layout Itemize
1434 make destructors virtual in base classes and only there
1437 \begin_layout Itemize
1438 assign to all data members in operator=()
1441 \begin_layout Itemize
1442 strive for class interfaces that are complete and minimal
1445 \begin_layout Itemize
1446 differentiate among member functions, global functions and friend functions
1449 \begin_layout Itemize
1450 avoid data members in the public interface
1453 \begin_layout Itemize
1454 use const whenever possible
1457 \begin_layout Itemize
1458 pass and return objects by reference instead of by value
1461 \begin_layout Itemize
1462 choose carefully between function overloading and parameter defaulting
1465 \begin_layout Itemize
1466 never return a reference to a local object or a dereferenced pointer initialized
1467 by new within the function
1470 \begin_layout Itemize
1471 use enums for integral constants
1474 \begin_layout Itemize
1475 minimize compilation dependencies between files
1478 \begin_layout Itemize
1479 pay attention to compiler warnings
1482 \begin_layout Itemize
1483 differentiate between inheritance of interface and inheritance of implementation
1486 \begin_layout Itemize
1487 differentiate between inheritance and templates
1490 \begin_layout Itemize
1491 ensure that global objects are initialized before they are used
1494 \begin_layout Itemize
1495 avoid conditions to 'if' and 'while' that span more than a line
1498 \begin_layout Chapter
1503 \begin_layout Itemize
1504 And one of mine: (Lgb)
1508 \begin_layout Itemize
1510 \change_inserted 0 1288159389
1513 ching on enums, refrain from using "default:" if possible
1517 \begin_layout Itemize
1518 And one of mine: (Andre')
1522 \begin_layout Itemize
1523 try to implement your class in a way that the automatically generated copy
1524 constructor and copy assignment work out-of-the box
1527 \begin_layout Itemize
1528 I don't have problems with using boost in the implementation _if and only
1529 if_ it provides actual benefits over less intrusive alternatives.
1530 I do have a problem with needlessly sprinkling 'boost::' over interfaces,
1531 especially if it does not add any value.
1535 \begin_layout Standard
1536 Given that there seems to be an unconditional "typedef unsigned int quint32;"
1537 in qglobal.h I don't think there's any platform supported by current LyX
1538 that could not use 'unsigned int' (and an static assert in some implementation
1539 file for the unlikely case some ILP64 zombie raises its ugly head again.
1540 And if that happens, using <cstdint> would still be a better choice...)
1543 \begin_layout Standard
1544 The idea is to create something that's not compilable as soon as the condition
1546 There are lots of possibilities to achieve this, some examples follow:
1549 \begin_layout Standard
1550 In C++0x there's a "built-in":
1553 \begin_layout Standard
1554 \begin_inset listings
1558 \begin_layout Plain Layout
1560 static_assert(sizeof(int) == 4, "Funny platform")
1568 \begin_layout Standard
1569 until then on namespace scope:
1572 \begin_layout Standard
1573 \begin_inset listings
1577 \begin_layout Plain Layout
1579 #include <boost/static_assert.hpp> BOOST_STATIC_ASSERT(sizeof(int) == 4)
1587 \begin_layout Standard
1591 \begin_layout Standard
1592 \begin_inset listings
1596 \begin_layout Plain Layout
1598 template<bool Condition> struct static_assert_helper;
1601 \begin_layout Plain Layout
1603 template <> struct static_assert_helper<true> {};
1606 \begin_layout Plain Layout
1608 enum { dummy = sizeof(static_assert_helper<sizeof(int) == 4>)};
1616 \begin_layout Standard
1617 or somewhat brutish without templates, in any function:
1620 \begin_layout Standard
1621 \begin_inset listings
1625 \begin_layout Plain Layout
1627 const int d = sizeof(int) - 4;
1630 \begin_layout Plain Layout
1635 \begin_layout Plain Layout
1640 \begin_layout Plain Layout
1645 \begin_layout Plain Layout
1650 \begin_layout Plain Layout
1660 \begin_layout Standard
1661 Any of them in a .cpp file will break compilation as soon as sizeof(int)
1663 Personally I prefer something like the third version (or the first, if
1664 using C++0x is allowed).
1669 \begin_layout Itemize
1670 And one of mine: (vfr)
1674 \begin_layout Itemize
1676 \begin_inset Flex URL
1679 \begin_layout Plain Layout
1681 http://www.lyx.org/trac/changeset/35855
1690 \begin_layout Standard
1691 A dynamic_cast is necessary when:
1694 \begin_layout Itemize
1695 the object to be casted is from an external library because we can't add
1696 Qxxx::asXxxx() to Qt e.g.:
1700 \begin_layout Itemize
1701 QAbstractListModel to GuiIdListModel,
1704 \begin_layout Itemize
1705 QValidator to PathValidator,
1708 \begin_layout Itemize
1709 QWidget to TabWorkArea,
1712 \begin_layout Itemize
1713 QWidget to GuiWorkArea;
1717 \begin_layout Itemize
1718 the object is to be casted from an interface to the implementing class,
1719 because the Interface does not know by whom it is implemented:
1723 \begin_layout Itemize
1724 ProgressInterface to GuiProgress,
1727 \begin_layout Itemize
1728 Application to GuiApplication.
1732 \begin_layout Standard
1733 A dynamic_cast can be replaced by:
1736 \begin_layout Itemize
1737 already existing as***Inset() functions, e.g.:
1741 \begin_layout Itemize
1745 \begin_layout Itemize
1746 asInsetMath()->asMacro(),
1749 \begin_layout Itemize
1754 \begin_layout Itemize
1755 A static_cast when we are sure this can't go wrong, e.g.:
1759 \begin_layout Itemize
1760 we are sure that CellData::inset->clone() is an InsetTableCell,
1763 \begin_layout Itemize
1764 in cases where we explicitly check it->lyxCode().
1770 \begin_layout Bibliography
1771 \begin_inset CommandInset bibitem
1772 LatexCommand bibitem
1779 Effective C++, 50 Specific Ways to Improve Your Programs and Design.
1780 Addison-Wesley, 1992
1783 \begin_layout Bibliography
1784 \begin_inset CommandInset bibitem
1785 LatexCommand bibitem
1791 Exceptional C++: 47 engineering puzzles, programming problems, and solutions.
1795 \begin_layout Bibliography
1796 \begin_inset CommandInset bibitem
1797 LatexCommand bibitem
1802 Scott Meyers, C/C++ User's Journal (Vol.18,No.2)