@@ -13,6 +13,7 @@ This repository contains external libraries for use with C3.
13
13
- PQ (PostgreSQL) https://www.postgresql.org/docs/current/libpq.html
14
14
- MySQL 8 https://dev.mysql.com/doc/c-api/8.0/en/
15
15
- SQLite 3 https://sqlite.com/c3ref/intro.html
16
+ - FreeType https://freetype.org/ - WIP
16
17
17
18
## Guide for writing bindings
18
19
@@ -23,13 +24,13 @@ rewritten to work in C3, and one also have to consider the namespacing C3 will a
23
24
24
25
1 . Keep names predicable so that a user who knows the name in C can easily find the name in C3.
25
26
2 . Avoid changing the names to conform to some other style, even if it's the C3 standard. By keeping the original name it's much
26
- easier to drop in code examples and to see exactly what is the library code. Users can write 'C3-like' wrappers later,
27
+ easier to drop in code examples and to see exactly what is the library code. Users can write 'C3-like' wrappers later,
27
28
but that can be added when the "raw" functions are already there.
28
29
29
30
### Module name
30
31
31
32
The user will use the last component in the module name you choose, shorter names
32
- are often appreciated, if possible. But also make sure that the full name
33
+ are often appreciated, if possible. But also make sure that the full name
33
34
is unique. ` com::mylib::asyncio ` is better than ` asyncio ` .
34
35
35
36
### Function names
@@ -57,16 +58,16 @@ options:
57
58
When converting OS functions, then (1) is sometimes fine. Otherwise, prefer (2).
58
59
59
60
1 . Don't change anything more about the name, at most add the prefix or change the first character to lower case.
60
- 2 . If (2) is used, pick a module name where the library source is immediately obvious.
61
- For example, imagine ` module mylib::ui; ` was used, and now ` ui::openWindow(...) `
61
+ 2 . If (2) is used, pick a module name where the library source is immediately obvious.
62
+ For example, imagine ` module mylib::ui; ` was used, and now ` ui::openWindow(...) `
62
63
is suddenly super unclear.
63
64
3 . For bindings to OS libraries, use the name of the OS as the last module component,
64
65
e.g. ` module std::os::win32 ` , ` module std::os::posix ` , ` module std::os::darwin ` etc.
65
66
66
67
### Type names
67
68
68
69
Types will in general not be prefixed as long as they're unique,
69
- but if the library uses very common names, there is a risk for
70
+ but if the library uses very common names, there is a risk for
70
71
name collision.
71
72
72
73
#### Type names that are not valid C3 type names
@@ -103,7 +104,7 @@ types, then that type should be prefixed as well, so `Win32_Foo`.
103
104
104
105
For bindings that use ` int ` , ` char ` etc, there are two options:
105
106
106
- 1 . Use ` CInt ` , ` CChar ` and others. This maximizes compatibility and allows
107
+ 1 . Use ` CInt ` , ` CChar ` and others. This maximizes compatibility and allows
107
108
the binding to be correct on platforms that might have 16-bit ints.
108
109
2 . Just use C3 ` int ` for ` int ` , ` char ` for ` char ` .
109
110
3 . Unless the sign of the ` char ` is important, replace C ` char ` by ` char ` and not ` CChar ` .
@@ -112,7 +113,7 @@ If it's known that the C type in the binding will always match the C3 size,
112
113
then prefer (2) for that type.
113
114
114
115
For example, on MacOS and Win32 an ` int ` in C will always be the same size as in C3,
115
- so use ` int ` rather than ` CInt ` if you are making a binding for
116
+ so use ` int ` rather than ` CInt ` if you are making a binding for
116
117
OS libraries. However, the ` long ` in C may differ, so use ` CLong ` for that.
117
118
118
119
#### C strings (char * )
@@ -122,8 +123,8 @@ much more convenience for the user.
122
123
123
124
### Translating enums
124
125
125
- For simple C enums that are implicitly sequential, i.e. they start at 0 with no break,
126
- C3 enums can be used unchanged. There is no need to set the type of the
126
+ For simple C enums that are implicitly sequential, i.e. they start at 0 with no break,
127
+ C3 enums can be used unchanged. There is no need to set the type of the
127
128
enum as C3 enum sizes will default to C int size. So use ` enum Foo { ... } `
128
129
not ` enum Foo : int { ... } ` .
129
130
@@ -136,7 +137,7 @@ my_constant -> MY_CONSTANT
136
137
MyConstant -> MY_CONSTANT
137
138
```
138
139
139
- If simple enums are used, then (consistently for the entire binding)
140
+ If simple enums are used, then (consistently for the entire binding)
140
141
pick one of the following:
141
142
142
143
1 . Remove any namespacing prefix, but don't remove suffixes. (Usually recommended)
@@ -161,7 +162,7 @@ enum Button
161
162
{
162
163
ANY_TYPE,
163
164
CANCEL_TYPE,
164
- }
165
+ }
165
166
// 2. Full name:
166
167
enum Button
167
168
{
@@ -181,7 +182,7 @@ from simple to more complex.
181
182
182
183
##### Declaring a regular constant
183
184
184
- This is simply
185
+ This is simply
185
186
186
187
``` c
187
188
const GL_TEXTURE_2D = ...`
@@ -201,9 +202,9 @@ CInt / int.
201
202
202
203
##### Using a distinct type
203
204
204
- In this case we first define a distinct type,
205
+ In this case we first define a distinct type,
205
206
matching the enum name, then use constant but with
206
- the distinct type. This is a better experience for
207
+ the distinct type. This is a better experience for
207
208
the user and is recommended.
208
209
209
210
The same recommendation regarding ` @builtin `
@@ -236,7 +237,7 @@ We can model this as:
236
237
// Define the distinct type
237
238
distinct Button = CInt;
238
239
239
- // Create a specific sub module based on the enum name
240
+ // Create a specific sub module based on the enum name
240
241
module mylib::ui::button;
241
242
242
243
// Place the constants inside
0 commit comments