First login?
Lost password?
 
 
sctp-discussion AT lists.franken.de 
SCTP Discussions

Text archives Help


Re: [SCTP-Discussion] New to sctplib / impl. without glib?


Chronological Thread 
  • From: Michael Tuexen <Michael.Tuexen AT micmac.franken.de>
  • To: Carsten Fuchs <CarstenFuchs AT T-Online.de>, Irene Rüngeler <I.Ruengeler AT fh-muenster.de>
  • Cc: sctp-discussion AT sctp.de
  • Subject: Re: [SCTP-Discussion] New to sctplib / impl. without glib?
  • Date: Tue, 5 Feb 2008 18:12:32 +0100
  • List-archive: <http://lists.franken.de/pipermail/sctp-discussion>
  • List-id: SCTP Discussions <sctp-discussion.sctp.de>
Hi Carsten,

see my comments in-line.

Best regards
Michael

On Feb 5, 2008, at 4:01 PM, Carsten Fuchs wrote:

Hi,

Thomas Dreibholz wrote:
On Freitag, 1. Februar 2008, Carsten Fuchs wrote:
[...]
Well, I was wondering what your plans wrt. glib are.
Are you planning to get rid of it?
Since glib is already installed on almost every Linux/FreeBSD/... system, I have never thought about replacing it. However, it should not be very difficult to do this. Writing a wrapper providing GList, GArray and the type definitions should already be sufficient. So, if you write such a wrapper, we could integrate it.

Thank you very much for your reply!
I tried several approaches for a wrapper over the weekend, but was not entirely satisfied with any of them.

The big question is, how much/many changes/inconveniences/trouble would you accept in a wrapper to still integrate it with the "official" sctplib?

[1] Personally, I'd just rename all *.c to *.cpp and replace the GArray with std::vector<> and GList with std::list<>.
The sctplib is written in C and this should not be changed. That means that the file extension should
be .c, it should be compilable by a C compiler and it should not use any C++ extensions or functions.

Currently it depends on the glib for some data structures and also some types.

[2] Another approach was to keep the GArray and GList interfaces and reimple
ment them with malloc() and free(), forgoing the allocation (speed) optimizations in the glib implementation. Another downside here is the introduction of new bugs with the new code.
What you can do is to encapsulate a List and Array structure in new types, implement
them via GLib (most preferable via C macros). Then you can also provide an additional
implementation of these structures via C++ stuff.

What I do not understand: Why can't you just use the glib?


Both of these approaches work for me just fine, but I was wondering if you'd accept either?

Obviously, whatever kind of wrapper I implement, I'd enjoy the work a lot more if it was included with the official sctplib, because then other people would benefit as well, plus I'd safe myself from patching new releases of sctplib over and over again.
(Alternatively, has somebody else done this before on Windows with a compiler newer than VC++ 6??)
I think Irene did... Irene?


So... give some advice please! What are my options for writing a patch that gets both rid of glib *and* has a change of being integrated *and* meets the demands wrt. speed and stability?
Is the way above (use C macros and provide definitions using the glib and C++ stuff) is doable?


Many thanks and best regards,
Carsten



--
Ca3D - Engine http://www.Ca3D-Engine.de
Carsten Fuchs http://www.Ca3D-Engine.de/c_Carsten.php
_______________________________________________
sctp-discussion mailing list
sctp-discussion AT sctp.de
http://www.sctp.de/mailman/listinfo/sctp-discussion




Archive powered by MHonArc 2.6.19+.

Top of page