[Libssh] Enhancements proposals

[Aris Adamantiadis]

Hello,

Rodolphe Rocca a écrit :
> 
> Ok I did not see those function pointers.
> 
I made a small exemple of what would look like the typical 
Cat/dog/animal exemple in object C. ( http://0xbadc0de.be/c_object.tgz ).
I find it awful. One of the reasons i hate it is because it took me 
almost an hour to develop (agreed, once I've learned it it's easier) and 
to debug (oh, I missed a copy there, ...)
It has lots of almost same functions (but not exactly the same), cut and 
paste inheritance (i'd say add-and-forget-to-cut-and-paste) and no 
implicit type-safe Cast (I can't implicitely convert a Cat to an Animal).
I'll look at what can be done with some macros.

> 
> Yes, if you compile with g++. Are you sure a native C library (compiled 
> with gcc) will be able to link to such object file containing C++ data 
> structures ? I'm quite perplex.
pretty sure, there's no reason it couldn't be done. extern "C" was done 
for this purpose.
But at linking time, on some architectures you'd have to add the C++ 
librairies (on linux, you can link a library to the .so file so the 
linker already knows the dependances)

> 
>>> And even if it's possible, you'll still have to design your C API...
>> that's right. It will follow the external C++ api. But it's much less 
>> hasle than having to design the whole code with these tricks.
>>> Notice that I don't have any personal interest in keeping C for libssh : 
>>> my application is written in C++. However I'm seriously thinking about 
>>> the wide amount of applications written in C that could not use libssh.
>>>
>> or the applications that won't want to use libssh because it's C++ and 
>> c++ is the root of all evil. Bad for them.
> 
> It's not my case :-)
> 
good. A lot of C users have prejudges on C++ : it is slow and bloated. 
The same people who have dual core 2gb systems who complains C++ has a 
large footprint...
The same people who will be whining if I link to Glib to have OO support 
in C.
It's 2008 now. The only reason to develop new projects in C today is 
backward compatability and special environments. The "nobody does that" 
is a logical fallacy - this reasonment is an "ad populi" fallacy + the 
fact that if no protocol library is in C++, it's because they were 
almost all developped at a moment there were good reasons not to do them 
in C++.
> 
> So you're telling them to use a deprecated unmaintained version... maybe 
> some will stick to a version they're already using, but I doubt any 
> company would get interested in starting with an already unmaintained 
> library.
I didn't say it would be unmaintained. I'd make the 0.2 rocksolid but 
with almost no new features. Embedded people will stick with it.
When they respect the licence ... (the LGPL requires user to be able to 
replace themselves the LGPL code with another.)

Regards,
Aris