1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
|
<html>
<head>
<META NAME="copyright" CONTENT="Copyright 2001 by MandrakeSoft S.A.">
<META NAME="Author" CONTENT="Kevin Lawton">
<META HTTP-EQUIV="Content-Type" CONTENT="text/html;CHARSET=iso-8859-1">
<TITLE>Coding Guidelines For Bochs</TITLE>
</head>
<body TEXT="#000000" BGCOLOR="#ececec" LINK="#3333cc" VLINK="#666666">
<center><h1>Coding Guidelines For Bochs</h1></center>
<br>
<ul>
<li> <u>Don't make use of any external C++ classes.</u> They are not offered
on all platforms and this would make bochs non-portable. There is use of
such classes in the optional debugger. I plan on removing this use.
<li> <u>Don't use fancy C++ features.</u> Bochs is incredibly
performance sensitive, and will be increasingly so as more speed
enhancements are added. There's a time and place for most
everything and this is not it. Some advanced features
create overhead in the generated code that you don't see.
They also convolute the code, and sometimes occlude
what is really going on.
<ul>
<li> Don't use templates.
<li> Don't use virtual functions.
<li> Don't use C++ exceptions.
<li> Don't use overloading of any kind.
</ul>
<li> <u>Use soft tabs.</u> At least when you submit code, convert all
hard tabs to spaces. There is no uniform way to handle
tabs properly.
<li> <u>Prefix screen spew with a pound sign ('#').</u>
If you want to spew something out to the screen rather than
the bochs.out file, send it to stderr (not stdout), and prefix the string
with a pound sign. This is so that a text interface which
drives bochs (the debugger) can discern between messages and
command responses.
<li> <u>Please do compile with all warnings turned on.</u> It's really
difficult to spot interesting warnings when a compile is littered
with non-interesting ones.
<li> <u>Don't use signed ints where unsigned will do.</u>
</ul>
</body>
</html>
|
