Mein Problem mit den Umlauten

Mahlzeit!

Ich hoffe das ist okay wenn ich die Frage hier stelle, hat sie doch nicht soo viel mit Ki oder so zu tun.

Ich versuche aus einem Wort die Umlaute zu ersetzen. Bislang habe ich zum Ersetzen von Buchstaben in einem char String immer folgendes gemacht:

Code:

---

.
.
.
for(i=0;i<wortlang;i++)
{
    if(wort[i] == 'ä') wort[i] = 'a';
.
.
}
.
.
.

---

Doch mache ich das bekomme ich eine solche Meldung:

Code:

---


Warnung: multi-character character constant [-Wmultichar]

---

Schockiert mich irgendwie. Funktioniert das mit den Umlauten nicht oder wie?

Hallo,

Zitat:

---

Zitat von hirnfrei

Schockiert mich irgendwie. Funktioniert das mit den Umlauten nicht oder wie?

---

Und gleich noch der nächste Schock:
Es gibt gar keine Buchstaben, nur Zahlen!

Eine CPU weiss rein gar nichts über Buchstaben!
Wir haben verschiedene Codes Entwickelt und die Buchstaben durchnummeriert.
Für dein Problem musst du dir des ASCII-Code und den Unicode ansehen.
Die Zuordnung für die Zahlen 0...127 ist dabei noch identisch, aber darüber wird es dann sehr unterschiedlich.
Da ASCII von den Amis stammt, hatten diese keinen Bedarf für Sonderzeichen.
Die Europäer haben dann einige, im Schriftverkehr wenig benutze, Zeichen mit den Umlauten belegt. Das waren z.B. "[" und "]". Listings sahen dann etwas komisch aus, vor allem auf dem Drucker.
Man hat dann die 7-Bit auf 8-Bit erweitert, da gibt es aber für die zweiten 128 Zeichen unterschiedliche Varianten, bekannt als Codepages.

Normalerweise arbeiten Tastatur und Monitor eines PCs mit dem selben Zeichensatz, da scheint dann auf dem Monitor alles normal.
Wenn dann der Drucker mit einem anderen Zeichensatz arbeitet, was früher oft der Fall war, kommt auf Papier was anderes raus.

PC arbeiten heute meistens mit Unicode, da werden Sonderzeichen intern mit 2 Bytes dargestellt und dein Editor legt dies auch so in der Datei ab.

Dein Compiler erwartet nun aber einen 8-Bit ASCII-Code und da passen die zwei Bytes nicht rein.

Du musst also entweder deinen Editor so einstellen, dass er nur ASCII-Code erzeugt oder deinen Compiler so einstellen, dass er Zeichen aus mehreren Bytes verarbeiten kann. Letzteres hat dann aber Einfluss auf die Bibliotheken und wenn du Textnachrichten wieder nach aussen sendest (Display, Schnittstelle).

MfG Peter(TOO)

Also doch keine so lahme Sache wie ich gedacht habe. Wenigstens etwas ;).

Danke für die ausführliche Antwort!

Es kommt noch schlimmer.
ASCII Code - 1 Byte: 7 Bit je Zeichen (Erweitert: 8 Bit)
http://www.chip.de/ii/1/2/5/4/9/5/8/...e7009f26b0.png

ANSI Code - 1 Byte: 8 Bit je Zeichen
http://www.itwissen.info/bilder/zeic...ansi-codes.png

Undicode - 2 Byte je Zeichen
http://unicode-table.com/de/#control-character

Hallo,

Zitat:

---

Zitat von hirnfrei

Ich hoffe das ist okay wenn ich die Frage hier stelle, hat sie doch nicht soo viel mit Ki oder so zu tun.

---

was glaubst du denn, warum mein Beispiel zu den Threads eine englische Ausgabe hatte ? :cool:

Aber im Ernst, ich denke da beschwert sich der Compiler über die Codierung des Quelltextes. Abseits von Raspi und Beaglebone bin ich nicht so der Linux Programmierheld, ich kann da nicht sagen, wie deine Entwicklungsumgebung das handelt.

Wenn man mit internationalen Texten im Programm zu tun hat, sollte man eigentlich nicht mehr mit char arbeiten. Das Problem ist, dass man dann Portierbarkeit verliert. Unter Windows hat man es dann normalerweise bei wchar_t mit UTF-16 (meistens zwei Byte, wie oben gesagt, aber nicht immer) zu tun, unter Linux entweder mit UTF-8 (ein bis vier Byte) oder UTF-32 (immer vier).

http://unicode.org/faq/utf_bom.html

Also ich kann mich auf den Kopf stellen, ich bekomme kein äöü verglichen. Habe jetzt meine Funktion auch auf STRING umgestellt, hilft aber auch nicht. Auch locale hat nichts gebracht.

Lustig ist, wenn ich

Code:

---

printf("%d\n", 'ä');

---

verwende, dann bekomme ich in der Konsole

Code:

---

50084

---

zurück. Drehe ich den Spiess aber um mittels

Code:

---

printf("%c\n", 50084);

---

bekomme ich nur ein Symbol zurück.

Hätte ja nicht gedacht, dass drei so kleine Zeichen das Leben so schwer machen können. Zumal ich zu meinen Hochzeiten im Programmieren, das war auf dem Amiga mit StormC, damit nie Probleme hatte. Da hatte ich eine eigene Mailinglist aufgebaut, die auch nach Wörtern mit Sonderzeichen suchen konnte und das hat nie Probleme gemacht.

Zitat:

---

Zitat von hirnfrei

Code:

---

printf("%d\n", 'ä');

---

---

das gibt bei mir unter Windows -28. Das (signed) char ist größer als 127 und wird in einen int umgewandelt, klingt plausibel.

Erzähl mal mehr über Editor, OS und Compiler.

Das Problem gibt es auch im gewerblichen Bereich öfters.
Der Mainframe spricht ASCII, der Middleware Server ANSI und das Webfontend Unicode.
Grade wenn das dann von 3 Verschiedenen Anbietern kommt (von denen keiner über den eigenen Tellerrand schaut) macht die Integration besonders viel spaß.
Üblicherweise einigt man sich dann auf eine Codierung und schreibt für die anderen beiden je einen Parser, der eine Umcodierung vornimmt bevor man mit der Verarbeitung beginnt.

Wenn der Text aus Dateien eingelesen wird, efentuell mal in den Metadaten der Dateien checken ob dort das Codierungsformat angegeben ist.
Ansonsten über das Dateiformat (nicht nur die Dateierweiterung des Namens) selektieren.

Das ist eine Eingabe mit getchar(). Wird korrekt eingelesen und mit cout auch wieder korrekt ausgegeben.

OS: Gentoo Linux 64 Bit
IDE: Qt-Creator 3.4.2
Compiter; GCC 4.9.3 64 Bit

Ja, wie schon gesagt, schein mir nicht der Wert zur Laufzeit das Problem zu sein, sondern die Konstante 'ä' im Quelltext. Das scheint ja die "multi character constant" zu sein.

Da es ja C++ ist, was liefert denn

Code:

---

int main()
{
    auto c = 'ä';
    std::cout << sizeof(c) << " " << typeid(c).name() << std::endl;

    return 0;
}

---

bei dir ?

Wirklich "1 char" ?

Da bekomme ich

Code:

---

Fehler: 'c' does not name a type
  auto c = 'ä';
          ^

---

zurück...

Spannend.

Visual Studio 2015 hat ja zwei C++ Compiler. Wenn ich

Code:

---

auto c = 'ä';

---

mit Clang übersetze, produziert das 'ä' auch eine Warnung.

Zitat:

---

warning : illegal character encoding in character literal [-Winvalid-source-encoding]
auto c = '<E4>';

---

das ^ welches die Fehlerposition markiert, steht beim ersten '


Kombiniere, das 'ä' ist anscheinend nicht überall erlaubt und tut nicht was du meinst. Das muss ich auch mal weiter erforschen. Da ist mir was bisher entgangen.

- - - Aktualisiert - - -

=======

Ok,

die Meldung " 'c' does not name a type " kommt wohl eher daher, dass kein C++11 oder 14 eingeschaltet ist und hat somit nicht direkt mit dem Problem zu tun.

Ansonsten wollen g++ oder clang wohl lieber Unicode Quelltextdateien, wenn du da mit Umlauten in Literalen arbeiten willst. Ob einzelne oder doppelte Anführungszeichen macht wohl keinen Unterschied.

Dann nehm für deinen Vergleich halt das ä als Hexkonstante, so in der Art

Code:

---

const char c = 0xe4;

---

oder was immer der Code des Zeichens bei dir ist.

Ich bekomme

Code:

---

1 c

---

zurück

Das ist ok, der g++ ist bei typeid wohl nicht so ausführlich.

Aber dann ist c ein Byte groß und kann daher nicht 50000 sein, schau mal mit dem Debugger hinein.

Funktioniert es, wenn du das ä wie oben durch eine Konstante ersetzt ?

===

Nachtrag: Auf dem Raspi mit Raspian und vim als Editor ist die Ausgabe tatsächlich
4 i
das 'ä' wird dort also 4 Byte groß. Ein "file -bi dateiname" zeigt, dass die Datei als utf-8 gespeichert wird.

wenn ich mich nicht irre, liest die C-read (scan, getc oder C++ << -) Funktion von stdin nicht einen unsigned char sondern ein int16_t. Man liest ja aus einem FILE * stream und da wird auch grundsätzlich bei eof() eine -1 zurückgegeben (erinnere mich dunkel an so etwas), also kann es kein uchar sein. Die Codierung deutscher Umlaute und Sonderzeichen jenseits ASCII 127 ist dennoch ungewiss.

Ich habe jetzt auch noch in mehrere Bücher geschaut und außer "das ist implementierungsabhängig" nicht viel gefunden.

Meine Vermutung ist, bei

Code:

---

if(wort[i] == 'ä')

---

betrachtet der g++ die rechte Seite des Vergleichs als int, also wahrscheinlich einen etwas größeren Zahlenwert (228 ?). Wenn wort ein char Array ist, werden die Werte auf der linken Seite vor dem Vergleich nach int umgewandelt, da kommen dann nur Werte von -126 bis 127 raus, der Vergleich schlägt also immer fehl. (Da holt man sich auch noch wieder das Problem rein, dass auf ARM ein char vorzeichlos ist und auf Intel eines hat.)

Wenn ich meinen Raspi wieder mal auf Arch Linux umgesteckt habe, muss ich das mal mit einem aktuellen g++ 5.3.x vergleichen.

Wahrscheinlich ist man mit den Präfixvarianten für Stringkonstanten sicherer, also L"text", U"text" oder u"text", dann hat man aber immer Unicode in verschiedenen Varianten.

Sonst halt Zahlenkonstanten statt Zeichen, oder eben in Konsolenanwendungen immer englisch schreiben.

Hallo,

Zitat:

---

Zitat von Mxt

Ich habe jetzt auch noch in mehrere Bücher geschaut und außer "das ist implementierungsabhängig" nicht viel gefunden.

---

Deshalb gibt es auch Manual zum Compiler.
Da steht dann in einem Anhang wie das genau ist und welche Parameter was übersteuern.

Zitat:

---

Zitat von Mxt

Meine Vermutung ist, bei

Code:

---

if(wort[i] == 'ä')

---

betrachtet der g++ die rechte Seite des Vergleichs als int, also wahrscheinlich einen etwas größeren Zahlenwert (228 ?). Wenn wort ein char Array ist, werden die Werte auf der linken Seite vor dem Vergleich nach int umgewandelt, da kommen dann nur Werte von -126 bis 127 raus, der Vergleich schlägt also immer fehl. (Da holt man sich auch noch wieder das Problem rein, dass auf ARM ein char vorzeichlos ist und auf Intel eines hat.)

---

Da ist halt wieder die Frage, wie char implementiert ist.

Wenn man sicher gehen will, verwendet man char gar nicht!
Sondern explizit unsigned char und signed char.

Ich habe in meinen Programmen vor 30 Jahren ein typedef für uchar und schar verwendet, dann muss ich nicht so viel tippen und es funktioniert mit jedem Compiler. :-)
Mit ANSI-C wurden dann typen wie int8_t und uint8_t eingeführt, welche bei jeder Implementierung gleich sind, eingeführt.

Bibliotheken, welche mit unterschiedlichen Text-Codierungen zurecht kommen, haben meistens eigenen Datentypen, welche an Stelle von char verwendet werden sollten.

Ich habe viel Code geschrieben, welcher meistens auf PC und µC laufen musste (Vor allen Übertragungsprotokolle). Da kommt dann noch das Problem von Little und Big Endian hinzu. Aber wenn man ein paar Dinge berücksichtigt, geht das ganz gut und auch ganz ohne den Code doppelt zu schreiben und mit #if nur Teile zu Compilieren.


MfG Peter(TOO)

Zitat:

---

.. Deshalb gibt es auch Manual zum Compiler .. Wenn man sicher gehen will . . Sondern explizit unsigned char und signed char.
Ich habe in meinen Programmen vor 30 Jahren ein typedef für uchar und schar verwendet, dann muss ich nicht so viel tippen und es funktioniert mit jedem Compiler..

---

Peter, bitte gib dazu ein Beispiel. Denn ich bin a) reichlich unwissend und b) stehen solche fortgeschrittenen Beispiel ja leider (soweit ich es bisher sah) nicht im Manual. Und bisher stehen in meinem Definitions-Faulenzer (mydefs.h) nur Dinge wie
......typedef uint16_t u16; //typedef unsigned short u16;
und so

Danke im Voraus.

Zitat:

---

Zitat von oberallgeier

Peter, bitte gib dazu ein Beispiel.

---

Ja, insbesondere zur Verwendung von Eingabefunktionen wie getch usw., da ist man ja auf deren Rückgabewert und dessen Typ angewiesen, wie HaWe richtig angemerkt hat.

Außerdem dürfte es in der g++ Doku nicht so einfach nachzulesen sein, warum der bei dem auto Testbeispiel oben, wenn er also template type deduction verwendet, beim Fragesteller sagt das 'ä' sei 1 Byte groß, in dem if dagegen die "multi byte constant" dann implizit als int betrachtet. Ich bin noch dabei zu erforschen, ob sich da verschiedene g++ unterschiedlich verhalten, und ob es Unterschiede zu clang++ gibt.

- - - Aktualisiert - - -

==

So, Neuigkeiten.

Auf dem Raspi mit Arch mit g++ 5.3.0 das gleiche Bild wie mit Raspian.

Aber mit dem clang 3.7.1 und -std=c++14 wird ein 'ä' gar nicht mehr übersetzt. Das gibt jetzt ein

Zitat:

---

error: character too large for enclosing character literal type

---

Es geht nur
L'ä' (Ausgabe "4 w" im obigen Testprogramm)
U'ä' (Ausgabe "4 Di")
u'ä' (Ausgabe "4 Ds")

Hallo,

Zitat:

---

Zitat von Mxt

Auf dem Raspi mit Arch mit g++ 5.3.0 das gleiche Bild wie mit Raspian.

Aber mit dem clang 3.7.1 und -std=c++14 wird ein 'ä' gar nicht mehr übersetzt. Das gibt jetzt ein


Es geht nur
L'ä' (Ausgabe "4 w" im obigen Testprogramm)
U'ä' (Ausgabe "4 Di")
u'ä' (Ausgabe "4 Ds")

---

Die Frage ist jetzt was es werden soll?

Eine Lösung ist, dass du einen Text-Editor nimmst, der reinen ASCII-Text erzeugt, bzw. deinen entsprechend einstellst (Kann schon am gewählten Zeichensatz liegen).

Du erzeugst mit dem Editor ein Textfile welches den Vorgaben des Betriebssystems folgt.
Nun hat aber dieses Betriebssystem oft gar nichts mit dem zu tun, was auf deinem µC vorhanden ist.
Die Motzerei des Compilers bezieht sich auf die Textdatei, welchem ihm gefüttert wird.

Die andere Möglichkeit ist, den Compiler so einzustellen, dass er mit Mehrbyte-Zeichen zurecht kommt, dann muss dies aber auch von der Laufzeitumgebung des µC unterstützt werden.

MfG Peter(TOO)

- - - Aktualisiert - - -

Hallo Geier,

Zitat:

---

Zitat von oberallgeier

Peter, bitte gib dazu ein Beispiel. Denn ich bin a) reichlich unwissend und b) stehen solche fortgeschrittenen Beispiel ja leider (soweit ich es bisher sah) nicht im Manual. Und bisher stehen in meinem Definitions-Faulenzer (mydefs.h) nur Dinge wie
......typedef uint16_t u16; //typedef unsigned short u16;
und so.

---

Was für Beispiele willst du jetzt?

Bei mir stand da halt
typedef unsigned char uchar
Meinen Faulenzer hatte ich mit GoeDef.h bezeichnet.

Ein typisches Problem für die Portierbarkeit:

Code:

---

typedef struct
  {
    unsigned char c
    unsigned int i;
  } s_foo;

---

Ich gehe mal davon aus, dass char 8-Bit und int 16-Bit haben.

Manche CPUs können 16-Bit-Zugriffe nur auf gerade Adressen machen, weshalb der Compiler zwischen c und i noch ein Füllbyte einfügen muss. Kann man beim Compiler unter Alignement beeinflussen. Manche CPUs können auch auf ungeraden Adressen 16-Bit Zugriffe machen, brauchen dann aber 2 Speicherzyklen. Hier kann dann die Optimierung auf Geschwindigkeit das Füllbyte erzwingen.

Und bei int weiss man nicht ob da zuerst das Low-Byte oder das Hight-Byte abgelegt wird. Bei 32-Bit gibt's dann schon 4 Möglichkeiten (Endian).

Code:

---

typedef struct
  {
    unsigned char c
    unsigned int i;
  } s_foo;

  s_foo var;
  fwrite(&s_var, sizeof(s_foo), 1, file):

---

Scheint jetzt sehr einfach, aber da weiss jetzt keiner was wirklich geschrieben wird.
Je nach Füllbyte sind es 3 oder 4 Byte und wie der int dargestellt wird, weiss man auch nicht.

Eine sauber Lösung ist:

Code:

---

typedef struct
  {
    unsigned char c
    unsigned int i;
  } s_foo;

  s_foo var;
  unigned char buf[3];
 
  buf[0] = var.c;
  buf[1] = (var.c >> 8) & 0xFF;
  buf[2] = (var.c    ) & 0xFF;

  fwrite(buf, sizeof(buf), 1, file):

---

Wolltest du so etwas?

MfG Peter(TOO)

Also um die Sache mal von meiner Seite aus abzuschliessen:

Ich stimme Peter darin zu, dass man für diese Aufgabe mit entsprechenden Bibliotheken besser bedient wäre. Da der Fragesteller mit QtCreator auf dem PC arbeitet, nicht mit einem Mikrocontroller, wären dazu die Datei- und Stringklassen von Qt sicher gut geeignet.

Die Unicode-Geschichte ist ein typisches Beispiel dafür, dass sich die Mikrocontrollerprogrammierung und die auf den "großen" Betriebssystemen schon etwas unterscheidet. "Einfaches C" kann auf den komplexen Systemen schnell in so einem Minenfeld landen, wie wir es in diesem Thread gesehen haben.

Was der Fragesteller nicht erwartet hatte, ist das für den gcc etwas in einfachen Anführungszeichen, abhängig vom Inhalt ein char oder int sein kann. Das wusste ich auch nicht. Die anderen C++ Compiler sehen das anders.

Zitat:

---

Ein typisches Problem für die Portierbarkeit:

Code:

---

typedef struct
  {
    unsigned char c
    unsigned int i;
  } s_foo;

---

Ich gehe mal davon aus, dass char 8-Bit und int 16-Bit haben.

---

schon wieder lese ich hier was über int und 16 bit und "einfach davon ausgehen".... tstststs...
das geht hier mit Sicherheit schnell schief!

auf dem Raspi hat int 32 bits , also int == int32_t
will man exakt 16 bit int, muss man short verwenden - oder eben int16_t.
auch word hat hier übrigens 32 bits.

und char ist auf ARM-Plattformen häufig unsigned char, während es auf AVR Plattformen häufig signed char ist!

Auch auf dem Arduino Due (ARM Cortex M3) gilt das automatisch !!

und werden aus einem FILE * stream (Datei als SD-File oder von stdin) Zeichen gelesen, sind es signed int, keine unsigned int, denn es gibt hier auch negative Werte, während der erweiterte ASCII-Zeichensatz (0...255) unsigned char ist !!


Mein Tipp:
vergesst doch einfach mal die alten Datentypen.

per gpp und Arduino sind die C11-Datentypen bereits implementiert,
bei gpp für Raspi muss man bei Raspbian per Hand includen:
#include <stdint.h>

dann weiss man, was man hat.


ps,
für Buchstaben gibt es bei Raspi C++ auch den Datentyp
wchar_t
mit 8-16 bit, der alle "chars" aufnimmt, seien es uint8_t oder int16_t.

Zitat:

---

Datentyp wchar_t
Der Datentyp char ist nicht in der Lage, die Zeichensätze aller nationaler Sprachen zu repräsentieren. Um zum Beispiel auch mit dem japanischen Zeichensatz umgehen zu können, ist dieser Datentyp "zu klein".

Die Darstellung beliebiger landesspezifischer Zeichensatze kann mit Hilfe des Datentyps wchar_t (wide characters) vorgenommen werden, der mit ANSI-C eingeführt wurde.
Die Definition des Datentyps erfolgt in der Header-Datei stddef.h.

wchar_t ist ebenso wie char, int, ... ein integraler Datentyp.

Literale vom Typ wchar_t besitzen folgende Gestalt

L'..'

http://www2.informatik.uni-halle.de/...c/c_wchar.html

---

s.a. http://www.raspberry-projects.com/pi...mory/variables

Zitat:

---

Zitat von HaWe

schon wieder lese ich hier was über int und 16 bit und "einfach davon ausgehen".... tstststs...

Mein Tipp:
vergesst doch einfach mal die alten Datentypen.

#include <stdint.h>

dann weiss man, was man hat.

---

+1


wchar_t ist der native Typ des Betriebssystems für wide characters. Unter Windows sind das 2 Byte, unter Linux 4, wie oben in den Ausgaben gezeigt. (Schreibweise L"...").

Dann gibt es in neuerem C++ noch char32_t, Schreibweise U"...", sollten eigentlich überall 4 Bytes sein.

Mit kleinem u"..." ist es eigentlich char16_t, wie wir oben gesehen haben unter Linux trotzdem 4 Bytes, unter Windows sind es 2.

char32_t und char16_t kannte ich jetzt noch nicht, sondern nur int32_t und int16_t .... oder war das ein "Verschreiber"?

http://en.cppreference.com/w/cpp/lan...haracter_types

Bei den Zahlentypen gibt es einen ganzen Zoo
http://en.cppreference.com/w/cpp/types/integer


Da steht übrigens was interessantes zu char

Zitat:

---

char - type for character representation which can be most efficiently processed on the target system (has the same representation and alignment as either signed char or unsigned char, but is always a distinct type).

---

oh ja! :-o

ich kannte allerdings nur diese Liste speziell für Raspi, kA ob diese ausschließlich ist oder ob die anderen ebenfalls schon mit drin sind:

http://www.raspberry-projects.com/pi...mory/variables

Zitat:

---

Zitat von Peter(TOO)

. . . Wolltest du so etwas? . . .

---

Peter, vielen Dank, genau das bringt mich weiter. Danke für die viele Mühe.

Hallo,

Zitat:

---

Zitat von HaWe

schon wieder lese ich hier was über int und 16 bit und "einfach davon ausgehen".... tstststs...
das geht hier mit Sicherheit schnell schief!

---

Manche hier haben verstanden, was ich geschrieben habe, andere haben den Satz aus den Zusammenhang gerissen!

Ich kenne auch noch CPUs bei denen char 9-Bit hat!
Bei K&R, stand schon in der ersten Ausgabe:
Garantiert ist nur, dass "char <= int <= Long" ist. char kann dabei aber auch 38-Bit haben.

MfG Peter(TOO)

- - - Aktualisiert - - -

@Geier,

Das war nur etwas Tipparbeit.

MfG Peter(TOO)

der TO arbeitet mit GCC und 64 bit Linux, da werden ints weder 16 noch 9 bit haben. Auch 32-bit ARM Prozessoren verwenden 32 bit int.
Es ging mir nur um die Tatsache, dass 16-bit int nichts ist, wovon man JEMALS EINFACH MAL ausgehen darf, allein diese Aussage ist völlig aus der Welt. Und w_char ist darüberhinaus bei ANSI C eh der eigentliche proprietäre Zeichen-Datentyp, wo es nicht verwunderlich ist, wenn ein in ' ' eingeschlossenen Zeichen nicht 8, sondern 16 bit groß ist, insbes. wenn man von stdin liest.
(Annodazumal ist eben annodazumal, das mag alles in leipzig-einundleipzig noch anders gewesen sein: wir arbeiten meist mit C99 oder sogar C11 und gcc/gpp auf ARM oder AVR hat da auch seine eigenen Konventionen.)

Hallo HaWe,

Zitat:

---

Zitat von HaWe

der TO arbeitet mit GCC und 64 bit Linux, da werden ints weder 16 noch 9 bit haben. Auch 32-bit ARM Prozessoren verwenden 32 bit int.
Es ging mir nur um die Tatsache, dass 16-bit int nichts ist, wovon man JEMALS EINFACH MAL ausgehen darf, allein diese Aussage ist völlig aus der Welt. Und w_char ist darüberhinaus bei ANSI C eh der eigentliche proprietäre Zeichen-Datentyp, wo es nicht verwunderlich ist, wenn ein in ' ' eingeschlossenen Zeichen nicht 8, sondern 16 bit groß ist, insbes. wenn man von stdin liest.
(Annodazumal ist eben annodazumal, das mag alles in leipzig-einundleipzig noch anders gewesen sein: wir arbeiten meist mit C99 oder sogar C11 und gcc/gpp auf ARM oder AVR hat da auch seine eigenen Konventionen.)

---

Du hast überhaupt nicht begriffen was ich geschrieben habe oder den Text gar nicht zu Ende gelesen!

Aber nochmals explizit für dich:

1. Bezog sich die Antwort auf die Frage des Oberallgeiers (Dies zu erkennen ist übrigens der Unterschied zwischen lesen können und Lesekompetenz).
2. Die Antwort bezog sich auf Probleme, welche sich beim Portieren von Code ergeben.
3. Um zu beschreiben was das Aligment macht, MUSS man nun mal irgendwelche Annahmen über die Bit-Grösse von Datentypen machen.

MfG Peter(TOO)

Ich denke, das ist mitterweile wirklich OT. Den Fragesteller hat man eh schon vertrieben.

Zitat:

---

Zitat von Peter(TOO)

3. Um zu beschreiben was das Aligment macht,

---

hätte es in C++ alignof, alignas, usw. gegeben, das war aber nicht das (eigentliche) Thema dieses Threads.

Ach was ihr habt mich doch nicht vertrieben ;). So leicht wird man mich nicht los :D.

Habe das bisher auch schon so grösstenteils verfolgt, aber ich denke, solange ich keinen Raspi habe, für welchen das Programm letzten Endes gedacht ist, macht das wohl weniger Sinn. Nutzt ja nichts wenn ich auf meinem Rechner eine Lösung gefunden habe, die dann auf dem Raspi nicht mehr läuft. Entwickle derzeit auch nur deshalb auf meinem Rechner, da ich eben noch kein Raspi habe.

Bin aber auf jeden Fall erstaunt, was diese drei Sonderzeichen einen Thread los getreten haben ;). Und ich bedenke mich auf jeden Fall für die rege Beteiligung.

nur ein kleiner Tipp noch von mir, falls du noch keinen Raspi hast:

kauf dir den neuen Raspi 2B quadcore. Der hat zwar nicht viel mehr cpu clock als der B+, aber bei den vielen Daemons und Linux-Betriebssystem-Tasks macht das manchmal tatsächlich das 4-fache an performance, besonders bei Internet (Iceweasel) und der grafischen Oberfläche, v.a. auch mit Geany.
Hatte erst nen B+ und hätte den fast in die Tonne gekloppt.
Mit dem 2B fluppts (relativ).

Danke.

Ja den habe ich auch im Auge. Ich brauch schon Rechenleistung da ich auch Gesichtserkennung mit OpenCV usw. nutzen will.