striiiiiiiiiiiiiiing - Page 14

à propos de ta question sur la taille de la pile, tu n'as pas à t'inquiéter. car même si tu déclares une string sur la pile, il n'y aura que quelques membres de la classe qui seront effectivement placé sur la pile, le contenu de la string sera lui alloué dynamiquement dans le tas. mais tout ça, c'est la classe string qui le gère en interne, tu n'as pas à te soucier de ces détails (comme beaucoup de choses quand tu fais de la programmation haut niveau, POO qui plus est )

et pour préciser pour la question sur les membres statique de ta classe Date, on ne peut accéder qu'aux membres statique avec l'operateur ::
pour les membres d'un objet, il faut un objet et les operateurs . ou ->

C'est que j'avais mal écrit, c'est corrigé depuis. Mais merci bien, je ne maitrise pas du tout la syntaxe encore

Concrètement, j'ai cette méthode, renvoie-t-elle bien la valeur privée de l'objet qui l'appelle ? (renvoi d'un objet Date, membre privé d'un objet de classe Contact)

Date Contact::getContactBirthDay()
{
    return BirthDay;
}

ben sans savoir ce que c'est que Birthday c'est dur à dire
mais a priori, ta méthode renvoie une copie du membre Birthday de la classe contact

sinon une petite remarque à propos des conventions de codage. je sais pas laquelle est utilisée dans ton bouquin, mais généralement c'est une bonne idée d'ajouter un préfixe ou un suffixe à toutes tes variables membres pour les différentier des variables locales et savori ce qui persiste entre plusieurs appels de la méthodes. au aussi de différencier les types et les variables ou methodes
la convention que moi et beaucoup de monde utilise :
variable membre : préfixe "m" (on trouve aussi beaucoup de "m_")
variables membre statiques : préfixe "ms"
type ou classe : commence par une majuscule
variable ou fonction : commence par une minuscule
tu fais comme tu veux, mais le plus important étant de différentier les membres du reste ^^

Bon parfait, Zephyr m'a dit tout à l'heure que c'était encore une fois une question de choix auquel se tenir, donc tout va bien. En fait, je fais comme toi, sauf pour le m_. Et c'est pas con, je me suis retrouvé avec un conflit de nom de variable : un constructeur qui prenait en argument une variable à laquelle j'avais évidemment donné le nom d'un membre, c'était logique.

Ben merci.

Oui, comme l'implémentation de la fonction l'indique, BirthDay est un objet Date.
Rah ça fait chier, je vois pas comment faire de l'héritage, du polymorphisme et des fonctions virtuelles dans ce que je fais, je dois sûrement pas assez voir "objet", ça fait bien suer

au boulot on nous obligeait méchamment à préfixer les variables locales par v (vLocal), champs par f (fTruc) les paramètres entrant par in (inParam) out (outParam) ou io (ioParam).

je peux plus m'en passer.

QString("%1 %2 %3").arg(Date:: Day).arg(Date::Month).arg(Date::Year)rulez. (Probablement moins rapide que les concaténations, mais plus pratique.)

tring:number(Date::Year)Sinon, la concaténation:QString s = QString:number(Date:: Day) + ' ' + QString:number(Date::Month) + ' ' + QS(Tu ne peux pas utiliser un nombre directement avec + parce que ça créerait des conflits avec l'addition de char à cause de la "default promotion" char→int du C++.)

aze (./391) :
à propos de ta question sur la taille de la pile, tu n'as pas à t'inquiéter. car même si tu déclares une string sur la pile, il n'y aura que quelques membres de la classe qui seront effectivement placé sur la pile, le contenu de la string sera lui alloué dynamiquement dans le tas. mais tout ça, c'est la classe string qui le gère en interne, tu n'as pas à te soucier de ces détails (comme beaucoup de choses quand tu fais de la programmation haut niveau, POO qui plus est )

Oui, mais quand tu passes une std::string par valeur, ça te recopie toute la chaîne. QString est beaucoup mieux pensée (la chaîne est aussi dans le tas, mais elle n'est recopiée que quand tu la modifies et la copie originale est toujours référencée).

Folco (./395) :
Rah ça fait chier, je vois pas comment faire de l'héritage, du polymorphisme et des fonctions virtuelles dans ce que je fais, je dois sûrement pas assez voir "objet", ça fait bien suer

Tu n'es pas obligé d'utiliser tout ça. Si ça ne sert pas dans ton cas concret, ne l'utilise pas! Ça ne sert à rien de faire de l'objet juste pour faire de l'objet. Personnellement, j'ai une manière de penser très procédurale et mon C++ ressemble beaucoup avec du C qui utilise les objets de Qt.

Kevin Kofler (./397) :
Sinon, la concaténation:QString s = QString:number(Date:: Day) + ' ' + QString:number(Date::Month) + ' ' + QString:number(Date::Year)(Tu ne peux pas utiliser un nombre directement avec + parce que ça créerait des conflits avec l'addition de char à cause de la "default promotion" char→int du C++.)

; QString s = QString() + Date:: Day + " " + Date::Month + " " + Date::YearNe fonctionne pas? Ca fait un moment que je n'ai pas fait de Qt, mais il me semble que je faisait des truc du genre.

Kevin Kofler (./398) :

Folco (./395) :
Rah ça fait chier, je vois pas comment faire de l'héritage, du polymorphisme et des fonctions virtuelles dans ce que je fais, je dois sûrement pas assez voir "objet", ça fait bien suer

Tu n'es pas obligé d'utiliser tout ça. Si ça ne sert pas dans ton cas concret, ne l'utilise pas! Ça ne sert à rien de faire de l'objet juste pour faire de l'objet. Personnellement, j'ai une manière de penser très procédurale et mon C++ ressemble beaucoup avec du C qui utilise les objets de Qt.

Tout a fais d'accord en tempos normal, je deteste les gens qui se sentent obligés de passer par des design pattern compliqué lorsque ce n'est pas nécessaire.

Sauf que la, il essaye d'apprendre le C++, donc ça parait normal qu'il cherche a expérimenter le concept qui fait toute la particularité de l'objet.

Ben en fait, j'ai failli faire un topic "TD de C++", où les connaisseurs auraient pu me balancer des exercices simples, m'obligeant à mettre en oeuvre ces différents mécanismes. Evidemment, sans expérience, je ne peux pas imaginer moi-même ce genre d'exercice...

(si tu veux j'ai encore quelques TD qui trainent, ça vaut ce que ça vaut mais je peux t'envoyer ça ce soir si ça t'intéresse)

Uther (./399) :

Kevin Kofler (./397) :
Sinon, la concaténation:QString s = QString:number(Date:: Day) + ' ' + QString:number(Date::Month) + ' ' + QString:number(Date::Year)(Tu ne peux pas utiliser un nombre directement avec + parce que ça créerait des conflits avec l'addition de char à cause de la "default promotion" char→int du C++.)

; QString s = QString() + Date:: Day + " " + Date::Month + " " + Date::YearNe fonctionne pas? Ca fait un moment que je n'ai pas fait de Qt, mais il me semble que je faisait des truc du genre.

Comme je viens d'expliquer, ça ne marche pas avec des nombres. (Il croit que tu veux ajouter des char.) Il faut utiliser QString::Number ou .arg().

Très sympa.

Etant déjà sur un projet (déjà, faut bien se lancer même si c'est casse gueule ^^), je ne sais pas si ça vaut le coup que t'y passes du temps (sauf si ça t'en prend vraiment peu, que t'as rien à scanner etc.. ). A voir en fonction de ta disponibilité/motivation/fatigue/toussa, mais merci beaucoup

Tiens, cette ligne de code ne veut pas compiler :
return {31,(Year%4 ? 28 : 29),31,30,31,30,31,31,30,31,30,31}[Month];
Ya pas une extension GNU quelconque permettant ça ?

Evidemment, décomposé, ça marche :

int Date::lastDay(int Month, int Year)
{
    int LastDayList[12] = {31,(Year%4 ? 28 : 29),31,30,31,30,31,31,30,31,30,31};
    return LastDayList[Month];
}

Essaie: return ((int[]){31,(Year%4 ? 28 : 29),31,30,31,30,31,31,30,31,30,31})[Month]; (mais je ne sais pas si g++ accepte ça, il n'accepte pas toutes les extensions que le frontend C accepte).

D'un autre côté je vais garder ma solution, je veux pas être dépendant d'un compilateur. Mais je note la forme employée.

Tiens, dans une fonction comme celle postée au-dessus (Date::lastDay), feriez-vous un passage des arguments (Month, Year) par référence ou par valeur ? Je n'ai rien à perdre avec des références, non ? N'étant pas encore au point, je ne sais pas trop quoi décider...

Par valeur, ça ne sert à rien de passer un int par référence! (Sauf si tu veux le modifier dans la fonction, mais … Il vaut mieux un pointeur dans ce cas, au moins comme ça tu vois que c'est une sortie et ça permet aussi de passer NULL si l'appelant n'a pas besoin de la valeur.)

Ok. Maintenant, j'ai un autre problème.

Je veux que mon constructeur de Date crée un objet appelé DATE_NULL, pouvant être comparé à des champs Date non-renseignés d'une autre classe.
Mais évidemment, je voudrais que cet objet DATE_NULL ne soit créé qu'une seule et unique fois, et non à l'instanciation de chaque objet.

Comment dois-je faire ? Déclarer mon objet DATE_NULL en static ? Il serait donc initialisé à la première construction d'une date, mais jamais dupliqué ? La méthode est bonne ?

[google]singleton object[/google] ? c'est pas tout a fait ce concept mais presque:

En gros tu fais ton instance et tu la stockes dans un champ statique uniquement si ce champ vaut null.

en pseudo c++
class date {
private:
static date the_undefined_one = null;
};

date date::getUndefinedDate() {
if ( date::the_undefined_date == null) {
date::the_undefined_date = new date(komifo);
}
return date::the_undefined_date;
}

il faut le déclarer en static et l'initilaliser dans directement dans le fichier[nosmile]

// .h
class Date
{
public:
  Date(args);
  static const DATE_NULL;
};

// .cpp
const Date::DATE_NULL = Date(args);
Date::Date(args)
{
  /*...*/
}

la variable DATE_NULL sera initialisée au lancement de ton application, avant d'entrer dans la fonction main()
et ensuite tu accèdes à ton objet avec Date:ATE_NULL

ah c'est mieux, je suis décidément trop javaïen

Ah ok !!!

Vu que c'est static, c'est en effet initialisé au démarrage du programme, donc pas besoin que ce soit appelé par un constructeur.
Génial, merci !

Et je vais me pencher sur cette histoire de singleton (pour moi, c'était quand j'avais qu'une carte dans une couleur donnée au bridge )

le singleton c'est quand on veut créer absolument une unique instance de chaque classe, mais pas utiliser des static partewt.

on rend le constructeur private, on garde un champ statique, et une méthode get() qui initialise le champ statique au premier appel, et renvoie toujours le contenu de ce champ.

Si ton objet Date était implicitement partagé, une date nulle serait tout simplement une date avec le d-pointer (ton QSharedDataPointer) nul, c'est comme ça que fonctionne QDate, par exemple. Ensuite, on peut toujours créer un null statique (cf. par exemple QString::null), mais ce n'est pas nécessaire.

avec des si on mettrait Vienne en citerne.

il veut, point barre. il étudie.

Attends, ça me donne déjà une idée de comment procède Qt, sachant que j'ai dit que c'est ce à quoi je voulais arriver. Donc je prends, meric bien.

J'y arrive toujours pas :/

Dans mon header de classe, j'ai déclaré ça :
static const Date DATE_NULL;
C'est bien une déclaration de variable de type Date et de nom DATE_NULL ?
Et dans l'implémentation (cpp), j'ai écrit ça :
static const Date DATE_NULL;
C'est pas l'implémentation d'une Date de nom DATE_NULL, initialisée par le constructeur Date:ate() ?

Pourquoi ça marche pas ?!? Je comprends plus...

Dans les fichiers qui l'utilisent, j'ai inclus date.h, mais il me dit que DATE_NULL n'a pas été déclarée dans ce scope.

ça ne marche pas parceque tu n'as pas recopié correctement mon ./411
[nosmile]
pour l'en-tête, c'est bon. par contre pour l'implémentation il faut enlever le "static", qui ne sert qu'à dire à la classe que ce champ n'est pas à instancier à chaque fois, mais à chercher la variable globale Date:ATE_NULL. le static ne sert plus dans l'implémentation (enfin il doit avoir el même sens qu'en C, c'est à dire local au fichier, ce qui n'est pas ce que tu veux)
ensuite il ne faut pas oublier le Date:: car là tu déclares une variable globale de type Date qui s'appelle DATE_NULL, pas un membre statique de la classe Date. Le linker lui va continuer de chercher Date:ATE_NULL et ne pas la trouver

Ah... J'avais mal compris cette différence entre membre static de la classe et variable globale, merci bien.

ps -> j'essaye de comprendre le principe et de refaire derrière, donc pas de recopier bêtement, spour ça. Et en revenant sur ton post, j'ai pas vu là où je m'étais trompé, à cause de cette confusion justement. Merci bien, maintenant j'ai compris.