Zweidimensionale Array füllen

Torben K. schrieb:
> unsigned char array[5][5];
> array[0]={0b11111, 0b11111, 0b11111, 0b11111, 0b11111};
> array[1]={0b00001, 0b00001, 0b00001, 0b00001, 0b00001};
> array[2]={0b01111, 0b01111, 0b01111, 0b01111, 0b01111};
> array[3]={0b00001, 0b00001, 0b00001, 0b00001, 0b00001};
> array[4]={0b11111, 0b11111, 0b11111, 0b11111, 0b11111};

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.

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?

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.

In C++ geht die Array-Zuweisung:

1

#include <array>

2

3

int main () {

4

  std::array<std::array<unsigned char, 5>, 5> array {{

5

    {{ 0b11111, 0b11111, 0b11111, 0b11111, 0b11111 }},

6

    {{ 0b00001, 0b00001, 0b00001, 0b00001, 0b00001 }},

7

    {{ 0b01111, 0b01111, 0b01111, 0b01111, 0b01111 }},

8

    {{ 0b00001, 0b00001, 0b00001, 0b00001, 0b00001 }},

9

    {{0b11111, 0b11111, 0b11111, 0b11111, 0b11111 }}

10

  }};

11

  array[1] = {{ 0b01111, 0b01111, 0b01111, 0b01111, 0b01111 }};

12

}

Also den Aufruf von "gcc" durch "g++ -std=c++11" ersetzen und diesen 
Code verwenden.

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.

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.

Es gibt in C auch noch die compound literals, wenn auch erst seit 15 
Jahren.

1

int main()

2

    unsigned char* array[5];

3

    array[0] = (char[]){0b11111, 0b11111, 0b11111, 0b11111, 0b11111};

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...

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.

Jetzt fehlt nur noch die Anwendung aus dem embedded-Bereich, für die man 
sowas braucht.

Oliver

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...

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 dasselbe

W.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.

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

int array [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...