Menu
▾
▴
oml-devel — OML Developers
You can subscribe to this list here.
| 2007 |
Jan
(15) |
Feb
|
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|
|
From: Tommaso C. <cuc...@ss...> - 2007-04-14 20:43:22
|
This is a list of the extensions of GCC that OML is currently using, or is going to use within a short time. Please, feel free to comment on it. GCC Extensions used within OML ======================================= Variadic macros allow to define printf-like macros with the ability to dump the calling function name, file name and line number from within the macro. The typeof() operator is used a lot in order to allow to write macros that are able to work with variables of different type. Also, it is useful to define macro-local variables where to copy macro args, thus avoiding multiple evaluation that is usually dangerous when there are side effects in the macro argument expressions. The __builtin_apply_arg() and __builtin_apply() functions are used in helper macros for declaring functions. These are useful to insert arbitrary code before the function call and after the function returns, e.g. for logging, benchmarking or synchronisation purposes. The __builtin_frame_address() function might be useful with the two builtin functions cited above for computing the stack-size of the function arguments, thus avoiding the waste of a fixed amount of bytes into the stack for wrappers. The nested functions extension to the C language should be useful to declare synchronised blocks of code. The __builtin_types_compatible_p() function may be used to emulate overriding of functions with same number of args but different types. The function should actually be a macro where the __builtin_types_compatible_p(), along with typeof(), discriminate among various types of a given argument. The unnamed structure feature allows, in the context of OO-like macros, the operations of a child class to access the fields of the parent class without the need to explicitly go through the father field. This is useful when the child does not want to deal with how many levels in the hierarchy it needs to go up, in order to find the field. The weak attribute on variables and functions could allow distribution of OML as a pure set of (completely portable) include files, that do not need any compilation process in order to be made available onto a machine. This would avoid the burden of building and distributing compiled libraries for different architectures, and it also would allow to a programmer to use OML by customising only the include path, without any need to customise also the library path and used libraries. Warning: this slows down compilation and linking processes, and adds the risk of accidental override of a library symbol by the application program, that almost certainly leads to hardly debuggable bugs. -- Tommaso Cucinotta, Computer Engineering PhD, Researcher ReTiS Lab, Scuola Superiore Sant'Anna, Pisa, Italy Tel +39 050 882 024, Fax +39 050 882 003 http://feanor.sssup.it/~tommaso |
|
From: Tommaso C. <cuc...@ss...> - 2007-03-06 01:19:06
|
The syntax quick tour page has been split into an entire site subsection
with a page dedicated to each OML type. Due to the lack of time, the
test cases for the various data types and operations have been reused as
quick tour of the syntax for the types and operations they test. The
good news is that, as the test cases will always be tested for
compilation and correctness for each OML release, the syntax quick tour
will consequently contain up-to-date and correct information.
T.
|
|
From: Cucinotta T. <cuc...@ss...> - 2007-01-24 18:07:17
|
After posting to the SF support area, I noticed a couple of other projects reporting similar problems (some of the subscribed users are not receiving messages) in the last few days. I guess the only practical solution, at the moment, is to not use this mailing list and post instead to the Development forum (which I'm currently monitoring) at: http://sourceforge.net/forum/forum.php?forum_id=654119 Bye, T. |
|
From: Cucinotta T. <cuc...@ss...> - 2007-01-23 15:10:50
|
I get your point. Then I think the current code is OK. I prefer "chk" to save a few key strokes. Regarding to the mailing list, have you received the confirmation email after subscription and replied it? -- Yes, this is going to be my 4th SF project, after all ! Also tried with another e-mail variant. I get administrative messages (welcome message and the sort), but not mine neither your posts (also enabled the deliver twice option, and deliver messages non-matching any filter -- all default options have always worked in the past. I'm going to contact the SF crew). T. |
|
From: Wei D. <wd...@Pr...> - 2007-01-23 14:14:41
|
I get your point. Then I think the current code is OK. I prefer "chk" to save a few key strokes. Regarding to the mailing list, have you received the confirmation email after subscription and replied it? - Wei Cucinotta Tommaso wrote: > I see you got the point in the existence of the various > macro. You're right, assertions are supposed to be used to > detect programming errors during development, therefore > they are optimized away in final releases (with a debug > level supposedly lower than DEBUG), while checks are > supposed to remain in production state, therefore there > are various actions undertakable when such conditions are > detected: > > - oml_check_exit: exit the program if condition not > satisfied > (for fast prototyping, not to be used in final > programs) > - oml_check_go: go to label if condition not satisfied > (typically at an error-recovery point) > - oml_check_ret: return a specified value if condition not > satisfied > > Maybe 'check' may be used in place of 'chk' for clarity > and uniformity with 'assert' macros. > > Whether to leave assertion expansion/elimination under the > control of the debugging level is still a mystery to me: > could it be meaningful to separate the two concepts ? > (adding sensitivity to a OML_ASSERT_ENABLED define). > > Couldn't figure out what's going on yet, but I don't > receive any message from the list, thus I'm reading from > the on-line archives :-(. Tried options, subscribe, > unsubscribe, resubscribe, no way. > > Bye, > > T. > > The web site is very nice. > > I just realized a possible bug in the Syntax Quick Tour. > Statements > like the following are used very often > > oml_assert_ok(oml_vector_init(&v, 16)); > > However, when you disable assert, the vector init code is > optimized > out. I think oml_chk_exit might be > more suitable. I'm wondering if it's appropriate to make > assert > generate the tested code even if assert is > disabled. > > BTW, I've signed up for the mailing list. So please just > send emails to > the mailing list. > > Best, > > - Wei > > I've signed up for the mailing list, so please send the > further > > ------------------------------------------------------------------------- > 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 > _______________________________________________ > Oml-devel mailing list > Oml...@li... > https://lists.sourceforge.net/lists/listinfo/oml-devel > |
|
From: Cucinotta T. <cuc...@ss...> - 2007-01-23 14:06:06
|
I see you got the point in the existence of the various macro. You're right, assertions are supposed to be used to detect programming errors during development, therefore they are optimized away in final releases (with a debug level supposedly lower than DEBUG), while checks are supposed to remain in production state, therefore there are various actions undertakable when such conditions are detected: - oml_check_exit: exit the program if condition not satisfied (for fast prototyping, not to be used in final programs) - oml_check_go: go to label if condition not satisfied (typically at an error-recovery point) - oml_check_ret: return a specified value if condition not satisfied Maybe 'check' may be used in place of 'chk' for clarity and uniformity with 'assert' macros. Whether to leave assertion expansion/elimination under the control of the debugging level is still a mystery to me: could it be meaningful to separate the two concepts ? (adding sensitivity to a OML_ASSERT_ENABLED define). Couldn't figure out what's going on yet, but I don't receive any message from the list, thus I'm reading from the on-line archives :-(. Tried options, subscribe, unsubscribe, resubscribe, no way. Bye, T. The web site is very nice. I just realized a possible bug in the Syntax Quick Tour. Statements like the following are used very often oml_assert_ok(oml_vector_init(&v, 16)); However, when you disable assert, the vector init code is optimized out. I think oml_chk_exit might be more suitable. I'm wondering if it's appropriate to make assert generate the tested code even if assert is disabled. BTW, I've signed up for the mailing list. So please just send emails to the mailing list. Best, - Wei I've signed up for the mailing list, so please send the further |
|
From: Cucinotta T. <cuc...@ss...> - 2007-01-23 13:46:45
|
|
From: Cucinotta T. <cuc...@ss...> - 2007-01-23 13:35:58
|
Cannot receive messages from this list, yet. |
|
From: Tommaso C. <cuc...@ss...> - 2007-01-23 09:17:40
|
Sorry. |
|
From: Tommaso C. <cuc...@ss...> - 2007-01-23 09:12:54
|
Please, ignore it once again (I'm not receiving any list message). |
|
From: Tommaso C. <cuc...@ss...> - 2007-01-23 09:03:45
|
Please, ignore it. |
|
From: Wei D. <wd...@Pr...> - 2007-01-22 14:17:11
|
The web site is very nice. I just realized a possible bug in the Syntax Quick Tour. Statements like the following are used very often oml_assert_ok(oml_vector_init(&v, 16)); However, when you disable assert, the vector init code is optimized out. I think oml_chk_exit might be more suitable. I'm wondering if it's appropriate to make assert generate the tested code even if assert is disabled. BTW, I've signed up for the mailing list. So please just send emails to the mailing list. Best, - Wei I've signed up for the mailing list, so please send the further Tommaso Cucinotta wrote: > Hi, > > I've just set-up very quickly a website for the project > > http://oml.sourceforge.net > > and I've put a few documentation on the API and syntax related > to the container types in the description page. > > http://oml.sourceforge.net/documentation-description.php > > The syntax quick tour in the documentation pages partially reflects > the status of the code that may be found on the project CVS: > > http://sourceforge.net/cvs/?group_id=186855 > > I hope to manage to keep it as up-to-date as possible. > > Please, check it out and provide any comments, suggestions, etc... > > On-line browsable doxygen-generated documentation is to come soon. > > Bye, > > T. > > > ------------------------------------------------------------------------- > 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 > _______________________________________________ > Oml-devel mailing list > Oml...@li... > https://lists.sourceforge.net/lists/listinfo/oml-devel > |
|
From: Tommaso C. <cuc...@ss...> - 2007-01-22 09:59:33
|
Hi, I've just set-up very quickly a website for the project http://oml.sourceforge.net and I've put a few documentation on the API and syntax related to the container types in the description page. http://oml.sourceforge.net/documentation-description.php The syntax quick tour in the documentation pages partially reflects the status of the code that may be found on the project CVS: http://sourceforge.net/cvs/?group_id=186855 I hope to manage to keep it as up-to-date as possible. Please, check it out and provide any comments, suggestions, etc... On-line browsable doxygen-generated documentation is to come soon. Bye, T. |
|
From: Cucinotta T. <cuc...@ss...> - 2007-01-21 20:09:31
|
On Sun, 21 Jan 2007 12:53:01 -0500
Wei Dong <wd...@Pr...> wrote:
>I think this design will probably satisfy everybody. A
>separately allocated
>link node containing only the pointers will be cost
>something like 16~32 bytes,
>and it can be saved by using the embedded style macros.
> I think the cost
>of keeping a pointer to the linked item inside
>oml_list_node can be neglected
>in most cases.
Hope so.
>There's one thing left I'm not sure: how can we get back
>a correct typed pointer
>from oml_list_node?
Following the same syntax paradigm you can find in
oml_heap.h, it will be something like:
typedef struct myType *pMyType;
struct myType {
oml_list_node(pMyType) free_list_node;
oml_list_node(pMyType) full_list_node;
}
so the type is implicitly printed into the node structure.
I was thinking to use (not sure yet) a solution similar to
yours, with "fake" container element(s), in order to write
generic algorithms without having to repeat involved types
in macros.
For instance, I could instantiate an iterator into a
generic operation:
#define op(p_container) do {
typeof(*p_container->p_fake_iterator) __it;
for (
oml_iterate(p_container, &__it);
oml_has_next(p_container, &__it);
) {
typeof(*p_container->p_fake_value) __value;
oml_get(__it, &__value);
/* .. do something .. */
}
}
>Following is the way I think of,
>assuming we have a "void *"
>pointer pointing to the value in oml_list_node.
>
>1. "oml_list(myItem *) free_list; " is expanded to
>something like the following
>
>struct {
> oml_list_node head;
> myItem type[0]; /* only keep type information, no
>memory is used */
>} free_list;
>
>So that the type information is saved in free_list.
>
>2. When we need to extract a value from oml_list_node, we
>use the following
>macro:
>
>#define oml_list_value(list, node) \
>(typeof((list)->type[0]))((node)->pvalue)
>
>Should that be something to be implemented in OML? Maybe
>you have a
>better idea.
I guess so. Guess the container will not be needed,
because the node->value variable will already have the
correct type.
Bye,
T.
>
>
>Thanks,
>
>- Wei
>
>
>Cucinotta Tommaso wrote:
>> Right. The approach I prefer, in these cases, is to
>>expose
>> an embeddable "node" type, which, in at least some
>>cases,
>> is identical to the "iterator" type. The embeddable
>> node may reside wherever you want, it is not constrained
>> to reside within the type you are adding to the
>>collection,
>> even if it is probably the most meaningful choice, and
>>you
>> may have more than one embeddable node referring to the
>>same
>> item, but used in different collections.
>>
>> When declaring your item type, it resembles really much
>>the list.h
>> approach:
>>
>> struct myItem {
>> oml_list_node free_node; /**< Node for linking in one
>>list */
>> oml_list_node full_node; /**< Node for linking in
>>another list */
>> };
>>
>> When performing operations, you pass explicitly the
>>pointer
>> to the embeddable node, instead of the field name:
>>
>> oml_list(myItem *) free_list;
>> oml_list(myItem *) full_list;
>> myItem value;
>>
>> oml_list_add(&free_list, &value); // Don't care about
>>the node
>> oml_list_add_node(&free_list, &value, &value.free_node);
>>//
>> Application provides the node
>>
>> With a standard linked list, the first call allocates a
>>node, makes it
>> point to the value, links it to the list.
>> The second call only links the provided node into the
>>list and makes
>> it point to the value.
>>
>> oml_list_del(&list, &value); // OML deallocates the node
>> oml_list_del_node(&list, &value.free_node); // OML only
>>unlinks the
>> node, without deallocating it; probably the node is
>>invalidated.
>>
|
|
From: Wei D. <wd...@Pr...> - 2007-01-21 17:53:11
|
I think this design will probably satisfy everybody. A separately allocated
link node containing only the pointers will be cost something like 16~32
bytes,
and it can be saved by using the embedded style macros. I think the cost
of keeping a pointer to the linked item inside oml_list_node can be
neglected
in most cases.
There's one thing left I'm not sure: how can we get back a correct typed
pointer
from oml_list_node? Following is the way I think of, assuming we have a
"void *"
pointer pointing to the value in oml_list_node.
1. "oml_list(myItem *) free_list; " is expanded to something like the
following
struct {
oml_list_node head;
myItem type[0]; /* only keep type information, no memory is used */
} free_list;
So that the type information is saved in free_list.
2. When we need to extract a value from oml_list_node, we use the following
macro:
#define oml_list_value(list, node) \
(typeof((list)->type[0]))((node)->pvalue)
Should that be something to be implemented in OML? Maybe you have a
better idea.
Thanks,
- Wei
Cucinotta Tommaso wrote:
> Right. The approach I prefer, in these cases, is to expose
> an embeddable "node" type, which, in at least some cases,
> is identical to the "iterator" type. The embeddable
> node may reside wherever you want, it is not constrained
> to reside within the type you are adding to the collection,
> even if it is probably the most meaningful choice, and you
> may have more than one embeddable node referring to the same
> item, but used in different collections.
>
> When declaring your item type, it resembles really much the list.h
> approach:
>
> struct myItem {
> oml_list_node free_node; /**< Node for linking in one list */
> oml_list_node full_node; /**< Node for linking in another list */
> };
>
> When performing operations, you pass explicitly the pointer
> to the embeddable node, instead of the field name:
>
> oml_list(myItem *) free_list;
> oml_list(myItem *) full_list;
> myItem value;
>
> oml_list_add(&free_list, &value); // Don't care about the node
> oml_list_add_node(&free_list, &value, &value.free_node); //
> Application provides the node
>
> With a standard linked list, the first call allocates a node, makes it
> point to the value, links it to the list.
> The second call only links the provided node into the list and makes
> it point to the value.
>
> oml_list_del(&list, &value); // OML deallocates the node
> oml_list_del_node(&list, &value.free_node); // OML only unlinks the
> node, without deallocating it; probably the node is invalidated.
>
|
|
From: Cucinotta T. <cuc...@ss...> - 2007-01-21 13:29:33
|
On Sat, 20 Jan 2007 14:17:38 -0500
Wei Dong <wd...@Pr...> wrote:
>This style of code is very much what I wanted.
Nice to hear.
>Actually I'm using something pretty similar in my projects
>(see attachment for my version of array.h and heap.h).
Let me see if I can comment on that later...
> Following are some my ideas. I don't have much
>programming experience, so I'm sure I'm missing some
>practical considerations.
Never mind. I'm sure discussion is useful anycase.
>1. I think heap.h should be the model to implement other
>data structures. I'm wondering if you are planning to
>convert queue.h to something like that.
I already adapted oml_queue.h to the oml_heap and
oml_eheap interface. Check out cvs on SF.
>2. I agree with you by exploiting the GCC syntax
>extension, we'll be able to make some things much simpler.
>I use "typeof" a lot so I can avoid passing a type to a
>macro. Maybe that worths compromising some of
>portability. But given GCC's popularity, that might not
>be big deal.
Agree.
>3. Though not very elegant, I think the embedded link
>structure in the Linux list.h or BSD queue.h might be
>helpful, because they let you easily link a node to more
>than one list.
Right. The approach I prefer, in these cases, is to expose
an embeddable "node" type, which, in at least some cases,
is identical to the "iterator" type. The embeddable
node may reside wherever you want, it is not constrained
to reside within the type you are adding to the
collection,
even if it is probably the most meaningful choice, and you
may have more than one embeddable node referring to the
same
item, but used in different collections.
When declaring your item type, it resembles really much
the list.h approach:
struct myItem {
oml_list_node free_node; /**< Node for linking in one
list */
oml_list_node full_node; /**< Node for linking in
another list */
};
When performing operations, you pass explicitly the
pointer
to the embeddable node, instead of the field name:
oml_list(myItem *) free_list;
oml_list(myItem *) full_list;
myItem value;
oml_list_add(&free_list, &value); // Don't care about the
node
oml_list_add_node(&free_list, &value, &value.free_node);
// Application provides the node
With a standard linked list, the first call allocates a
node, makes it point to the value, links it to the list.
The second call only links the provided node into the list
and makes it point to the value.
oml_list_del(&list, &value); // OML deallocates the node
oml_list_del_node(&list, &value.free_node); // OML only
unlinks the node, without deallocating it; probably the
node is invalidated.
>I believe of course exposing something like
>"head.lh_first" to the user is bad practice, but that can
>be easily prevented by a couple of macros. It does not
>necessarily need to break into your data structure.
>Instead we can just let the user explicitly define the
>encapsulating node structure, as the following example:
>
>typedef struct
>{
> url_t url; /* The original structure. Not using a
>pointer to
>url_t to avoid memory fragments */
> oml_llist_entry(tree_link); /* let you link to a
>list */
> oml_lheap_entry(heap_link); /* let you link to a
>heap */
>} url_node_t;
I guess I clarified above I plan to keep the same
functionality, with a slight different paradigm of use.
>The bad thing is we can not avoid passing the structure
>field as a macro params, which I'm sure you don't like :
>). Just raise the problem for consideration. At least
>that can be one way to uniformly describe everything.
You're right: I don't like it, and everytime I dig into
the Linux kernel and I see these field names around I get
really confused. Of course, it's just due to my
little/poor experience with that interface.
Please, think about my above interface proposal
(embeddable node) and drop me a comment (on the project
mailing list, if you can).
>4. In terms of heap and other ordered structure, I think
>sometimes people don't want to keep another copy of the
>key given that the key is often included in the value it
>self, and the key might be more than a single integer and
>cost significant memory overhead. I'd prefer maintain a
>single value and always let the user pass the comparator
>as a macro parameter.
I see memory occupation is a concern for you. This
probably
prevents you from liking too much what I just proposed
above, as it is of course optimizable, assuming the list
node is embedded into the value itself, provided that you
know the node offset within the value (list.h approach).
Concerning the comparator, if you see eheap.h I already
provided the less-than comparator as an argument to two
separate operations for inserting and deleting with a
custom comparator (oml_eheap_add_lt). I want to keep the
default operations without that param, as in most cases
you will use a key type that simply compares with "<".
Maybe in some cases OML will be able to provide a couple
of
container variants, if I have enough free time for that.
>5. To provide an "foreach" macro for each container might
>be useful, as I have defined in my array.h. Consider the
>following example
> oml_array(url_t) urls;
> ...
> oml_array_foreach_begin(urls, url) {
> ... something to do with each url ...
> } oml_array_foreach_end(urls, url);
>
> I believe "foreach" (not assuming visiting order) is
>a paradigm
>which cannot be replaced by "for (;;)" in C.
> Of course, iterator is definitely to be kept for more
>flexibility.
I think it will be possible to write, in the oml_algo.h
"package", a generic foreach algorithm that uses
iterators.
Also, I think we do not need the oml_array_foreach_end
macro, therefore the paradigm of use will be exactly what
you wrote without the ending macro.
>6. I suggest provide an abstraction for the conditions
>and mutexes which are to be mapped to pthread or other
>implementation, if oml is to be used in kernel developing.
Yes, I was thinking to something like that. It would be
supposed to help in writing, into the Linux kernel, a
monitor-like synchronized type (missing an unlock into the
kernel results into immediate machine crash -- I wish I
could manage to write something that helps in that
direction -- maybe it's impossible, yet don't know).
>7. Many containers need to be synchronized. It seems
>painful to provide an oml_sync_queue for oml_queue,and an
>oml_sync_heap for oml_heap, etc. Maybe it's not
>avoidable.
I'm sure the synchronized types need to exist separately,
but they will rely on the unsync versions for the
functionality. On the interface level, it is not possible
to unify it, unless we switch to heavy use of OO
inheritance (virtual functions), which I'd like to avoid
as much as possible (it is somewhat opposite to the
macro/template-like approach).
>8. I believe exception handling will be a most
>appreciated feature by the C folks. I'll try to propose a
>scheme later, but I'm sure you must have some idea on it.
I already have an implementation, based on
setjmp()/longjmp() of course. I just need to find where I
backed it up a few years ago. I'd like to refactor it by
using a OML stack type.
>9. Finally, given the fact that C does not support some
>of the features necessary for abstraction, like operator
>overriding, we might not be able to encapsulate everything
>as neatly as we want. I think so long as the library is
>designed so that the rules are easy to understand and
>remember, it doesn't hurt much to expose a little of the
>inside mechanisms to the user.
>
>Again, these points are just for consideration and I'm not
>pretty sure that they all make sense.
Thanks for your contribution -- I hope to hear more
comments from you as more code is published into the cvs
(I guess I'll need a couple of months before making an
official release).
Bye,
T.
>Best,
>
>- Wei
>
>Cucinotta Tommaso wrote:
>> Hi,
>>
>> I just created a ML for the project and filled up the SF
>>cvs with some
>> contents. I'm curious to hear these ideas from your
>>side.
>>
>> Bye,
>>
>> T.
>>
>> On Thu, 18 Jan 2007 10:27:26 -0500
>> Wei Dong <wd...@Pr...> wrote:
>>> Nice to hear from you. The proposed syntax is pretty
>>>nice and I kind
>>> of have some idea about how encapsulation is realized.
>>> Waiting for
>>> more materials to appear in sourceforge.
>>>
>>> Thank you very much.
>>>
>>> - Wei
>>>
>>> Cucinotta Tommaso wrote:
>>>> Hi Wei,
>>>>
>>>> I'm just getting impressed from the fact of seeing a
>>>>potential
>>>> interest for the project before I actually knew it had
>>>>been approved
>>>> in the SF workflow.
>>>>
>>>> On Wed, 17 Jan 2007 12:57:31 -0800
>>>> "Wei Dong" <wdo...@us...> wrote:
>>>>
>>>>> finally come up to you project page. Are there any
>>>>>working
>>>>> source code available so far?
>>>>
>>>> Some. I have various reusable components which I'd like
>>>>to refactor
>>>> with a uniform API, especially with a generic API
>>>>(template-like),
>>>> through a heavy use of macros. Not really sure the macro
>>>>paradigm is
>>>> preferrable to the "void *" one, but I'd like to
>>>>experiment with it
>>>> in this project.
>>>>
>>>> Summarizing:
>>>> - queue
>>>> - synchronized queue
>>>> - debugging (with levels and the sort)
>>>> - array-based heap
>>>> - array-based quick-extractable heap
>>>> - tree-based heap
>>>> - exception handling
>>>>
>>>> Aim of the project: reaching a full-featured set of
>>>>commonly needed
>>>> functionality: containers, synchronized and non,
>>>>monitors/condition
>>>> vars (pthread-based), debugging, OO-typing, exceptions,
>>>>safe memory
>>>> management (leakages detection), ...
>>>>
>>>> Just an idea of the syntax, here is my heap sample
>>>>usage:
>>>> (from aquosa.sf.net LGPL license):
>>>>
>>>> #include "oml_heap.h"
>>>>
>>>> oml_define_heap(int, int); // template-like syntax
>>>>
>>>> #define HEAP_BITS 3
>>>> #define HEAP_SIZE (1 << HEAP_BITS)
>>>>
>>>> oml_heap_t(int, int) h;
>>>> rv = oml_heap_init(&h, HEAP_BITS);
>>>> rv = oml_heap_add(&h, 4, 20);
>>>> rv = oml_heap_get_min(&h, &k, &v);
>>>>
>>>> I'd like to exploit as much as possible GNU C extensions
>>>> in GCC, especially for macros, in order to attain a nice
>>>> syntax (I'm suspecting nested functions will help me
>>>>with
>>>> synchronization primitives, as an example).
>>>>
>>>>> I'm writing programs in C and am unhappy with the fact
>>>>>that
>>>>> there's not a good "template" library available.
>>>>
>>>> Agree of course.
>>>>
>>>>> Personally
>>>>> I find the "/sys/queue.h" is a good model to implement
>>>>> general data structure algorithms, and I'm thinking of
>>>>> implement some data structure (heap) that I need in that
>>>>> way.
>>>>
>>>> Not bad, even if arrays and queues are the most trivial
>>>> things to do. I see the focus is on embeddable
>>>>structures,
>>>> which are invasive on your data structures (ala
>>>> include/linux/list.h), I'd prefer to
>>>> focus on a non-embeddable API, and see the capability of
>>>> providing an embeddable node as an add-on. API should
>>>>not have names
>>>> of structure fields used as params, IMHO, unless I'm
>>>>writing macros
>>>> for serialization.
>>>>
>>>> I love encapsulation, and I'd never have smth. like you
>>>> can see on the man page of sys/queue.h:
>>>>
>>>> for (np = head.lh_first; np != NULL; np =
>>>>np->entries.le_next)
>>>>
>>>> which is accessing internals of LIST and TQ macros.
>>>> Iterator should be completely abstracted; data type
>>>>should
>>>> be completely opaque to the programmer (cmp Java JCF).
>>>>
>>>>> I just don't want to waste my labor if there's already
>>>>> such code available. I'll also by happy if there's a
>>>>> project which I can contribute my code to.
>>>>
>>>> I'd be happy too if I had a contributor.
>>>>
>>>>> I also found an other library called sglib, which I
>>>>>think
>>>>> might have similar goal as OML. It's homepage is at
>>>>
>>>> So it seems. Doesn't seem to have been maintained for a
>>>>while. I'd
>>>> like to focus on synchronization and "portable"
>>>>kernel-level /
>>>> user-level code. Seems out of the scope of sglib.
>>>>
>>>> Bye,
>>>>
>>>> T.
>>>
>>
>
|
|
From: Cucinotta T. <cuc...@ss...> - 2007-01-19 23:39:36
|
Hi,
I just created a ML for the project and filled up the SF
cvs with some contents. I'm curious to hear these ideas
from your side.
Bye,
T.
On Thu, 18 Jan 2007 10:27:26 -0500
Wei Dong <wd...@Pr...> wrote:
>Nice to hear from you. The proposed syntax is pretty
>nice and I kind of have some idea about how encapsulation
>is realized. Waiting for more materials to appear in
>sourceforge.
>
>Thank you very much.
>
>- Wei
>
>Cucinotta Tommaso wrote:
>> Hi Wei,
>>
>> I'm just getting impressed from the fact of seeing a
>>potential
>> interest for the project before I actually knew it had
>>been approved
>> in the SF workflow.
>>
>> On Wed, 17 Jan 2007 12:57:31 -0800
>> "Wei Dong" <wdo...@us...> wrote:
>>
>>> finally come up to you project page. Are there any
>>>working
>>> source code available so far?
>>
>> Some. I have various reusable components which I'd like
>>to refactor
>> with a uniform API, especially with a generic API
>>(template-like),
>> through a heavy use of macros. Not really sure the macro
>>paradigm is
>> preferrable to the "void *" one, but I'd like to
>>experiment with it in
>> this project.
>>
>> Summarizing:
>> - queue
>> - synchronized queue
>> - debugging (with levels and the sort)
>> - array-based heap
>> - array-based quick-extractable heap
>> - tree-based heap
>> - exception handling
>>
>> Aim of the project: reaching a full-featured set of
>>commonly needed
>> functionality: containers, synchronized and non,
>>monitors/condition
>> vars (pthread-based), debugging, OO-typing, exceptions,
>>safe memory
>> management (leakages detection), ...
>>
>> Just an idea of the syntax, here is my heap sample
>>usage:
>> (from aquosa.sf.net LGPL license):
>>
>> #include "oml_heap.h"
>>
>> oml_define_heap(int, int); // template-like syntax
>>
>> #define HEAP_BITS 3
>> #define HEAP_SIZE (1 << HEAP_BITS)
>>
>> oml_heap_t(int, int) h;
>> rv = oml_heap_init(&h, HEAP_BITS);
>> rv = oml_heap_add(&h, 4, 20);
>> rv = oml_heap_get_min(&h, &k, &v);
>>
>> I'd like to exploit as much as possible GNU C extensions
>> in GCC, especially for macros, in order to attain a nice
>> syntax (I'm suspecting nested functions will help me
>>with
>> synchronization primitives, as an example).
>>
>>> I'm writing programs in C and am unhappy with the fact
>>>that
>>> there's not a good "template" library available.
>>
>> Agree of course.
>>
>>> Personally
>>> I find the "/sys/queue.h" is a good model to implement
>>> general data structure algorithms, and I'm thinking of
>>> implement some data structure (heap) that I need in that
>>> way.
>>
>> Not bad, even if arrays and queues are the most trivial
>> things to do. I see the focus is on embeddable
>>structures,
>> which are invasive on your data structures (ala
>>include/linux/list.h),
>> I'd prefer to
>> focus on a non-embeddable API, and see the capability of
>> providing an embeddable node as an add-on. API should
>>not have names
>> of structure fields used as params, IMHO, unless I'm
>>writing macros
>> for serialization.
>>
>> I love encapsulation, and I'd never have smth. like you
>> can see on the man page of sys/queue.h:
>>
>> for (np = head.lh_first; np != NULL; np =
>>np->entries.le_next)
>>
>> which is accessing internals of LIST and TQ macros.
>> Iterator should be completely abstracted; data type
>>should
>> be completely opaque to the programmer (cmp Java JCF).
>>
>>> I just don't want to waste my labor if there's already
>>> such code available. I'll also by happy if there's a
>>> project which I can contribute my code to.
>>
>> I'd be happy too if I had a contributor.
>>
>>> I also found an other library called sglib, which I
>>>think
>>> might have similar goal as OML. It's homepage is at
>>
>> So it seems. Doesn't seem to have been maintained for a
>>while. I'd
>> like to focus on synchronization and "portable"
>>kernel-level /
>> user-level code. Seems out of the scope of sglib.
>>
>> Bye,
>>
>> T.
>
|
