C++ sleep’ was not declared in this scope ?

Programmation
#1

hello
tout est dans le titre sauf le code que voici

#include <iostream>

using namespace std;

int main()
{
    cout << "Hello world!" << endl;
	sleep(1);
    return 0;
}

bon je viens d’installer la wheezy alors je me doute qu’il manquerai un paquet: j’ai mi la liste dans un fichier ci joins,
qui a été fournis par dpkg -l
sa devrai en dire long :confused:

je code avec code block 10.05 note que c’est installer en local et pas celui fourni par le gestionnaire de paquet le souci ce situe peux etre a ce niveau mai c’est peux probable:
j’ai essayer avec un simple makefile:

$ make
c++ -Wall -Wextra -pedantic   -c -o main.o main.cpp
main.cpp: In function ‘int main()’:
main.cpp:8:9: error: ‘sleep’ was not declared in this scope
make: *** [main.o] Erreur 1

je suis peut etre fatiguer m’enfin la je pense plutôt a un bug de g++ :\

note: ma signature n’est plus a jours
paquet.txt (182 KB)

#2

[quote=“man 3 sleep”]SYNOPSIS
#include <unistd.h>
unsigned int sleep(unsigned int seconds);[/quote]
:wink:

Très fatigué en effet, pour oublier que “not declared in this scope” se résout généralement grâce au bon #include ! :mrgreen:

#3

Curieux dans mes programme j’avais jamais besoins d’insérer ce fichier ?
il y a une résont particulière pour que cela soie devenu obligatoire ?

Merci pour l’info je l’ignorais :think: :023
Merci pour ta réponse :006

#4

[quote=“panthere”]Curieux dans mes programme j’avais jamais besoins d’insérer ce fichier ?
il y a une résont particulière pour que cela soie devenu obligatoire ?[/quote]
Tu incluais un fichier qui incluait unistd.h. C’est l’un des défaut du système d’inclusion par rapport à des import qu’on trouve ailleurs, je trouve. Tu as une mauvaise visibilité de tes dépendances.

#5

c’est donc juste pour connaître les dépendance. oki c est noter :slightly_smiling:

#6

D’un autre côté ça peut aussi être vu comme un avantage. :wink:
Exemple : foo utilise systématiquement bar dans sa partie publique. Si baz utilise foo (et donc bar aussi) pourquoi le forcer à importer les deux ?

Mais bon, on retombe sur un dilemme classique : verbosité et précision, contre concision et flou artistique. Je ne pense pas qu’il y ait de bonne ou de mauvaise solution, juste des choix arbitraires par les concepteurs du langage.
Perso je préfère la concision quitte à devoir jongler un peu avec le flou artistique qu’elle entraîne, mais ça dépend aussi du caractère de chacun. :slightly_smiling:

#7

Ça n’est pas vraiment comme ça. Avec des imports, tu récupère tout ce que tu utilise et uniquement ça. Si une bibliothèque possède une classe X, il n’y a pas besoin de technique particulière pour qu’elle ne soit pas utilisée par mégarde par l’utilisateur. Pour moi c’est un problème d’accessibilité et plus j’ai de contrôle sur la visibilité de mes données et classe mieux je me porte. C’est ce qui me plaît dans OSGI on contrôle précisément tout ce qui est accessible à l’extérieur du bundle. Ça demande un runtime plus lourd souvent, mais les performances ne sont pas toujours la priorité face à la fiabilité ou la maintenabilité.