On 13 Jan 2000 16:58:30 +0100, Lars Gullik Bj°nnes wrote:
>Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>
>|
>| If we want to have CC compile lyx easily, we have to settle the
>| question of adding 'usingstd::foo' where foo is a C library function.
>| The problem is that cxx does not like that. On esolution is to have
>| the headers in cheader/ declare everything in std::. I'll try to have
>| a look.
>
>The problem is not C library functions, but "UNIX" functions declared
>in C headers. (IMHO a mistake, but now we have to cary the inheritance
>garbage.)
Hi,
I've been thinking for quite a time now about system-dependent
low-level stuff and found it always annoying that non ANSI function
calls are spread around nearly everywhere in the sources. A while ago
I've been advocating to isolate that stuff and to put it into a
separate library. Rethinking this, I would even propose:
Put all low-level stuff into a separate opaque C library !
here some, well, improper ideas about low-level system dependency (1)
and usability (1). Both are absolutely unrelated (or somehow related?).
1) Use external C functions for low-level system dependencies
(I'm probably going to rethink this and will try to rewrite some emx
stuff, if you agree with the idea.)
As far as file attributes/modes, file attributes, file name conventions
and encodings, process environment strings and encodings (ASCII,
Unicode, DBCS encodings, Win*blurb codepages, EBDIC or whatever) and
similar low-level file system or operating system dependencies - like
contradicting shell syntax - are involved:
Make (file/OS/etc.) system internals opaque, for this purpose use
external C functions, and call them in thin C++ wrappers for a uniform
interface. Don't try to handle everything in C++.
C++ is not designed to handle every low-level problem in an efficient
way and if we mix low level C library system calls, C++ standard
string, etc., this leads to excessive complexity:
E.g. cf. Linux man page for one simple low-level function (stat()):
"Note that st_blocks may not be in terms of blocks
of size st_blocksize and st_blocksize may instead pro-
vide a notion of the "preferred" blocksize for efficient
file system I/O. [...] Not all of the Linux filesystems
implement all of the time fields." etc., etc.
2) ISO/EC software ergonomy standards
Recently the European Union adopted ISO ergonomy standards (ISO 9142 or
so) as part of the common market regulation. Most countries have
released their national decree on this subject. Now it is fined to urge
employees (in business and science) to use software that is potentially
injurious to health. Injurious is software that is not adopted to
recent standards of usability/ergonomy, as set forth by modern findings
in industrial medicine and psychology.
Now, M$ always refused to undergo certification procedures in this
field, but a PC magazine paid the Euro 50.000,- for certification by
TÜV IT Certification Institute. Radio today interviewed the project
coordinator, who said what you might already know: M$ Office 2000
failed; from the point of view of the Institute, it is illegal to use
this software in professional contexts.
Why don't we - as a kind of publicity gag and to attract more users and
developers - prepare some blurb/project in this field and claim
compliance? (The KDE project always had those ergonomy aspect in mind,
when designing their GUI standards.) For every professional GUI
designer/developer ergonomical aspects are a must, as the focus slowly
shifts from functionality/theoretical power to usability.
Greets,
Arnd
