Re: Umlaute und andere Sonderzeichen in Dateinamen konvertieren?

On Fri, Mar 21, 2014 at 09:39:31AM +1100, Peter Ross wrote:
> On Thu, 20 Mar 2014, Bernd Walter wrote:
>
> >Auf Steuerungssystemen mit wenigen kB-RAM oder NV-Seicher sieht
> >man sowas gar nicht gerne.
>
> Du arbeitest ja mit embedded-Systemen (ich nicht).

Ah gut.
Dann bist du einer der Glücklichen, die keine Chipkarten in der Geldbörse
haben...
Kein (Festnetz-)Telefon mit Kontaktliste...
Und du hast auch keine Server mit Managementprozessor im Einsatz.
Die billigen HD44780 Displays mit ihren wenigen festen Zeichen sind
auch noch lange nicht tot, aber wer hat in einem Gerät mit Displaybedienung
schon den Speicherplatz für alle möglichen Zeichen.

Vielfach ist es natürlich Absurd.
USB z.B.
Es gibt da diese nervenden 16-bit Vendor-IDs, obwohl man den Hersteller
(und sämtliche anderen Produktstrings) durchaus als UTF-16 liefern kann.
Da wird auf der einen Seite geknausert, indem man den Hersteller nicht
mal mehr als ASCII liefern kann und auf der anderen Seite dann das volle
Programm.

> Ich frage mich nur, wie relevant das noch ist, wenn es um neue Hardware
> gibt. Es ist doch im allgemeinen schwieriger, einen 256kByte-RAM zu
> kriegen als einen 4GB-Riegel..

Mag sein.
Für denjenigen der das baut aber nicht, wobei 256kByte SRAM schon sehr
viel ist.
Außerdem verträgt sich DRAM nicht so gut mit wenig Strombedarf wie SRAM.
Bei Geräten die per Batterie einige Monate laufen sollen durchaus ein
Thema.
Abgesehen davon sind ja ein paar Byte SRAM in den Prozessoren schon drin,
die man nicht extra kaufen muss und die kein extra Platz im Gerät benötigen.
Aber vergiss mal RAM - du willst vielfach Daten so speichern, dass die
ohne Strom beibehalten werden.
Da gibt es grundsätzlich Speicherchips die Byteweise schreiben können
und welche die Blockweise schreiben können.
Manchmal sagt der Bedarf, dass es Byteweise sein muss und dann kosten
große Chips deutlich mehr Geld.
Auch das schreiben ist nicht immer schnell, da will man nicht immer
neben den Daten auch noch einen Index schreiben, der ohnehin nicht
zeitgleich mit den Daten geschrieben werden kann und daher ein neues
Problem liefert, was zwar lösbar ist aber halt auch nicht einfacher
macht.

> >Die 3123. Zeile ereicht man halt einfacher mit 3123*Feldgrößen als
> >einen Index mit zu schleppen, oder gar immer alles abzugrasen.
>
> Ja, und ich habe das kürzlich hier erlebt (COBOL-Applikation unter
> Windows)
>
> Nachteilig: kein ordentliches Transaktionskonzept, keine garantierte
> Konsistenz, Abprüfen auf Fremdschlüssel muß manuell erfolgen, wenn die
> Tabelle voll ist, wird der Index halt neu vergeben (Quittung 3000.. die
> von 2012 oder 2010?), dann das Mehrfachbelegen von Teilen der Records
> (C-Union-Stil)

Ja, auf ausgewachsener Hardware will das keiner, weil der Performance-
nachteil nicht so schwer wiegt und RAM nicht mehr so teuer ist.
Aber es gibt halt immer noch die alte Hardwareklasse mit 8-bit und wenigen
kByte RAM, die ist nur kleiner geworden, braucht weniger Strom und füllt
neue Anwendungsbereiche aus, wo aber auch Strings verarbeitet werden müssen.
Man mag das jetzt als OT sehen und das ist es auch, aber in einzelnen
Bereichen wird halt noch so gearbeitet und dann schwappt das schon mal wieder
rüber.
Ich sehe das aber nicht als Grund an generel auf Umlaute zu verzichten.
Man muss halt jeweilig passende Kompromisse finden.

> Es ist ja schön, daß es sowas gibt.. aber es ist halt auch einfach, auf
> solcher Basis "Mist" zu programmieren..
>
> Damit will man sich als Programmierer nicht wirklich beschäftigen.
>
> >Wie viel Speicher muss ich allokieren, um 10-Zeichen zu speichern?
>
> Bei der Eingabe muß jemand zählen, von meinen xEvents auf dem Keyboard
> hier z.B. angefangen.
>
> Wenn danach der String als Struktur vorliegt, (erstes Byte die
> Stringlänge), dann weißt Du, wieviel Platz Du brauchst.

Nöh weiß ich nicht.
Beispiel ein String.
Ich will die ersten 10 Zeichen rauskopieren und muss Speicher für die
Kopie besorgen.
Jetzt fange ich erst mal an die CPU damit zu beschäftigen die Bytes der
Quelle zu zählen, dann Speicher zu besorgen und anschließend zu kopieren.
Wenn ich das vorher weiß kann ich den ersten Schritt auslassen.
Ok - wenn ich einen C-String komplett kopieren will muss ich das auch
vorher zählen, aber wenn es kritisch ist muss ich ja keine C-Strings
nehmen.

-- 
B.Walter <bernd@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message