von C nach C++

Geht es dir um das lernen von C++ oder um eine Probelmlösung?
Ich würde verschiedene Ansätze austesten.
1. Jedes C(ANSI.89) Programm ist ein C++ Programm, aber nicht umgekehrt.
Also C-Style schreiben und gucken...
2. UML-Designer verwenden und C++ Template erzeugen und ausfüllen

oder 3. Bücher / E-Books besorgen und lesen, lesen, lesen...

Gruß aus Berlin

Seh hier kein Problem. Schreib dir eine Klasse die strtok- und 
atoi-Geschichten ausführt und dann haste dein C++.
Oder benutz die tausend anderen Möglichkeiten. Ein richtig Richtig gibt 
es hier wohl nicht...

Na dann würde ich aus meinen Ansätzen den 2. versuchen.

UML-Designer -> Code-Templates ...

Je nach dem Designer erhält man eine vernünftige Struktur und im Prinzip 
ein lauffähiges Programm-Gerüst.
-> http://de.wikipedia.org/wiki/UML-Werkzeug#Codeerzeugung

Die grosse Suchmaschine findest auch reichlich Infos: "UML-Designer C++"

Wenn die Grundlagen sitzten ist es, denke ich der einfachste Weg.

masl schrieb:

> Die STL wär mir erstmal am Liebsten.

Na, dann machs halt mit der STL.

Du hast eine wunderbare std::string Klasse.
Sieh dir an, welche Member die hat und such dir einen Weg, wie du mit 
den vorhandenen Funktionen deine gewünschte Funktionalität 
zurechtpfriemeln kannst.


Entweder du willst fertige Tokenizer. Dann musst du zu den großen 
Bibliotheken gehen. Oder du nimmst eine Nummer kleiner und setzt dir mit 
wenig Aufwand aus den Primtiv-Basisklassen das gewünschte zusammen.

Einen String an Tabulatoren in Einzelteile aufzubrechen ist ja jetzt 
nicht wirklich Raketentechnik, wenn man Funktionen wie find, erase, 
substr zur Verfügung hat. Die Eregebnisse könnte man zb in einen 
vector<string> stecken und die Sache ist gegessen.

> Unzulänglichkeiten zu umschiffen ("Bastellösungen") wie in C bisher
> notwendig war,

Ne, ne.
Langsam.
Alleine dadurch, dass dir die std::string schon mal das ganze dynamische 
Memory Management abnimmt, sparst du dir gegenüber einer reinen C-Lösung 
schon mal 80% vom Code und 95% aller dabei möglichen Fehler. Und der 
Rest ist eine Kombination aus ein paar Member Funktionen von std::string 
uns std::vector mit einer Schleife drumherum. Also soooo wild ist das 
auch wieder nicht. STL bedeutet ja nicht, dass es für jeden erdenklichen 
Aufgabenfall eine fix&fertige Lösung gibt.

schau dir Qt an.
Da ist es ziemlich straight forward.

1

QFile file("dateiname.tsv");

2

QVector<QVector<float>> dataFile;

3

4

if( file.open(QIODevice::ReadOnly) )

5

{

6

  QTextStream input(inputfile);

7

8

  while(!file.atEnd()){

9

    QString line = input.readLine();

10

    QStringList fields = line.split("\t");

11

    QVector<float> dataSet;

12

    foreach(auto& elem, fields){

13

      dataset.append(elem.toFloat());

14

    }

15

    dataFile.append(dataset);

16

  }

17

18

}

Peter II schrieb:
> Vlad Tepesch schrieb:
>> Da ist es ziemlich straight forward.
>
> ja und leider nicht so schnell wie jeden billige C version.

Solange die Strings von einem File kommen, ist das piep schnurz egal.
Ob die Zerlegung 50 oder 150 Nanosekunden dauert, interessiert 
heutzutage industriell keinen mehr. Wichtiger ist, dass es fehlerfrei 
und schnell programmiert werden kann.

Peter II schrieb:
> In C geht man einfach auf dem String durch und nimmt die elemente die
> man braucht.

klar geht das effizienter und Ressourcensparender.
Das mag sogar wichtig sein, wenn man riesige Datein einliest.

Großer Vorteil ist jedoch (gerade für Programmieranfänger), dass man 
recht wenig falsch machen kann, da sich die Klassen um die 
Speicherverwaltung kümmern.
Die Wahrscheinlichkeit sich irgendwo was durch Buffer-Overruns 
kaputtzuschreiben geht gegen 0.

Peter II schrieb:

> Wenn ich mit den gleichen Aufwand es schneller programmieren kann, warum
> sollte ich denn resourcen verschwenden nur weil es gerade modern ist?

:-)

Das haben wir alles in den letzten 40 Jahren gesehen. Die Anzahl der 
Programmabstürze, fehlerhaften Daten, Möglichkeiten zur Manipulation ist 
legendär. Aber die Hauptsache man hat es schnell und resourcenschonend 
geschrieben :-)
Hautzutage hat sich Gott sei Dank der Fokus verschoben. 'Speed um jeden 
Preis' ist heute kein Thema mehr.

> Wenn ich mit den gleichen Aufwand

Genau da liegt der Trugschluss. Bis du in deinem C tatsächlich 'das 
gleiche Resultat hast', ist dein persönlicher Aufwand in C beträchtlich 
höher! Es reicht nicht, wenn das C-Programm ungefähr dasselbe macht, wie 
das C++ Programm. Es muss sich auch in Fehlersituationen gleichwertig 
Verhalten (nämlich den Fehler abfangen und etwas sinnvolles damit tun). 
Und dann wird deine 'schnell-schnell' Lösung dann nämlich plötzlich gar 
nicht mehr so 'schnell-schnell'.

Und das fängt schon mit dieser ganz banalen Zeile an

1

    QString line = input.readLine();

bis du DAS in C #gleichwertig# hast, hab ich meine C++ Lösung schon 
ausgeliefert :-)


(Das geht nicht gegen dich persönlich.)

Peter II schrieb:
> Karl Heinz Buchegger schrieb:
>> Und das fängt schon mit dieser ganz banalen Zeile an
>> QString line = input.readLine();
>> bis du DAS in C 'gleichwertig' hast, hab ich meine C++ Lösung schon
>> ausgeliefert :-)
>
> gegen die zeile habe ich auch nichts - die Trick besteht ja daran immer
> das zu verwenden was jeweil sinnvoll ist.
>
> Es ging mir nicht um das einlesen der Zeile sondern um das Parsen und da
> bin ich mit C genauso schnell.

Es spricht ja auch nichts dagegen, auch in C++ dieses Parsen auf einem 
std::string zu machen und sich die gefundenen Positionen in einem size_t 
Array zu merken. Die Möglichkeiten sind ja da.

Wenn es dir aber eben nicht reicht, das Parsen quasi 'in place' im 
String zu machen, sondern wenn du die Strings dann tatsächlich einzeln 
benötigst, dann bietet dir C++ auch dann Möglichkeiten, welche du in C 
so erst mal nicht hast.


Gerade dann, wenn es eben darum geht, mal schnell eben ein Werkzeug zu 
schreiben, welches ein gerade anfallendes Problem kurzfristig löst, ist 
man mit einem objektorientierten Ansatz meistens um einiges schneller, 
eben weil man sich nicht um die kleinen Stolpersteine kümmern muss.

Karl Heinz Buchegger schrieb:
> Hautzutage hat sich Gott sei Dank der Fokus verschoben. 'Speed um jeden
> Preis' ist heute kein Thema mehr.

Unterschreibe ich zu 100%. Obwohl es immer sinnvoll ist im Hinterkopf zu 
wissen wie günstig/ungünstig bzgl. Laufzeit eine Lösung ist. Zumindest 
tendenziell.
In größeren Softwareprojekten sind üblicherweise <1% des Codes 
Zeitrelevant.
Die Kunst ist es nicht Code zu optimieren, bei dem es sch--- egal ist ob 
er in einer oder 10 µs ausgeführt wird, weil der User doch eine Sekunde 
braucht, sondern genau dieses 1% zu optimieren.

Olaf schrieb:
>> Hautzutage hat sich Gott sei Dank der Fokus verschoben. 'Speed um
>> jeden Preis' ist heute kein Thema mehr.
>
> Stimmt, heute gibt es schon Leute die laden ihr Handy taeglich auf und
> halten das fuer normal. Ich erlaube mir aber das fuer peinlich zu
> halten.

Was hat das eine mit dem anderen zu tun?

Ob sich ein Dialog in 1 Millisekunde oder in 1.5 Millisekunden 
schliesst, interessiert keine Sau. Beides ist für einen Benutzer "nicht 
merkbar".

Peter II schrieb:
> Karl Heinz Buchegger schrieb:
>> Ob sich ein Dialog in 1 Millisekunde oder in 1.5 Millisekunden
>> schliesst, interessiert keine Sau. Beides ist für einen Benutzer "nicht
>> merkbar".
>
> wenn die software 1Mil nutzer die damit einen höheren Stromverbrauch in
> diese zeit haben könnte man schon fast eine Windrad sparen.

Ach komm, das kannst du garnicht ernst meinen.
Der PC läuft bei den meißten eh einfach so zur Gaudi, weil keiner Lust 
auf runterfahrn und neu starten hat.

Keiner sagt hier dass man alles dreckig und ressourcenfressend 
programmieren muss.
Ihr tut ja alle als würde die Benutzung einer Bibliothek einen Overhead 
ohne Ende darstellen.

Aber wisst ihr was?
Genau so wie ihr niemals mit Assembler den C-Compiler in Sachen 
Optimierung schlagen werdet (jaja, zu 95% nicht) so werdet ihr mit 
Bytegepfriemel und LowLevel-Zugriffen wie in C üblich nicht die 
Performance der STL nachbilden können, zumindest nicht mit annähernd 
diesem Komfort und der Fehlertoleranz.
Denn, tut mir leid, den Leuten die solche Libs schreiben trau ich mehr 
zu als dem durchschnittlichen Forumuser.
Wieso also sich nicht auf Lösungen verlassen, die sich weltweit 
millionenfach bewährt haben?