comparison between portability libraries?

>
>> I see your points.
but it shows exaclty the "problem". So there is not comparision
because people prefer to invent that stuff on their own.

I agree that you can implement the "common datastructures" and we all
have, but I don't think that is a "wise" decision.

I completely disagree with points about e.g the OpenSSL library. I'm
pretty sure that the self-baked software has much large potential of
beeing wrong.

I can follow the argument about the dependencies of libraries. I guess
the negative "example" is the gtk+ stuff, however I have run glib here
on Linux and Windows and it "simply" has worked as has libapr.

Now the argument about compilation problems is quite meager, how much
time does it take to try out? How much time does it take to implement
something like libpar, or glib on your own. Not just writing it but
also having documentation which deserves it's name?

But it does not help. We disagree about usefullness of the
library. You think you can better I think I can't or if I would I do
not want.

But you answers show also you do not have had a look, and it shows
that you do not have used it. Which leads me back to the original
question, wouldn't it be very helpful to find it's use documented and
wouldn't it be interesting to see those libraries compared?



Regards
Friedrich

--
Please remove just-for-news- to reply via e-mail.

"Friedrich Dominicus" <just-for-news-frido@q-software-solutions.de> wrote in
message news:87u09cqhij.fsf@flarge.here...
> >
>>> I see your points.
> but it shows exaclty the "problem". So there is not comparision
> because people prefer to invent that stuff on their own.
>
dunno.

personally I define "portability library" as "library wrapping part of the
os", eg, SDL, GTK, to a lesser extent OpenGL, ...

"library doing utility stuff" (basically, the originally listed examples)
doesn't get so much respect, as it doesn't really solve anything portability
related, rather it just creates more dependencies for often dubious
benefeit.

if I can link to a single library and be able to suddenly forget about, say,
the mass of the win32 api on windows, and all the X related stuff on linux,
and not need to modify my code when porting, that is justified. misc
non-essential stuff is less so.


> I agree that you can implement the "common datastructures" and we all
> have, but I don't think that is a "wise" decision.
>
most common algos are easy enough to not be worth the bother.

for example, a simple (partial) string merging hash:
char *strhashdup(char *s)
{
static char *hash[4096];
static int init=0;
char *t;
int i;

if(!init)
{
memset(hash, 0, 4096*sizeof(char *));
init=1;
}
t=s; i=0;
while(*t)i=(i>>12)^(i<<4)^(*t++);
i&=0xFFF;

if(hash[i] && !strcmp(hash[i], s))
return(hash[i]);
hash[i]=strdup(s);
return(hash[i]);
}

could be a little shorter, but I wouldn't feel using a lib for something
like this to be justified. now one can argue: "but it doesn't guerantee that
strings are merged", but it does not need to, it is a little faster to not
bother with this (a premade hash function likely wouldn't give you this
option).

now, did this preexist? no. I wrote it right here (and will presume it
probably works, but I am not going to test it).

> I completely disagree with points about e.g the OpenSSL library. I'm
> pretty sure that the self-baked software has much large potential of
> beeing wrong.
>

possibly, but it depends on what one aims for, and how well they test their
code (I tend to write and test fragile code more carefully than I do more
mundane code, for example).


I would argue that part of my motive is doing things myself, for I can feel
that I have done it myself...

> I can follow the argument about the dependencies of libraries. I guess
> the negative "example" is the gtk+ stuff, however I have run glib here
> on Linux and Windows and it "simply" has worked as has libapr.
>
I haven't used either.

my main complaint is yeah, more about dependencies on more major libs, eg:
libqt;
libgnome;
libkde-whatever;
....


it is like, recently, I half considered using ogg/vorbis (vs doing my own
codec, or continuing use of mp3). didn't feel like writing a decoder, so I
figured I would try to build these.

problem: they don't build, either under cygwin or mingw.
oh well, wont mess with them then...

did my own codec, works well enough (it is a low bitrate low quality codec,
but this is what I was aiming for anyways...).

the work needed for this was minor, far more time was spent debating whether
or not I should do it than on implementing it.


then of course, I also went and did my own physics lib, and never did get it
as good as ode...
then again, it is my code, so I can at least take pride in that, and take
responsibility for the addition or absense of features...


> Now the argument about compilation problems is quite meager, how much
> time does it take to try out? How much time does it take to implement
> something like libpar, or glib on your own. Not just writing it but
> also having documentation which deserves it's name?
>
depends. again, most of my code has also been a side effect of other
efforts. never really thought much of writing it, for writing most code is
pretty cheap in my experience.

often it is written piecemeil, and shuffled around some until it eventually
ends up in a more or less final form, or is coalesced into one of my own
libraries.

documentation is a pita side task. I guess if you want people to use your
code you can document it, but sometimes it is difficult to muster that much
concern...


> But it does not help. We disagree about usefullness of the
> library. You think you can better I think I can't or if I would I do
> not want.
>
> But you answers show also you do not have had a look, and it shows
> that you do not have used it. Which leads me back to the original
> question, wouldn't it be very helpful to find it's use documented and
> wouldn't it be interesting to see those libraries compared?
>
dunno.

yeah, I have not used them, and looking at them, I don't personally feel a
need either.


plain ansi gives nearly all that is needed for most simiplistic apps. in
suit is posix, where one's apps can still be portable enough (posix is the
next layer, only to be used if ansi can't do something).

going outside this imo needs to be considered carefuly, each new feature can
generate a dependency, another little thing to worry about.

in these cases, if one wants, they can write their whole app as a bunch of
source files included from a single file, escaping needing a makefile, or
any real commandline options (this style is imo useful mostly for smaller
tools though, as it imo doesn't scale all that well...).

being able to just type, eg:
gcc -o foo foo.c

is preferable, eg, to command line tools requiring configure scripts and
blowing up because some random library is missing or because the script
tries to use some non-existant program (eg: pkgconfig, gnome-config, ...).

>
>
> Regards
> Friedrich
>
> --
> Please remove just-for-news- to reply via e-mail.

On 2006-04-02, Friedrich Dominicus <just-for-news-frido@q-software-solutions.de> wrote:
>>
>>> I see your points.
> but it shows exaclty the "problem". So there is not comparision
> because people prefer to invent that stuff on their own.
>
> I agree that you can implement the "common datastructures" and we all
> have, but I don't think that is a "wise" decision.

Well actually, I think that glib is the least generic one of the list, since
it is the most language specific. Datastructures can benefit tremendously
from language constructs as generics, classes etc.

Together with curl, it would be the last one I'd use. (except for GTK
related interfacing, but I would use GTK only on *nix).

> I can follow the argument about the dependencies of libraries. I guess
> the negative "example" is the gtk+ stuff, however I have run glib here
> on Linux and Windows and it "simply" has worked as has libapr.

Little question (a bit apart from this thread), how do you find libapr
useful on non-*nix ? (read: Windows)

Things like deployment size, deploymnet complexity, added complexity of the
buildprocess, versionitis etc, native feel of the result etc.

"Marco van de Voort" <marcov@stack.nl> wrote in message
news:slrne2vscb.abp.marcov@snail.stack.nl...
> On 2006-04-02, Friedrich Dominicus
> <just-for-news-frido@q-software-solutions.de> wrote:
>>>
>>>> I see your points.
>> but it shows exaclty the "problem". So there is not comparision
>> because people prefer to invent that stuff on their own.
>>
>> I agree that you can implement the "common datastructures" and we all
>> have, but I don't think that is a "wise" decision.
>
> Well actually, I think that glib is the least generic one of the list,
> since
> it is the most language specific. Datastructures can benefit tremendously
> from language constructs as generics, classes etc.
>
yeah. also, even in c, most of the stuff is pretty generic.

for example, a custom memory manager:
I have this, and it also supports object types and garbage collection
(conservative).

the only real problem it how unsafe it is to mix data between different
memory managers (especially ones with garbage collection), as there is no
guerantee that the memory manager will see the memory correctly (for garbage
collection, it wont trace through unknown objects, causing parts of the heap
to potentially fall off). in the manual case, it is a risk that the data
will be allocated with the wrong allocator, and things may mess up or crash
later when something tries to free the memory with a different allocator.


> Together with curl, it would be the last one I'd use. (except for GTK
> related interfacing, but I would use GTK only on *nix).
>
yeah.

if gtk were better cross-platform, that would be cool.

instead I have usually ended up with the fallback of just using opengl for
everything, and doing my ui's in gl (never really implementing/maintaining a
"proper" gui toolkit though, more often the ui's are ad-hoc globs of code).

partly it is I am lazy, and have a hard time going that much beyond the
level I am willing to tolerate.

one of the bigger problems here is one of api interface, eg:
is it callback driven (ok for plain c, horrid for much else)?
is it event driven (vaguely awkward in c and most else)?
is it "oo" (like callbacks, somewhat limiting language options)?
....

another is one of representation, eg:
are interfaces created dyamically via function calls?
are interfaces created statically via file-loading or similar?
....


my thought right now is that quite possibly an event driven system based on
a restricted form of dynamic construction makes the most sense.

eg:
int hfrm;

//indented for obviousness
UI_BeginForm(UI_DLG, "tst0");
UI_BeginWidget(UI_VBOX, NULL);

UI_BeginWidget(UI_BUTTON, "foo");
UI_WidgetPropertyS("title", "_Foo");
UI_EndWidget();

UI_BeginWidget(UI_BUTTON, "bar");
UI_WidgetPropertyS("title", "_Bar");
UI_EndWidget();

UI_BeginWidget(UI_LABEL, "baz");
UI_WidgetPropertyS("text", "");
UI_EndWidget();

UI_EndWidget();
hfrm=UI_EndForm();


with an event loop:
while(UI_HasEvent(hfrm))
{
i=UI_GetEventType(hfrm);
s=UI_GetEventWidget(hfrm);
switch(i)
{
case UI_BUTTON:
t=kprints("%s was pressed", s);
UI_SetWidgetPropertyS(hfrm, "baz", "text", t);
break;
default:
break;
}
UI_NextEvent(hfrm);
}


actually, this style of api design has been used by me a lot recently...


>> I can follow the argument about the dependencies of libraries. I guess
>> the negative "example" is the gtk+ stuff, however I have run glib here
>> on Linux and Windows and it "simply" has worked as has libapr.
>
> Little question (a bit apart from this thread), how do you find libapr
> useful on non-*nix ? (read: Windows)
>
> Things like deployment size, deploymnet complexity, added complexity of
> the
> buildprocess, versionitis etc, native feel of the result etc.
>
yeah.

next thought:
using non-standard libs on windows, especially as dll's, leads to potential
dll hassles, eg, the app may use one version of the library, but some other
app has used another version, and they conflict, likewise, one has to send
all the needed dll's with the app (often rarely done correctly, as there is
often some dll or another that they forgot to include). one almost needs to
have a "clean" windows install set up to test with (being clean, if the
dll's are not around, then they are more likely to be pointed out).

if one only uses system-provided libraries, and more or less statically
links everything else, then there is not really a problem with this.

....

In article <87sloxeha6.fsf@flarge.here>, Friedrich Dominicus wrote:
> well what's your opinion about diverse offers then?
> - libapr > - libcurl > - libxml2 > - libpcre > - glut
> - glib > - libssl (eay) > - other you name them
>
> That's the point I checked out quite few libraries and liked quite a
> few and dislike a few other, however that really is problematic is
> finding which shows how to use them.

Still following the topic.

Keep in mind that with a individual writing their own portability
libraries; their library will work the way they need and will most
probably be less than useful for a team to use. They will be able to
rework the library to extend it to cover deficiencies and fix bugs
(assuming they still remember how their own code works years later).

With a team using a 'standard' or widely available library offers an
easy entry (jump start) to get the first version running. As long as
the library is available on all the target platforms using a
pre-existing library offers less risk. You can usually find someone
who will fix bugs in the 'public' libraries - even if you have to pay
them to do it. The code may not be 'fast' or 'tight' or any other
desirable attribute for a self respecting individual coder, but for a
team it's someone else's code, their is less risk and they have less
invested in the result.

When a team finds the library unacceptable down the line, then the
choice may be made to re-write a section or to obtain the source code
and fix it.

cr#### is an example of someone who's frustration at learning to use
unfamiliar libraries, using unfamiliar code tools, outweighs the cost
of writing his own, a major case of NIH. Note: I'm not saying his
choice is invalid, only that his criteria is very different from those
of a team building commercial products. I write enough of my own code
and will also use his approach when working by myself.

--
Andrew Nicholson <andrewn@lesto.com> http://lesto.com/andrewn/
When all you have is a nail-gun, every problem looks like a messiah?