striiiiiiiiiiiiiiing - Page 18

libkdecore ne fait pas 100 MO, et KDE 4 est portable autant que Qt l'est.

oui, oui, on sait tout ça.

D'ailleurs, ça ne se limite pas aux fenêtres et à la pomme, KDE a même été porté vers Haiku OS.

oui, oui, on sait tout ça.

Bon, je comprends rien au principe même de ces dates

Qu'est-ce que c'est que cette histoire d'itérateurs ? Que viennent-ils faire là ?
Pourquoi je ne trouve pas de fonction qui me renvoie une structure ou à la rigueur une chaine contenant une date ?

En plus dans l'exmple donné, la date à traiter est passée directement dans le programme, hors je veux exactement le contraire : récupérer l'heure du PC sans rien demander.

J'ai rien, mais rien compris à cette fonction

http://www.cplusplus.com/reference/std/locale/time_get/get_date/

c'est trivial pourtant, suffit de recopier l'exemple

(skoi ce truc de ouf )

squalyl (./516) :
c'est trivial pourtant, suffit de recopier l'exemple

nein justement, je veux pas d'une entrée manuelle ^^

ça peut lire n'importe quel stream

les itérateurs c'est des sortes de pointeurs (\o/) abstraits qui représentent une position dans une liste , un stream, un ksétéra.

donc la, à get date on lui file deux itérateurs et il parse ce qui se trouve entre les deux.

c'est tordutionné quand même.

donc c'est pas du tout ces fonctions qu'il te faut. time_get sert juste à parser une string pour en extraire une date
ce qu'il te faut, c'est time() + localtime()

(ah, j'avais mal comprendu 'entrée manuelle')

Mais pourquoi t'obstines-tu à utiliser cette pourriture hyper-compliquée de STL plutôt que la libQtCore?

je commence à saturer, là, ou alors t'es vraiment fort et tu le fais exprès. J'hésite.

Merci aze. Visiblement, ce sont des fonctions de ctime.h, la bibliothèque C ? Pas de souci pour utiliser ça en C++ ?

ctime (ou time.h, mais l'utilisation directe des headers C en C++ est dépréciée), pas ctime.h (obsolète et supprimé dans les g++ récents)!

il faut juste que tu fasses #include <ctime> au lieu de #include <time.h>

squalyl (./522) :
je commence à saturer, là, ou alors t'es vraiment fort et tu le fais exprès. J'hésite.

-vraiment -fort, s'il l'était un tant soit peu il essayerait un minimum de le dissimuler
(cela dit c'est la finalité de Folco je crois d'utiliser Qt, donc à ce moment je suis d'accord avec Kevin - si Qt est tellement mieux que STL alors autant s'y mettre sans trop tarder. Perso je suis assez pour l'idée qu'il faut faire un truc motivant pour apprendre, après le reste vient tout seul - la question qui subsiste c'est: est-ce que Qt l'aidera dans sa démarche d'apprentissage de la POO?)

Merci à vous.

Je suis déjà motivé, et si ça déchire après, ça sera encore plus de la balle

pas plus qu'une trotinette à réaction

yay, suffit de ça pour écrire la date !

    const time_t t = time(NULL);
    tm *s = localtime(&t);
    std::cout << s->tm_mday << "/" << s->tm_mon + 1 << "/" << s->tm_year+ 1900 << std::endl;

(cross -> ttk )

Tiens, je me pose une question, c'est le topic de Bob qui me fait penser à ça...

int main(int argc, const char **argv)

c'est bien joli, mais quelque soit l'encodage du système, je vais bien récupérer des caractères ascii dans mes char* ?
Je vais pouvoir les traiter un à un comme des octets ordinaires (ie au sens où j'y suis habitué sur TI) ?

tu vas récupérer ce qu'on te passe sur la ligne de commande, et ça dépend de l'encodage du shell, donc de la locale en cours, écrasée éventuellement par la variable d'env LANG.

# LANG=C ls

te renverra de l'ascii.

mais bon comme tu peux accéder à LANG grâce à getenv() et que tu a Saint GNU iconv © qui existe aussi dans Mighty Qt ©, tu peux décoder correctement la ligne de commande GNU/Linux © sans te poser de iSouci ©

mais fond de vérité quand même.

il me semble oui.
par contre, je ne sais pas si les accents passeront bien, car ils ne seront pas forcément passés avec le bon encodage à ton programme

ça dépend de la "locale", non?

Oué... et la portabilité Win avec toussah ? Je veux juste lire quelques switches bordel, j'espère que c'est pas la croix et la bannière...

(cross)

ok, on va tenter, puis exécuter sous Win et Linux pour faire des essais...

Windows, il te passe les arguments en UTF-16 avec le saint wchar_t... ou bien en ANSI avec le char tout moisi...
int wmain(int argc, wchar_t *argv[]);(Sinon on utilise _tmain et TCHAR avec Visual C++, qui se résout en main/wmain et char/wchar_t selon que t aies défini UNICODE ou non)
(PS: l'unicode c'est mieux)

ie si j'utilise wchat_t, j'aurai un comportement équivalent sous Win/*nix au niveau des caractères accentués ?

Hmm je sais pas trop...
Windows utilise de l'UTF-16LE, donc en conséquence Visual C++ propose un wmain avec des paramètres wchar_t en UTF-16, mais la taille du wchar_t dépend du système (à priori windows => 2 octets; unix => 4 octets), et je ne sais pas si tu as un équivalent du wmain sous un bête linux. ^^
Pour le reste normalement il y a les fonctions en w (genre wprintf) un peu partout dans la librarie C, donc ça *devrait* marcher de manière identique sur un système ou un autre. (j'avoue ne jamais avoir testé )

Ah oui, et tu dois pouvoir utiliser des wstring au lieu des string avec la STL, etc etc

roh put**n quelle zone, tout ça pour quelques mots

Nan mais si ça peut te rassurer ça a toujours été la merde la gestion des caractères en C du fait qu'on a toujours supposé qu'un char = 1 octet (utilisé à la place d'un type byte / uint8_t manquant).
En C++ avec STL c'est un peu moins la merde car les string sont censées te masquer ça (cf. le template toumoche™ que représente la déclaration de string).
Dans les langages récents le type char est opaque. Tu ne sais pas la taille qu'il a, et tu n'es pas censé faire des opérations arithmétiques dessus, même si c'est possible dans certains à coup de cast. Tu peux te donner les mêmes contraintes en C en faisant ton propre type CHAR, par contre du coup il ne faut plus utiliser les fonctions de la libc...

Ah, dire que si les grosses boîtes au début de l'informatique personnelle avaient été chinoises ou japonaises, on aurait jamais eu ces problèmes...