Beim builden: Error 1 expected expression before '{' token
Ich möchte die einzelnen 5 Spalten der Array, mit jeweils 5 Werten
Füllen
Was mache ich falsch?
Karl Heinz schrieb:> Du hast kein C Buch gelesen
Stimmt, habe ich nicht :D
Und wenn ich nur den Speicherplatz einer Array benutzen möchte, die ich
immer wieder neu beschreibe?
Ich mein wenn ich Arrays nur intialisieren kann, müsste ich dann immer
wieder ne neue Array erstellen!? :O
Danke schonmal
Torben K. schrieb:> Und wenn ich nur den Speicherplatz einer Array benutzen möchte, die ich> immer wieder neu beschreibe?
Dann musst du dir was überlegen. Zb. jedes Element einzeln einen Wert
zuweisen.
> müsste ich dann immer wieder ne neue Array erstellen!
Man kann zb ein zusätzliches Array machen, welches die 'Standardwerte'
enthält, und dann die Werte von diesem 'Standard-Vorgabe' Array mit
Schleifen in das Array umkopieren, mit dem dann tatsächlich gearbeitet
wird (und dessen WErte dann auch verändert werden). Kommt auf die
Aufgebenstellung bzw. die konkrete Situation an, was man dann macht.
Und kauf dir ein C-Buch!
Karl Heinz schrieb:> Arrays kann man in C nicht zuweisen. Nur initialisieren
Anscheinend kann man Arrays in C doch Werte zuweisen, nur einzeln, wie
Kaj das schrieb.
Kaj schrieb:> unsigned char array[5][5];> array[0][0] = 0b.......;> array[0][1] = 0b.......;> array[0][2] = 0b.......;> array[0][3] = 0b.......;> array[0][4] = 0b.......;> array[1][0] = 0b.......;> array[1][1] = 0b.......;> array[1][2] = 0b.......;> array[1][3] = 0b.......;>> usw.
Scheint bei mir zu funktionieren, ist nur sehr umständlich :(
Das wundert mich, warum man in C nicht Arrays übersichtlich Werte
zuweisen kann.
Karl Heinz schrieb:> Und kauf dir ein C-Buch!
Werde ich demnächst tun.
Torben K. schrieb:> Karl Heinz schrieb:>> Arrays kann man in C nicht zuweisen. Nur initialisieren>> Anscheinend kann man Arrays in C doch Werte zuweisen, nur einzeln, wie> Kaj das schrieb.
Sonst wärs ja auch ein wenig sinnlos Arrays zu benutzen.
Natürlich kann man einzelnen Array-Elementen neue Werte zuweisen.
Gemeint war "Dem Array als Ganzem"
1
inti[5];
2
intj[5];
3
4
i=j;
Möööp. Die Zuweisungsoperation ist mit dem Array als Ganzes nicht
möglich.
Kleine ZwischenFrage:
Kann ich das Problem nicht umgehen, indem ich eine Array intialisiere,
nach gebrauch mit free() kille, und dann wieder neu intialisiere?
Der Speicherplatz wird nach free() doch wieder freigegeben, sodass ich
dann immer nur dein Speicher einer Array belege, oder nicht?
Torben K. schrieb:> Kann ich das Problem nicht umgehen, indem ich eine Array intialisiere,> nach gebrauch mit free() kille, und dann wieder neu intialisiere?
Was willst du mit free() wenn das Array nicht auf dem Heap liegt?
Was hindert dich daran das Array einfach mit memcpy() zu füllen?
TriHexagon schrieb:> Was hindert dich daran das Array einfach mit memcpy() zu füllen?
Ich möchte keine Array in eine andere kopieren.
Ich möchte im ganzen Programm eine Array haben, die je nach bedürfnis
komplett neu mit Daten gefüllt wird, die ich direkt übergebe.
Nur hatte ich gehofft, dass das als ganzer Datenblock geht (so wie es
beim initialisieren möglich ist), also
1
unsignedchararray[5][5]=
2
{
3
{0b11111,0b11111,0b11111,0b11111,0b11111},
4
{0b00001,0b00001,0b00001,0b00001,0b00001},
5
{0b01111,0b01111,0b01111,0b01111,0b01111},
6
{0b00001,0b00001,0b00001,0b00001,0b00001},
7
{0b11111,0b11111,0b11111,0b11111,0b11111}
8
};
Statt dessen geht das befüllen, wenn die array existiert ja wohl nur
Wert für Wert, also so:
Torben K. schrieb:> Ich möchte keine Array in eine andere kopieren.> Ich möchte im ganzen Programm eine Array haben, die je nach bedürfnis> komplett neu mit Daten gefüllt wird, die ich direkt übergebe.
Hab nicht weit genug gedacht, ich kann ja ne neue Array erstellen, die
Werte mit memcpy() auf meine eigentliche array übertragen.
Nur hab ich dann 2 (in meinem Programmverlauf 20, 30...) Arrays, welche
alle Speicher ziehen.
Und habe noch kein C Buch um herauszufinden, wie ich diesen Speicher
wieder freigebe, bzw diese ÜbergabeArrays lösche.
Die Daten, die in dem Array stehen sollen, müssen immer irgendwo
abgelegt sein. Auf einem Mikrocontroller hast Du zwei Speicherbereiche:
Den Flashspeicher (ROM) und den Arbeitsspeicher (RAM). Wenn Du zur
Laufzeit einzelne Werte ändern willst, muss das Array in den RAM.
Ansonsten reicht es, wenn es im ROM liegt.
Wenn Du in C ein Array im RAM anlegst und es mit bestimmten Werten
initialisierst, dann erzeugt der Compiler implizit ein Array im ROM mit
den Initialisierungsdaten und dazu Programmcode, der das Array im RAM
anlegt und die Daten aus dem ROM dort hinein kopiert.
Wenn Du dieses Array im RAM mehrmals "initialisieren" willst, musst Du
es nur etwas expliziter schreiben: Du legst ein Array mit den
Initialisierungswerten im ROM an und kopierst die Daten mit memcpy (bzw.
beim AVR-Mikrocontroller memcpy_P) ins gewünschte RAM-Array. Das ist im
Endeffekt nichts anderes, als der Compiler bei der ersten
Initialisierung implizit gemacht hat.
Bei einem Array kann man nach der Definition nicht mehr die Größe und
auch nicht die Position im Speicher ändern.
Man kann es auch nicht freigeben.
Es wird zerstört, wenn es den Gültigkeitsbereich (Block, Funktion)
verlässt.
Darum ist Speicher den man per malloc holt auch kein Array.
Hab anfänglich auch oft Arrays benutzt, mittlerweile ist es mir aber zu
blöd geworden, da Arrays in der Grösse beschränkt und allgemein
unhandlich sind und blöde Fehler fabrizieren.
Ich bau mir meine Arrays lieber selbst mit malloc. Da hat's soviel
Speicher wie im System frei ist man multipliziert einfach die
Basisaddresse mit der Länge der Werte und Anzahl Werte in der Spalte und
kommt so ganz einfach zur passenden Spalte ohne sich mit den C++ Fürzen
rumzuärgern.
Sollte am Ende eben das free() nicht vergessen
Tomate schrieb:> Sollte am Ende eben das free() nicht vergessen
Daher verwendet man den C++ std::vector , der ermöglicht die Verwendung
von Arrays komfortabler als in C möglich, man kann genauso 2D-Arrays
bilden & verwenden aber braucht sich zB nicht um free () zu kümmern
(Memory leak Sicherheit), man kann nachträglich die Größe ändern, das
ganze Array zuweisen, mit wenig Tipparbeit kopieren etc.
Simon K. schrieb:> Für> mich sieht es so aus als wüsste er gar nicht so ganz, was er will.
Ich denke er will folgendes:
Er in seinem ganzen Programm nur eine Array[5][5] haben, der er immer
wieder neue Werte zuweist, ohne dies Speicherplatz für Speicherplatz zu
tun.
Er weiß nur nicht wie er das programmiertechnisch umsetzen soll.
Wenn nur immer das gleiche Array mit festen Werten zu belegen ist, dann
kann man stattdessen einfach jeweils das Init-Array selbst verwenden,
bzw. dessen Startadresse.
Dann sind weder Kopiererei noch extra Speicherplatz für die Kopie
notwendig.
Simon K. schrieb:> Bevor er C++ verwendet, sollte er erst mal in C sattelfest sein.
"Bevor er C++ verwendet, sollte er erstmal in Algol sattelfest sein"...
Kleiner Tip: C und C++ sind zwei völlig eigenständige Sprachen, die man
ganz wunderbar unabhängig voneinander lernen kann.
Insbesondere kommt das "C-Subset" wie die Arrays in einer fundierten
C++-Ausbildung erst weit hinten dran. Lange nach std::vector.
Fred schrieb:> Kleiner Tip: C und C++ sind zwei völlig eigenständige Sprachen, die man> ganz wunderbar unabhängig voneinander lernen kann.
Absolut korrekt. Und wenn man erst C++ und dann C lernt, hat man den
Vorteil dass man nicht erst alle schlechten C-Angewohnheiten wieder
un-lernen muss, wenn man C++ lernt.
Fred schrieb:> Simon K. schrieb:>> Bevor er C++ verwendet, sollte er erst mal in C sattelfest sein.>> "Bevor er C++ verwendet, sollte er erstmal in Algol sattelfest sein"...>> Kleiner Tip: C und C++ sind zwei völlig eigenständige Sprachen, die man> ganz wunderbar unabhängig voneinander lernen kann.>> Insbesondere kommt das "C-Subset" wie die Arrays in einer fundierten> C++-Ausbildung erst weit hinten dran. Lange nach std::vector.
Das weiß ich schon, allerdings ist der Sprachumfang von C++ und die
Ideologie dahinter (OOP) so viel komplexer, dass er doch lieber erst mal
bei C (oder von mir aus auch bei Algol) bleiben soll.
Simon K. schrieb:> Das weiß ich schon, allerdings ist der Sprachumfang von C++ und die> Ideologie dahinter (OOP) so viel komplexer, dass er doch lieber erst mal> bei C (oder von mir aus auch bei Algol) bleiben soll
Oder gleich lieber einen Abakus benutzen? Keiner zwingt einen, sofort
alle Features von C++ einzusetzen . Man kann Freundlichkeiten wie
std::vector nutzen um mit wenig Aufwand stabile & effiziente Programme
zu schreiben, ohne all die Details zu kennen die dort im Hintergrund
arbeiten. Wenn man schon zB Java oder ruby oder Python kennt ist
std::vector auch viel intuitiver als C-Arrays...
Dr. Sommer schrieb:> Simon K. schrieb:>> Das weiß ich schon, allerdings ist der Sprachumfang von C++ und die>> Ideologie dahinter (OOP) so viel komplexer, dass er doch lieber erst mal>> bei C (oder von mir aus auch bei Algol) bleiben soll>> Oder gleich lieber einen Abakus benutzen? Keiner zwingt einen, sofort> alle Features von C++ einzusetzen . Man kann Freundlichkeiten wie> std::vector nutzen um mit wenig Aufwand stabile & effiziente Programme> zu schreiben, ohne all die Details zu kennen die dort im Hintergrund> arbeiten. Wenn man schon zB Java oder ruby oder Python kennt ist> std::vector auch viel intuitiver als C-Arrays...
Tja, das ist Ansichtssache. Ich komme eher aus dem Embedded Bereich und
sehe das eben etwas anders.
Simon K. schrieb:> Tja, das ist Ansichtssache. Ich komme eher aus dem Embedded Bereich und> sehe das eben etwas anders.
Wie siehst du denn dann dieses Beispiel:
Aufgabe ist eine Funktion zu schreiben, die "n" int-Arrays anlegt mit
den Längen 1,2,...n und diese über einen out-Parameter zurückgibt:
http://ideone.com/TNBPDL mit std::vector
http://ideone.com/po1tBB mit C-Arrays
die C-Version ist doppelt so lang und braucht eine extra Funktion zum
löschen. Der Tripel-Pointer ist mMn nicht gerade intuitiv und leicht zu
erläutern (jeder C-Anfänger verzweifelt erstmal an dem "char** argv"
Doppelpointer), und man muss genau aufpassen immer alles korrekt
freizugeben.
Das "std::vector<std::vector<int>>&" ist zwar mehr Tipparbeit als das
"int***", aber dafür sieht man dass es eine Referenz auf ein Array aus
Arrays von int ist.
Das "int***" ist ein Pointer auf ein Array aus Pointern auf Arrays. Es
könnte aber genausogut ein Array aus Pointern auf Arrays aus Pointern
auf int-Arrays sein. Und die Größen der Arrays sind auch erstmal nicht
bekannt, man muss sie alle einzeln mit übergeben (oder wie hier implizit
über "n" kennen) wenn man sie braucht. Da finde ich die C++ Version doch
wesentlich intuitiver.
Es gibt natürlich noch jede Menge weitere Beispiele wo C++ kürzer und
einfacher ist, aber das hier ist jetzt speziell für C-Array vs.
std::vector.
Dr. Sommer schrieb:> http://ideone.com/TNBPDL mit std::vector> http://ideone.com/po1tBB mit C-Arrays>> die C-Version ist doppelt so lang und braucht eine extra Funktion zum> löschen. Der Tripel-Pointer ist mMn nicht gerade intuitiv und leicht zu> erläutern (jeder C-Anfänger verzweifelt erstmal an dem "char** argv"> Doppelpointer), und man muss genau aufpassen immer alles korrekt> freizugeben.
Die Tatsache, dass man in C viel genauer hinschauen muss, um alles zu
verstehen und ja keinen Fehler zu machen, führt dazu, dass man sehr viel
konzentrierter arbeitet und weniger Fehler macht.
In C++ hingegen, wo auf den ersten Blick alles so leicht erscheint, wird
man leichtsinnig und macht deswegen viel mehr Fehler.
Genau so ist es auch dir bei deinen Beispielen ergangen: Der C-Code
scheint korrekt zu sein, aber im C++-Code ist die Zeile 7 fehlerhaft.
;-) SCNR
PS: Die Sonderbehandlung von n=0 ist in C genauso unnötig wie in C++,
was die Codegröße des C-Programms noch etwas reduziert.
Fred schrieb:> "Bevor er C++ verwendet, sollte er erstmal in Algol sattelfest sein"...
Tja, das war eine Sprache, die tatsächlich mit mehrdimensionalen Feldern
umgehen konnte. C kann das nicht und bei C++ kommt auch bloß eine
Verrenkung bei raus: man versuche doch mal, das Handling von Containern
jemandem zu erklären, der einfach nur mehrdimensionale Felder haben
will.
Insofern wäre es tatsächlich horizonterweiternd, mal ne Sprachdefinition
von Algol zu lesen. Einfach um die Grenzen der neueren Sprachen zu
begreifen, damit man damit umzugehen lernt.
und
"C und C++ sind zwei völlig eigenständige Sprachen.."
wiebitte? kopfschüttel... Das ist genauso bescheuert als wenn die Leute
von Rottweil behaupten, daß die aus Donaueschingen ja ne ganz andere
Sprache sprechen - die sollten mal nach Berlin kommen mit ihrem
Dialekt...
Aber zurück zum eigentlichen Thema. Vielleicht sollte der TO sich mal im
Detail anschauen, was er mit sowas wie
char x[5][4][3];
eigentlich anrichtet. Das NICHT zu verstehen, führt dann zu sowas:
Hans schrieb:> Wenn Du dieses Array im RAM mehrmals "initialisieren" willst, musst Du> es nur etwas expliziter schreiben: Du legst ein Array mit den> Initialisierungswerten im ROM an und kopierst die Daten mit memcpy (bzw.> beim AVR-Mikrocontroller memcpy_P) ins gewünschte RAM-Array.
Au Backe.
Bei all dieser Diskussion frage ich mich, WOZU man bloß der TO so ein
dussliges Array-Konstrukt haben will. Es macht ihm doch - wie man sieht
- mehr Streß als es ihm Nutzen bringt. Irgendwie geht's hier nur noch um
den Bart des Propheten aber nicht mehr um praktische Lösungen.
W.S.
Oliver schrieb:> Jetzt fehlt nur noch die Anwendung aus dem embedded-Bereich, für> die man> sowas braucht.
Vielleicht wenn man eine Reihe von Filtern braucht die verschieden große
Puffer brauchen. Oder verschieden große Puffer für verschiedene
Eingangskanäle. Oder oder oder... Der OP hatte scheinbar eine Anwendung.
Da du mir aber nicht widersprichst folgere ich dass du die std::vector
Version auch besser findest.
Yalu X. schrieb:> Die Tatsache, dass man in C viel genauer hinschauen muss, um alles zu> verstehen und ja keinen Fehler zu machen, führt dazu, dass man sehr viel> konzentrierter arbeitet und weniger Fehler macht.
Sehen wir ja am Heartbleed Bug, goto fail Bug, GNU TLS Bug und 1.000.000
weitere Fehler in C-Programmen - alles Fehler, wo jemand in C auf zu
viele Dinge gleichzeitig achten musste und daher eine "Kleinigkeit"
übersehen hat. In Java gibts nicht so viele Buffer-Overflows und Memory
Leaks...
>> In C++ hingegen, wo auf den ersten Blick alles so leicht erscheint, wird> man leichtsinnig und macht deswegen viel mehr Fehler.
Nach dieser Logik sind also Sprachen die einem kritische/fehleranfällige
Dinge abnehmen schwieriger und fehleranfälliger? ruby ist daher gleich
viel schwieriger weil man die Arrays nicht von Hand freigeben muss?
Sowas kann auch nur ein Embedded C Frickler behaupten...
> Genau so ist es auch dir bei deinen Beispielen ergangen: Der C-Code> scheint korrekt zu sein, aber im C++-Code ist die Zeile 7 fehlerhaft.
Jetzt nicht mehr :-P
W.S. schrieb:> C kann das nicht und bei C++ kommt auch bloß eine> Verrenkung bei raus: man versuche doch mal, das Handling von Containern> jemandem zu erklären, der einfach nur mehrdimensionale Felder haben> will.
C++ bietet glücklicherweise mächtige Methoden zur Abstrahierung und
Kapselung, sodass es kein Problem ist elegant nutzbare mehrdimensionale
Felder zu bekommen, zB so:
1
MultiField<int,3>f(8,9,10);// 3 Dimensionen mit der Größe 8x9x10
2
f[3][4][5]=7;// Feld-Zugriff
Das ist der Sinn einer Universalsprache wie C++ - sie kann keineswegs
alles was alle Anwendungsfelder benötigen (das kann keine Sprache) -
aber man kann es einbauen und dann komfortabel nutzen, als sei es Teil
der Sprache ("Domain Specific Language"). So kann man alle Teile einer
Anwendung in einer einzelnen Sprache (wie C++) schreiben, und muss nicht
für jedes Problem eine Spezialsprache bemühen und die dann irgendwie
aneinanderbasteln.
In C ist das natürlich alles nicht so schön.
W.S. schrieb:> die sollten mal nach Berlin kommen mit ihrem> Dialekt...
Nur das C++ kein Dialekt ist, sondern eine neue Sprache mit vielen sehr
mächtigen neuen Features, von denen C-Programmierer nicht zu träumen
wagen.
W.S. schrieb:> Bei all dieser Diskussion frage ich mich, WOZU man bloß der TO so ein> dussliges Array-Konstrukt haben will.
Vielleicht kennt er das aus so komplexen und daher schwierigen Sprachen
wie Python und versucht nun das C-Äquivalent zu verstehen...
Dr. Sommer schrieb:> Yalu X. schrieb:>> Die Tatsache, dass man in C viel genauer hinschauen muss, um alles zu>> verstehen und ja keinen Fehler zu machen, führt dazu, dass man sehr viel>> konzentrierter arbeitet und weniger Fehler macht.> ...> Sowas kann auch nur ein Embedded C Frickler behaupten...
Seit bekannt wurde, dass in diesem Forum bei den meisten Teilnehmern der
Ironiedetektor verkümmert ist (oder noch gar nie existent war), habe ich
mir angewöhnt, entsprechenden Beiträgen immer einen Smiley oder ein SCNR
anzufügen.
Bei obigem Beitrag habe ich sogar beides getan, aber offensichtlich
immer noch ohne Erfolg :-(
Ach Yalu,
ich hab da mal was zum Trost, nämlich ein Zitat:
" Vorwort zur 1.Auflage
"Language shapes the way we think,
and determines what we can think about
- B.L.Whorf"
C++ ist eine allgemein verwendbare Programmiersprache. Sie wurde
erfunden, damit der professionelle Programmierer mehr Vergnügen an
seiner Arbeit hat. Abgesehen von kleinen Details ist C++ eine Obermenge
von C. ..."
Das wirklich Interessante ist das Zitat im Zitat.
Ich sag's mal mit meinen Worten: Wer bislang nur C (oder C++, ist ja
fast genau dasselbe) kennen gelernt hat, kann auch nicht mehr anders
denken und er kann auch nicht mehr an etwas Anderes denken.
Das ist der Knackpunkt.
Es ist die fest eingewachsene Scheuklappe.
Stroustrup war im Wesentlichen C Programmierer und er hat eben nur C hie
und da ein Stück ausgebeult, immer nur das eine oder andere Feature
hinzugefügt, was ihm gerade so aufgestoßen ist. Immer nur Denken bis zum
eigenen Mützenrand und panische Angst davor, alten Mist auszumisten. Und
so ist C++ eben doch nix anderes als ein etwas ausgebeultes C. Das
Einzige wirklich Neue ist die Objektgeneriererei und
Operatorüberladerei. Oder von mir aus auch noch cout ;-)
Es ist schon eine Art Treppenwitz.
W.S.
Yalu X. schrieb:> Bei obigem Beitrag habe ich sogar beides getan, aber offensichtlich> immer noch ohne Erfolg :-(
Es sah so aus als gehörte das SCNR nur zum letzten Satz, der mit der
Zeile 7. Vielleicht gescoptes SCNR verwenden:
SCNR {
/* Beitrag */
}
W.S. schrieb:> oder C++, ist ja fast genau dasselbeW.S. schrieb:> Und er hat eben nur C hie> und da ein Stück ausgebeult, immer nur das eine oder andere Feature> hinzugefügt, was ihm gerade so aufgestoßen ist.
Das kannst auch nur du behaupten. Dass du keine Ahnung von C++ hast hast
du ja zu genüge bewiesen.
W.S. schrieb:> Immer nur Denken bis zum> eigenen Mützenrand
Es ging halt darum die gerade von Embedded Entwicklern so beschworene
Effizient beizubehalten. Das hat auch ganz gut geklappt. Wenn du andere
"innovative" Konzepte haben willst musst du eben eine andere Sprache
nehmen und mit den Konsequenzen leben.
> und panische Angst davor, alten Mist auszumisten.
Angst ist ein sehr sinnvoller Instinkt. Wenn man in C++ keine C-API's
mehr verwenden könnte und alte C-Programme nicht nach C++ konvertieren
könnte, würde gar keiner mehr C++ verwenden. Damit wäre auch nichts
gewonnen.
W.S. schrieb:> Das> Einzige wirklich Neue ist die Objektgeneriererei und> Operatorüberladerei.
templates, Exceptions, Destruktoren, Überladungen, statische
Polymorphie, RAII, standard Container, ausgefeilte Resourcen-Verwaltung
sind ja alles unwichtige Nebensachen die es in C ja auch schon gab...
oder nicht (falls du weißt was das ist)?
W.S. schrieb:> Ich sag's mal mit meinen Worten: Wer bislang nur C (oder C++, ist ja> fast genau dasselbe) kennen gelernt hat, kann auch nicht mehr anders> denken und er kann auch nicht mehr an etwas Anderes denken.
Es gibt Leute, die können C, C++, ruby, Python, Scala, Haskell, LISP,
Scheme, Java, diverse Assembler, Pascal, PHP, ... und benutzen dennoch
für bestimmte Dinge C(++). Vielleicht ist die C++ Denkweise doch nicht
völlig ungeeignet für alles.
Aber wo du doch so schön daher erzählst dass alles besser als C++ ist -
welche bahnbrechenden Sprachfeatures fehlen dir denn und passen auch
in den Kontext Low-Level & Effizienz? Multidimensionale Arrays zählen
nicht dazu, denn die kann man ja wie gesagt leicht nachbauen. Es geht um
echte Features, die man nicht nachrüsten kann und die - wie die
richtigen Features in C++ - die Abstraktion und Erweiterbarkeit direkt
verbessern.
Dr. Sommer schrieb:> Es ging halt darum die gerade von Embedded Entwicklern
Embedded Entwickler als Paten für C++ ?? Du machst (unfreiwillig) Witze.
Lies einfach noch mal den Stroustrup - inclusive der Vorworte - und du
kannst dich dann anhand des Gelesenen selbst eines Besseren belehren.
Ich hab dazu keine Lust. Allerdings gibst du hier ein sehr schönes
Exempel ab für den oben zitierten Satz aus dem Stroustrup: "Language
shapes the way we think, and determines what we can think about"
Im Grunde ginng es hier um mehrdimensionale Felder - tja, und die gibt
es nicht un C und sie gibt es auch nicht in C++. Auch wenn du hier mit
allerlei Workarounds versuchst, dich um diese klare Aussage zu drücken,
bleibt sie doch wahr. Das, was es in C und C++ gleichermaßen gibt, sind
Arrays of Arrays - und das ist inhaltlich was ganz anderes als
mehrdimensionale Arrays. Sei nicht so verbockt, sondern akzeptiere doch
einfach die Wahrheit.
W.S.
W.S. schrieb:> Dr. Sommer schrieb:>> Es ging halt darum die gerade von Embedded Entwicklern>> Embedded Entwickler als Paten für C++ ?? Du machst (unfreiwillig) Witze.
Für alles andere gibts ja Java etc. C++ wird nur noch für
Performance-kritische Dinge benötigt, wie Embedded.
> Lies einfach noch mal den Stroustrup - inclusive der Vorworte - und du> kannst dich dann anhand des Gelesenen selbst eines Besseren belehren.
Habe ich schon längst. Du hast offenbar nur das Vorwort gelesen.
> Ich hab dazu keine Lust. Allerdings gibst du hier ein sehr schönes> Exempel ab für den oben zitierten Satz aus dem Stroustrup: "Language> shapes the way we think, and determines what we can think about"
Bla, Bla, Bla mit Sicherheitsabstand um den heißen Brei. Was konkretes
kannst du wohl nicht von dir geben.
> Im Grunde ginng es hier um mehrdimensionale Felder - tja, und die gibt> es nicht un C und sie gibt es auch nicht in C++.
Ja. Das stimmt. Aber auch nicht in Java, ruby, Python, Scala. Und, macht
das was? Nein, denn diese Universalsprachen machen es einfach, eine
Library zu implementieren & zu verwenden, die genau solche
Funktionalität beinhaltet.
> Auch wenn du hier mit> allerlei Workarounds versuchst, dich um diese klare Aussage zu drücken,> bleibt sie doch wahr. Das, was es in C und C++ gleichermaßen gibt, sind> Arrays of Arrays - und das ist inhaltlich was ganz anderes als> mehrdimensionale Arrays. Sei nicht so verbockt, sondern akzeptiere doch> einfach die Wahrheit.
Diese Wahrheit schon, aber es ist auch die Wahrheit, dass das völlig
egal ist. Man wählt seine Sprache nicht danach aus ob sie ein bestimmtes
Anwendungsfeature X (wie mehrdimensionale Felder oder integrierte
Mathe-Algorithmen oder integriertes GUI-Framework etc.) hat, sondern wie
gut man solche Features hinzufügen kann - denn dadurch beestimmt sich,
ob die Sprache geeignet ist für Real-World-Anwendungen, die
typischerweise eine Menge solcher Features benötigen, die typischerweise
nicht alle integriert von einer einzelnen Sprache abgedeckt werden.
Was bringt mir eine Sprache mit integrierten mehrdimensionalen Arrays,
wenn es eine unglaubliche Frickelei ist eine GUI damit zu basteln? Da
verwende ich doch lieber eine Universalsprache (wie C++), die "von Haus
aus" wenig kann, aber durch Libraries alles erdenkliche elegant nutzbar
macht.
Und außerdem, mehrdimensionale Arrays sind soweiso nicht so das
Killerfeature, sowas wie templates und RAII schon eher...
Ach, Mr. Dolittle,
du wirst langsam langweilig. Ständig neue Behauptungen deinerseits und
das alles ohne jeglichen Bezug auf das Thread-Thema.
Liefere lieber mal nen konkreten und sinnvollen Beitrag zur Lernbetty,
wo du ja auch schon mal großspurig getönt hast, bevor du hier weiter
solche Töne von dir gibst. Das wäre vielleicht was Sinnvolleres -
vorausgesetzt, er ist ein Beitrag zur Verbesserung des allgemeinen
Bildungsniveaus der hier ja zahlreich vertretenen Programmier-Anfänger.
W.S.
W.S. schrieb:> Ach, Mr. Dolittle,> du wirst langsam langweilig.
Du glücklicherweise nicht, es macht immer wieder Spaß dir etwas
beizubringen.
> Ständig neue Behauptungen deinerseits und> das alles ohne jeglichen Bezug auf das Thread-Thema.
Wer hat denn hier mit Algol und C++-Bashing angefangen? Wenn du genau
hinsiehst, wirst du in meinem 1. Post einen sinnvollen Beitrag zum Thema
finden.
Du redest die ganze Zeit wirres Zeug über C++ ohne tatsächlich etwas zu
sagen - ist dein Hobby das Lesen von Vorwörtern bei gewissenhafter
Vermeidung des tatsächlichen Inhalts, um dich dann im Internet mit nicht
Halb-, nein, Viertel-Wissen lächerlich zu machen?
> Liefere lieber mal nen konkreten und sinnvollen Beitrag zur Lernbetty,
Das einzig sinnvolle wäre da Shift-Entf.
> wo du ja auch schon mal großspurig getönt hast, bevor du hier weiter> solche Töne von dir gibst. Das wäre vielleicht was Sinnvolleres -> vorausgesetzt, er ist ein Beitrag zur Verbesserung des allgemeinen> Bildungsniveaus der hier ja zahlreich vertretenen Programmier-Anfänger.
Im Gegensatz zu dir habe ich noch was anderes zu tun als im Internet
rumzugammeln. Du musst dich noch etwas gedulden und dich bis dahin mit
stückweiser Weisheit meinerseits begnügen - siehe Links im Anhang (so
viele Links kann man leider nicht unangemeldet direkt posten).
Dein jeweiliges Schweigen in den Threads werte ich als Zustimmung - hast
du also etwas gelernt. Freu dich doch.
Dr. Sommer schrieb:> Du redest die ganze Zeit wirres Zeug über C++ ohne tatsächlich etwas zu> sagen
Ach, du nicht?
Dr. Sommer schrieb:> Für alles andere gibts ja Java etc. C++ wird nur noch für> Performance-kritische Dinge benötigt, wie Embedded.
Ich wette, dass nicht mal 1% der Software auf meinem Rechner mit Java
programmiert ist.
Simon K. schrieb:> Ich wette, dass nicht mal 1% der Software auf meinem Rechner mit Java> programmiert ist.
Dann hast du wohl gezielt ausgewählt. Protip: Java-Software sieht man es
nicht zwangsläufig an ob sie Java ist oder nicht. Und schau mal auf dein
Handy.
Viel der C(++) -Software auf PC's ist entweder alt oder muss mit alten
Libraries klarkommen, aber Performance ist da nur ein kleiner Grund für
die Nutzung von C(++). Tatsächlich sind viele C++ - Programme gar nicht
so geschrieben, dass sie die potentiellen Performance-Vorteile von C++
nutzen.
Die Tools für Java (und auch .NET) -Programmierung sind mittlerweile so
gut, das macht einfach mehr Spaß als C(++). Das kann schon ein
ziemliches Argument für Java sein...
Und schau mal hier:
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
C ist nur ganz knapp vor Java, und das wird 3x so viel wie C++
verwendet.
Simon K. schrieb:>> Du redest die ganze Zeit wirres Zeug über C++ ohne tatsächlich etwas zu>> sagen> Ach, du nicht?
Nein. Ich weiß immerhin, wovon ich rede. Hat W.S. ein einzigen konkreten
Punkt genannt, wo C++ wirklich einen gravierenden Nachteil hat (die gibt
es, das weiß ich, aber W.S. wohl nicht so genau), und habe ich nicht
ganz konkret am Beispiel die Vorteile von C++ gezeigt?
Dr. Sommer schrieb:> Und schau mal hier:> http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html> C ist nur ganz knapp vor Java, und das wird 3x so viel wie C++> verwendet.
Glaube keiner Statistik, die du nicht selbst gefälscht hast (sorry, ich
muss hier mal querschießen). Dieser Index zeigt nur eine gewisse
Popularität der Sprachen an, das hat jedoch nicht zwangsweise etwas mit
der Verbreitung oder Performance etc. zu tun. Interessant wird die
Statistik, wenn man sich den zeitlichen Verlauf des Index' genauer
anschaut: da ist nämlich Java seit Jahren rückläufig :P
Auch ist in der Statistik Objective-C zu finden, eine Sprache die
wahrscheinlich nur die ganzen Apple-Jünger freiwillig auf Lunge rauchen.
Der ursprüngliche Aufhänger für diese Diskussion (bzgl. std::vector) ist
trotzdem Käse, da man nicht unbegrenzt verallgemeinern sollte. Klar kann
ich auch schreiben: die Verwendung von Float und Double ist im
Allgemeinen besser als Integer aufgrund geringerer Rundungsfehler.
Trotzdem läuft eine in Software gegossene Float Bibliothek auf einem
kleinen Atmega8 einfach nur langsam und besch.... Daher bleibt man dann
oft auch bei Integer, zumindest im Embedded-Bereich, sofern die
Anwendung nichts spezielles erwartet.
Es ist immer wieder amüsant zu sehen, wie hier manche Threads abdriften.
Brater schrieb:> Glaube keiner Statistik, die du nicht selbst gefälscht hast (sorry, ich> muss hier mal querschießen).
Ja. Aber dass Java sich großer Popularität erfreut ist nicht frei
erfunden.
> Der ursprüngliche Aufhänger für diese Diskussion (bzgl. std::vector) ist> trotzdem Käse, da man nicht unbegrenzt verallgemeinern sollte.
Ich habe ja auch nicht zu std::vector, sondern zu std::array geraten.
Das hat keinen Overhead bzgl. C-Arrays, ist aber komfortabler. Der
std::vector war eine Antwort auf dynamische C-Arrays mit "malloc" und
"free" - wenn man die verwenden kann, kann man auch definitiv
std::vector verwenden.
> Klar kann> ich auch schreiben: die Verwendung von Float und Double ist im> Allgemeinen besser als Integer aufgrund geringerer Rundungsfehler.
Überhaupt nicht. zB die Zahl 16777217 lässt sich als 32bit-float nicht
darstellen, als 32bit-Integer aber schon. Vergleiche sind mit integer
besser etc.
> Trotzdem läuft eine in Software gegossene Float Bibliothek auf einem> kleinen Atmega8 einfach nur langsam und besch.... Daher bleibt man dann> oft auch bei Integer, zumindest im Embedded-Bereich, sofern die> Anwendung nichts spezielles erwartet.
Wer redet von ATmega's? Soll man als Antworter jetzt gleich von der
kleinstmöglichen Plattform ausgehen? A priori kann man davon ausgehen,
dass die Sprache den Standard einhält, und Standard-C++ enthält den
std::vector.
> Es ist immer wieder amüsant zu sehen, wie hier manche Threads abdriften.
Und wie manche Leute den Thread gar nicht erst lesen, aber dann über
späte Beiträge herziehen...
Dr. Sommer schrieb:> Ja. Aber
aber, aber, aber..
Junge hör doch endlich mal auf mit deinem krampfhaften Versuch, alle
Dinge besserwissen zu wollen. Vorschlag meinerseits: Mach einfach nen
eigenen Thread auf, wo du dich ungestört über alles auslassen kannst,
was dir nicht paßt.
Und dein Vorschlag von "std::vector" hilft auch nicht darüber hinweg,
daß eben auch C++ keine mehrdimensionalen Arrays kennt, was ja
dedizierter Ausgangspunkt dieses Threads war.
W.S.
W.S. schrieb:> Dr. Sommer schrieb:>> Ja. Aber>> aber, aber, aber..
Verwirr mich nicht mit Tatsachen?!
> Junge hör doch endlich mal auf mit deinem krampfhaften Versuch, alle> Dinge besserwissen zu wollen Vorschlag meinerseits: Mach einfach nen> eigenen Thread auf, wo du dich ungestört über alles auslassen kannst,> was dir nicht paßt.
Das musst DU gerade sagen, der du keine Gelegenheit auslässt nicht nur
dein Viertelwissen loszuwerden sondern das auch noch in einem
unmöglichen Tonfall.
> Und dein Vorschlag von "std::vector" hilft auch nicht darüber hinweg,> daß eben auch C++ keine mehrdimensionalen Arrays kennt, was ja> dedizierter Ausgangspunkt dieses Threads war.
Sehr traurig. Aber das spielt ja wie gesagt keine Rolle. Aber jetzt
interessiert mich doch, was passt dir an
1
intarray[4][5];
2
array[1][2]=25;
nicht? Ob das jetzt tatsächlich ein Array aus Arrays oder ein
multidimensionales Array ist ist doch wurst, da man beide gleich
verwenden kann?!
Und der Ausgangspunkt des Threads war das "Unter"-Arrays zuweisen, und
das wird durch std::vector oder std::array wunderbar gelöst. Ob das
jetzt ein "Vektor aus Vektoren" oder "Multidimensionaler Vektor" ist
spielt keine Rolle.
Und falls du der Meinung bist dass es für eine Sprache essentiell ist in
der Sprachdefinition mehrdimensionale Arrays zu haben, bleiben ziemlich
wenige Sprachen übrig...
Dr. Sommer schrieb:> Sehr traurig. Aber das spielt ja wie gesagt keine Rolle. Aber jetzt> interessiert mich doch, was passt dir an>> int array [4][5];> array [1][2] = 25;>> nicht?
SCNR {
Bei echten zweidimensionalen Arrays stehen beide Indizes, getrennt durch
ein Komma, innerhalb eines einzelnen Klammerpaars.
Zum Glück ist C aber mächtig genug, um aus unechten zweidimensionalen
Arrays echte zweidimensionalen Arrays zu machen:
1
#define Komma ][
2
3
intarray[4Komma5];
4
array[1Komma2]=25;
Jetzt sehen die Array-Deklarationen und -zugriffe aus wie in Psacal,
sogar mit dem zusätzlichen Vorteil, dass anstelle des kryptischen
Zeichens "," das klar verständliche Schlüsselwort "Komma" verwendet
wird.
Das Ganze funktioniert selbstverständlich auch für höherdimensionale
Arrays.
}
Thread beobachten
Seitenaufteilung abschalten