WinFuture-Forum.de: [gelöst]C++: string und c_str() - WinFuture-Forum.de

Zum Inhalt wechseln

Nachrichten zum Thema: Entwicklung
Seite 1 von 1

[gelöst]C++: string und c_str() Programm stürzt ab


#1 Mitglied ist offline   Fabi 

  • Gruppe: aktive Mitglieder
  • Beiträge: 1.958
  • Beigetreten: 30. August 04
  • Reputation: 1
  • Geschlecht:Männlich

geschrieben 03. März 2011 - 16:42

Hi,

ich versuche gerade einen Standard C++ string in ein char-array (char*) zu konvertieren.
Bei dem Aufruf von strcpy stürzt allerdings das programm ab.

Hier mal der Code dazu:
#include <iostream>
#include <cstring>
#include <list>
#include <string.h>
#include <stdlib.h>
#include <stdio.h>
#include <math.h>
.
.
.
void convertList(string strEingabe, list<int> *lstEingabe)
{
	char *str_Neu;
	char *token;

	str_Neu = new char [strEingabe.size()+1];
	
	strcpy(str_Neu, (char*)strEingabe.c_str());

	fprintf(stdout,"Eingabe: %s",strEingabe.c_str());

	token = strtok(str_Neu, ",");

	while(token != NULL)
	{
		int buf = atoi(token);
		lstEingabe->push_back(buf);	
	}
}
.
.
.

Das Programm lässt sich zwar kompilieren stürzt dann aber wie gesagt an der Stelle, an der strcpy() aufgerufen wird ab.

Ich erhalte keine Fehlermeldung.

g++-Version:

Zitat

fabi@schnecki-workstation ~/Programmierung/C_C++/RSA $ g++ -v
Es werden eingebaute Spezifikationen verwendet.
Ziel: x86_64-pc-linux-gnu
Konfiguriert mit: /var/tmp/portage/sys-devel/gcc-4.4.5/work/gcc-4.4.5/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.4.5 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.5 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.5/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.5/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --without-ppl --without-cloog --enable-nls --without-included-gettext --with-system-zlib --disable-werror --enable-secureplt --enable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.4.5/python --enable-checking=release --disable-libgcj --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.4.5 p1.2, pie-0.4.5'
Thread-Modell: posix
gcc-Version 4.4.5 (Gentoo 4.4.5 p1.2, pie-0.4.5)


lg,
Fabi

Dieser Beitrag wurde von Fabi bearbeitet: 04. März 2011 - 18:09

0

Anzeige



#2 Mitglied ist offline   Fabi 

  • Gruppe: aktive Mitglieder
  • Beiträge: 1.958
  • Beigetreten: 30. August 04
  • Reputation: 1
  • Geschlecht:Männlich

geschrieben 04. März 2011 - 09:30

so, ich hab das ganze jetzt mal nochmal in nem minimalbeispiel getestet.

Hier mal der Code:
#include <iostream>
#include <string>
#include <string.h>
#include <stdio.h>

using namespace std;

int main(int argc, char **argv)
{
	char *strNeu;
	string strTest;


	cout << "Testtool" << endl;
	cout << "Quell-String: ";
	cin >> strTest;

	

	strNeu = (char*) malloc( sizeof(char) * strTest.length() + 1);

	strcpy(strNeu,strTest.c_str());

	fprintf(stdout,"Kopierter String: %s\n",strNeu);

	

	return 0;
}


Hier funktioniert das ganze "teilweise".
Hier mal die Ausgabe auf der Konsole:

Zitat

Testtool
Quell-String: Hallo Welt
Kopierter String: Hallo

Hier fehlt jetzt allerdings das "Welt" :ph34r:

Wenn ich "HalloWelt" ohne Leerzeichen schreibe, dann geht es:

Zitat

Testtool
Quell-String: HalloWelt
Kopierter String: HalloWelt


Jemand ne Idee, warum das oben nicht geht, bzw. warum hier nach dem ersten Leerzeichen abgeschnitten wird?

lg,
Fabi
0

#3 Mitglied ist offline   Witi 

  • Gruppe: aktive Mitglieder
  • Beiträge: 5.947
  • Beigetreten: 13. Dezember 04
  • Reputation: 43
  • Geschlecht:Männlich
  • Wohnort:Kingsvillage
  • Interessen:Frickeln

geschrieben 04. März 2011 - 10:04

Das liegt an cin. Das liest lediglich bis zum ersten Leerzeichen. Nimm stattdessen std::getline:

#include <iostream>
#include <cstring>
#include <string>
using namespace std;

int main () {
  char *strNeu;
  string strTest;

  cout << "Testtool" << endl;
  cout << "Quell-String: ";
  std::getline(std::cin, strTest);

  strNeu = new char [strTest.size()+1];
  strcpy(strNeu, strTest.c_str());

  cout << "Kopierter String: " << strNeu << endl;

  delete[] strNeu;
  return 0;
}

0

#4 _Fenix_

  • Gruppe: Gäste

geschrieben 04. März 2011 - 10:15

Am besten [1] verwendest Du auch strncpy [2], denn strcpy ist bekannt dafür Sicherheitslücken zu verursachen [1,3], da es keine Längenbeschränkung beim kopieren hat.
Außerdem noch ein kleiner Tipp [4] über new und malloc: Verwende in C++ besser einheitlich new. Das erhöht die Lesbarkeit und vermeidet einige Probleme bei Objekten. Falls das im Artikel [4] angesprochene realloc zum Problem werden sollte, ist sinnvoll zu überlegen, ob std::vector [5] nicht die bessere Wahl ist.

[1]: http://www.cert.org/archive/pdf/sd-bestpra...rings060914.pdf
[2]: http://www.cplusplus...string/strncpy/
[3]: http://www.cprogramm...ial/secure.html
[4]: http://www.codeproje...wandmalloc.aspx
[5]: http://www.cplusplus...nce/stl/vector/

Dieser Beitrag wurde von Fenix bearbeitet: 04. März 2011 - 10:34

0

#5 Mitglied ist offline   Fabi 

  • Gruppe: aktive Mitglieder
  • Beiträge: 1.958
  • Beigetreten: 30. August 04
  • Reputation: 1
  • Geschlecht:Männlich

geschrieben 04. März 2011 - 10:33

Beitrag anzeigenZitat (Witi: 04.03.2011, 10:04)

Das liegt an cin. Das liest lediglich bis zum ersten Leerzeichen. Nimm stattdessen std::getline:

Vielen Dank, das kannte ich noch garnicht.


Beitrag anzeigenZitat (Fenix: 04.03.2011, 10:15)

Am besten [1] verwendest Du auch strncpy [2], denn strcpy ist bekannt dafür Sicherheitslücken zu verursachen [1,3], da es keine Längenbeschränkung beim kopieren hat.

Gut, das werd ich mal noch machen.

Ich frag mich nur, warum dass in der Version aus dem ersten Post nicht funktioniert.
ich mach da ja eigenlich nichts anderes.

lg,
Fabi

EDIT:
strNeu = new char [strTest.size()+1];

Warum wird das hier eigentlich so gemacht und nicht mit malloc?

Dieser Beitrag wurde von Fabi bearbeitet: 04. März 2011 - 10:38

0

#6 _Fenix_

  • Gruppe: Gäste

geschrieben 04. März 2011 - 10:38

Im ersten Post ist eine Endlosschleife:

	while(token != NULL)
	{
		int buf = atoi(token);
		lstEingabe->push_back(buf);	
	}

Die Variable token wird in der Schleife nicht verändert. Vor der Endlosschleife wurde der Buffer von stdout nicht geleert, deshalb wird der Text nicht ausgegeben.

Zu der Frage nach malloc siehe [4] aus meinem vorherigen Post.

[4]: http://www.codeproje...wandmalloc.aspx

Dieser Beitrag wurde von Fenix bearbeitet: 04. März 2011 - 10:44

0

#7 Mitglied ist offline   Fabi 

  • Gruppe: aktive Mitglieder
  • Beiträge: 1.958
  • Beigetreten: 30. August 04
  • Reputation: 1
  • Geschlecht:Männlich

geschrieben 04. März 2011 - 10:41

Beitrag anzeigenZitat (Fenix: 04.03.2011, 10:38)

Die Variable token wird in der Schleife nicht verändert.

@Fenix: Vielen Dank, das hatte ich einfach übersehen, dann ist klar, warum das Programm nicht mehr reagiert hat.

Das werd ich heute Abend zu Hause gleich mal ändern.

Da ist wieder das Thema mit dem Wald und den Bäumen... :imao:

lg,
Fabi

EDIT:

Zitat

Zu der Frage nach malloc siehe [4] aus meinem vorherigen Post.

[4]: http://www.codeproje...wandmalloc.aspx


Vielen Dank, hatte da einfach so drüber gelesen :ph34r: .


EDIT2: Jetzt funktioniert es. Nochmal Vielen Dank.

Dieser Beitrag wurde von Fabi bearbeitet: 04. März 2011 - 18:09

0

Thema verteilen:


Seite 1 von 1

1 Besucher lesen dieses Thema
Mitglieder: 0, Gäste: 1, unsichtbare Mitglieder: 0