...does what it says on the tin. Nargery : comments.
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|---|---|---|---|---|---|
|
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
|
(no subject)
For your library you can decorate the functions with the representation and the user-facing header file can pick the right implementation for the selected algorithm by defining the publicly visible function name to the appropriate decorated one.
However, having callers know the representation, at the level of having macros that need to understand it, etc, is going to lose you type-safety at link time.
My usual approach for differing types with a common interface is the same as that used by Berkeley DB; the object representing the graph contains, or contains a pointer to, a table of function pointers, and all the knowledge of the underlying representation is hidden behind that. The only time your program ever knows the representation is when it requests the library to create it a new graph.
(no subject)
(no subject)