Subject: std C++ [was: [Patch] Psiconv TextEd and Word importer]
From: Mike Nordell (tamlin@algonet.se)
Date: Wed Dec 20 2000 - 09:00:59 CST
Thomas Fletcher wrote:
> Yes well we might have some fat trimming to do first. Our footprint
> (both runtime and exectable size) are a little on the big size ...
Which is why I have been thinking... We have almost a half megabyte of data
from one of our libraries. Would it be feasible to use gzip to compress that
data before linking it (or, which I'd prefer, lzo - since it's *way* faster,
*really* small and also GPL)? It would introduce one additional
"pre-processing" step, but since we already got one pre-processing step to
generate the images...
> Adding in things like STL and additional libraries (ie this psion
> library) doesn't help either.
Oh, STL (which is no more, it's called something like "the ISO standard C++
library", telling it's a part of C++. C++ without it would be a bit like C
without strcpy).
I still think you're wrong. Compare our current code with the code that
would be created using std C++ (on any of our current compilers, not any
imaginative compiler), I think the C++ library one would be smaller. But
this is currently purely hypothetical since we're not to use neither
standard C++ library nor templates, right? ;-)
Looking at our vector implementation. Pros:
- It's not typesafe, you can store anythin in a void*.
- It's three times slowe than at least my std::vector (though without your
fixes it would be more like 3000 times slower).
- It's used and abused throughout our code. Changing that to use _the C++
language declared data type_ would be extra work.
It's interface is *completely* incomatible with std C++ containers.
...
Cons:
??? It works on platforms that don't have C++???
(sorry about the irony, but I hope you all get my point)
> Has anyone given any thought to us using the Netscape Portable Runtime
> thingy so that we could make our importers/exporters work as plugins
> rather than having them bound directly into the executable.
Hell no! If we are to use a plugin architecture, we're to do it *right*
(IMHO). Else, we migh as well use a current C++ VM (like the Internet C++
"machine"). Nope, this is one this we should fix ourselves, right (IMHO of
course).
> Never having
> written an importer or an exporter (though I'm tempted to look at a
> writing a WordPerfect one) how solid is our API and what are other
> people's thoughts on this?
I can't comment on the solitity of it, but I can comment on its quality. But
I won't.
No offence, but much of our stuff seems is ad-hoc solutions, and AFAIK not
much have really been designed. I might be wrong, why I give you the
opportunity to kick me in the balls right now, but most of our interfaces
suck bugtime (no, not bigtime - bugtime).
/Mike - cc if you feel the need
Yes, I am a bastard, but I do deliver... What do you do...
This archive was generated by hypermail 2b25 : Wed Dec 20 2000 - 08:59:16 CST