Discussion :

[CleeM]

Bonjour à tous,

Depuis peu, lorsque je lance la commande System, mon programme plante.
Par exemple, j'essaye un simple System("pause") et mon programme plante.

J'ai pourtant toutes les libs/headers nécessaire à l'appel de cette fonction.

Je vous joins tous mes includes, au cas où certains feraient planter la fonction :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
#ifdef WIN32
	#include <winsock2.h>
	#include <Windows.h>
#elif defined (linux)
	#include <sys/types.h>
	#include <sys/socket.h>
	#include <netinet/in.h>
	#include <arpa/inet.h>
	#include <unistd.h> // GetHostName
	#include <netdb.h>
	#define INVALID_SOCKET -1
	#define SOCKET_ERROR -1
	#define closesocket(s) close(s)
	typedef int SOCKET;
	typedef struct sockaddr_in SOCKADDR_IN;
	typedef struct sockaddr SOCKADDR;
	typedef struct in_addr IN_ADDR;
#else
	#error not defined for this platform
#endif
 
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <vector>
 
#pragma comment(lib,"ws2_32.lib")

Je n'ai rien changé à ce niveau là depuis un moment je trouve donc ça très étrange !
Et dans les propriétés de mon projet, tout est normal (enfin rien de changé récemment aussi!).


PS: J'exécute le programme sous Windows, pour les #ifdef.

[Neckara]

Ton programme plante, mais quel est le message d'erreur? Segfault ?


Sinon system ne prend pas de majuscule il me semble.

Et une dernière chose, on est en C++ pas en C donc pour les includes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
#include <cstdio>
#include <cstdlib>
#include <cstring>

[CleeM]

Merci pour les infos, je ne savais pas que l'appel aux libs était différent

Quand à l'erreur, oui c'est une segfault. Donc je n'arrive pas à avoir plus d'infos sur l'erreur :/

[Jean-Marc.Bourguet]

Et une dernière chose, on est en C++ pas en C donc pour les includes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
#include <cstdio>
#include <cstdlib>
#include <cstring>

Pure preference stylistique. Et on a parfois des raisons non stylistiques de preferer la version .h pour certains entetes (en particulier sous Unix on a parfois des declarations additionnelles dans ces fichiers -- a l'origine certains sont des fichier de Unix qui ont ete partiellement standardise en C -- qui sont absentes avec la version cxxx et presentes avec xxx.h) donc le faire systematique pour tous a du sens.

[Neckara]

Je croyais qu'avec les xx.h, on avait l'implémentation C et avec les cxx on avait l'implémentation plus orienté C++.

Comme pour la fonction strcpy de cstring où on va faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

while(chaine1++ = chaine2++);

Chose qui ne marcherait pas en C.

Je doute qu'ils se soient amusés à refaire un certain nombres d'en-têtes standards juste pour des raisons stylistiques.

Il me semble aussi que string.h est obsolète (d'après la FAQ C++), donc ce doit aussi être le cas d'autres header en .h comme iostream.h ?

Toujours d'après la FAQ :

Il est en de même avec tous les fichiers d'en-tête standards en C++, y compris avec ceux de la bibliothèque standard C. Pour des raisons d'uniformisation, il faut désormais les inclure sans le .h et en préfixant leur nom par la lettre c (pour souligner le fait qu'ils sont issus du C).

EDIT : ton segfault viens du fait que tu as écris n'importe où en mémoire il faut donc t'armer de patience et relire tout ton code.

[Jean-Marc.Bourguet]

Je croyais qu'avec les xx.h, on avait l'implémentation C et avec les cxx on avait l'implémentation plus orienté C++.

Normativement en C++11, la seule difference entre xxx.h et cxxx, c'est que dans le premier cas les declarations sont a coup sur presentes dans le namespace global et peut-etre dans le namespace std, tandis que pour cxxx, les declarations sont a coup sur presentes dans std et peut-etre dans le namespace global. Avant, la garantie etait un peu plus forte pour cxxx; mais en pratique les implementations n'y obeissaient pas toutes.

En pratique, il y a une autre difference: les declarations demandees par d'autres normes comme POSIX pour les versions xxx.h etaient toujours presentes (quand demandees par ces normes) dans xxx.h quand j'ai teste, la situation variait pour cxxx. C'est une bonne raison de preferer xxx.h (surtout quand par ailleurs on inclus des entetes purement POSIX comme unistd.h, ce que fait l'OP).

Oui la forme xxx.h est deprecated avec comme signification Normative for the current edition of the Standard, but not guaranteed to be part of the Standard in future revisions ce qui ne veut pas dire grand chose on a vire des choses qui ne l'etaient pas; on en a conserve qui l'etaient (j'ai meme le vague souvenir qu'il y en a qui l'etaient et qui non seulement ont ete conservees mais ne sont plus deprecated).

Comme pour la fonction strcpy de cstring où on va faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

while(chaine1++ = chaine2++);

Chose qui ne marcherait pas en C.

Et ça marche en C++? (Le resultat de ++ postfixe sur un pointeur n'est pas une rvalue).
Par contre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

while (*chaine1++ = *chaine2++);

devrait fonctionner en C et en C++. Et surtout, on se fout de l'implementation.

Je doute qu'ils se soient amusés à refaire un certain nombres d'en-têtes standards juste pour des raisons stylistiques.

Tu as encore des illusions a perdre.

Il me semble aussi que string.h est obsolète (d'après la FAQ C++) donc ce doit aussi être le cas d'autres header en .h comme iostream.h ?

Attention. Les formes en .h, c'est pour les fichiers provenant du C. iostream ne provient pas du C, en inclusant iostream.h, Dieu seul sait ce que tu auras (au choix, une erreur, <iostream> avec un using std;, <iostream> avec des using plus selectifs, une implemetation des stream non templatees et compatible avec ce que fournissait ton fournisseur avant la norme).

Pour string, on a <string.h> et <cstring> avec la difference expliquee ci-dessus et <string> qui definit le type std::string. Il y a aussi un <strings.h> sous Unix.

[CleeM]

Merci pour tous ces détails sur les includes, même si ce n'était pas le sujet de base je suis content d'avoir lancé un débat !

Quand à mon souci de SegFault, quand tu dis que j'ai écrit n'importe où en mémoire, tu veux dire que je n'ai pas fait attention aux news/delete ; malloc/free ou autre chose? Car à ce niveau je fait attention normalement!

[Neckara]

Et ça marche en C++? (Le resultat de ++ postfixe sur un pointeur n'est pas une rvalue).
Par contre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

while (*chaine1++ = *chaine2++);

devrait fonctionner en C et en C++. Et surtout, on se fout de l'implementation.

J'ai en effet oublié les '*', ces temps-ci je fais pas mal d'erreurs bêtes dans mes codes.
Pour contre, je confirme que ce code ne marchera pas en C.
En effet, le premier octet ne sera pas copié.

Attention. Les formes en .h, c'est pour les fichiers provenant du C. iostream ne provient pas du C, en inclusant iostream.h, Dieu seul sait ce que tu auras (au choix, une erreur, <iostream> avec un using std;, <iostream> avec des using plus selectifs, une implemetation des stream non templatees et compatible avec ce que fournissait ton fournisseur avant la norme).

L'exemple de iostream.h a été pris dans la FAQ.

Merci pour ces renseignements sur la différence entre cxx et xx.h


Pour le segfault, ce n'est pas forcément la faute de news/delete mais par exemple la faute de pointeurs, dépassement de tableau...
Par contre dans un code en C++ on évite d'utiliser malloc et free.
Après même en faisant attention, il est impossible de ne pas faire d'erreurs.