striiiiiiiiiiiiiiing - Page 17

Ah oui, je me demandais aussi, même si j'ai pas relevé en tout cas, j'ai pas vu ça dans mon handbook

Sisi ça existe, c'est pour les conversions implicites. Tu peux utiliser n'importe quel type d'ailleurs.

Même un type non basique ?
Genre si j’écris quelque part « class MaClasse {}; » J’ai le droit d’écrire ailleurs « class MonAutreClasse { MaClasse operator MaClasse { return Maclasse(); } }; » ?

Il semblerait que oui : http://en.wikipedia.org/wiki/Operators_in_C_and_C++#Other_operators

Ah, j'ai trouvé comment faire de l'héritation, j'ai besoin de deux styles de dates : celles spécifiant des années, et les autres non. gnakgnakgnak

D'ailleurs, question (forcément ).

J'ai deux méthodes privées dans la classe que je veux dériver. La classe dérivée pourra-t-elle les utiliser ?

-> protected

Folco (./485) :
J'ai deux méthodes privées dans la classe que je veux dériver. La classe dérivée pourra-t-elle les utiliser ?

Les méthodes "private" non,
Si tu veux des méthode non publiques mais accessible pour les classes qui en héritent, il les faut "protected"

Ah oui c'est vrai, merci.

Folco (./468) :
Mais que devrais-je avoir comme type de classe ?

La classe américaine pardi !

Tiens, j'ai des warnings de ce genre (j'ai activé tous les warnings possibles jusqu'à --pedantic) :

||=== Anniv, Release ===|
||=== Anniv, Release ===|
/mnt/Data/Programmation/PC/Anniv/contact.cpp||In constructor ‘Contact::Contact()’:|
/mnt/Data/Programmation/PC/Anniv/contact.cpp|15|warning: ‘Contact::m_firstname’ should be initialized in the member initialization list|
/mnt/Data/Programmation/PC/Anniv/contact.cpp|15|warning: ‘Contact::m_lastname’ should be initialized in the member initialization list|
/mnt/Data/Programmation/PC/Anniv/contact.cpp|15|warning: ‘Contact::m_birthday’ should be initialized in the member initialization list|
/mnt/Data/Programmation/PC/Anniv/contact.cpp|15|warning: ‘Contact::m_celebration’ should be initialized in the member initialization list|
/mnt/Data/Programmation/PC/Anniv/contact.cpp|15|warning: ‘Contact::m_mariage’ should be initialized in the member initialization list|

Pourquoi ? Mon constructeur est écrit comme ça :

    Contact::Contact()
{
    std::string s;
    Date d;
    DateYear dy;

    m_firstname = s;
    m_lastname = s;
    m_birthday = dy;
    m_celebration = d;
    m_mariage = dy;
}

Et voici les constructeurs sans arguments de Date et DateYear :

Date::Date()
{
    m_day = 0;
    m_month = 0;
}

DateYear::DateYear()
{
    m_day = 0;
    m_month = 0;
    m_year = 0;
}

Tout me semble parfaitement initialisé, même si les valeurs ne veulent rien dire (mais sont gérées en tant que dates nulles par les autres méthodes). Le 'Date d', et 'DateYear dy' appellent bien les constructeurs par défaut, initialisant tous les membres, non ?

Je n'ai pas défini de constructeur d'affectation (Date:ate(const & Date)), c'est pour ça ? Mais alors, quel est le mécanisme de ce qui se passe ici ? Et j'ai les mêmes warnings pour mes autres constructeurs par défaut Date() et DateYear()...[nosmile]

Non, ce qu'il veut dire c'est que tu devrais initialiser tes membres comme ça :

Contact::Contact() : m_firstname(), m_lastname(), m_birthday(), m_mariage()
{ 
}

car quand tu les initialises dans le corps du constructeur au lieu de les initaliser comme au dessus (la member initalization list), tes membres sont d'abord construits avec le construsteur sans paramètres PUIS affectés avec la valeur que tu leurs passe dans le corps du constructeur
avec la liste d'initialisation tu fais tout en une fois.

mais dans ton exemple, ça ne sert à rien car tu leur passe déjà leur valeur par défaut (s, d et dy). Tu peux virer les lignes d'initialisation ça fera pareil.
C'est utile si tu veux préciser des paramètres du constructeur :

class A
{
public:
  A() : m_nombre(42), m_pointeur(NULL), m_classeB(blah)
  {
  }
private:
  int m_nombre;
  int* m_pointeur;
  B m_classeB;
};

cependant, pour des types de base (nombre ou pointeur qu'il faut initialiser explicitement), ça ne change rien au niveau perf de faire ça dans la liste d'init ou dans le corps du constructeur

Ok ! Dans un tuto, je vois que ce n'est qu'une autre forme d'écriture...

Donc j'ai écris la liste pour mes constructeurs par défaut, et en effet je n'ai plus de problème.

Par contre, j'ai des constructeurs qui travaillent sur les valeurs passées, je les initialise quand même à 0, même si la valeur sera autre par la suite ?
Genre ça :

Date:: Date(int day, int month)
{
    m_day = 0;                                  // init values
    m_month = 0;

    if ((day == 0) && (month == 0))             // return if its a null date
        return;

    if ((month >= 1) && (month <= 12))          // check month first, it must be valid for lastDay()
        m_month = month;
    else
        throw (DateException("Mois invalide"));

    if ((day >= 1) && (day <= lastDay(month)))
        m_day = day;
    else
    {
        m_month = 0;                            // error, reset month
        throw (DateException("Jour invalide"));
    }
}

Parce que j'ai le même warning...

Et FIXME sur un truc :
Quand les paramètres sont invalides, je lance une exception. Mais l'objet sera-t-il construit au final ? Je prends soin de mettre à 0 les membres, c'est peut-être complètement inutile ?

Et merci !

Non il ne sera pas construit.

oui, l'objet ne sera pas construit, donc son constructeurdestructeur ne sera jamais appelé (on pourrait penser que si une exception a lieu dans le constructeur, le destructeur est appelé juste après, mais non)


ton constructeur peut donc être écrit comme ça :

Date:: Date(int day, int month) : m_day(day), m_month(month)
{
  if(month != 0 && day != 0)
  {
    if ((month < 1) || (month > 12))          // check month first, it must be valid for lastDay()
        throw (DateException("Mois invalide"));

    if ((day < 1) || (day > lastDay(month)))
        throw (DateException("Jour invalide"));
  }
}

(edit : oups lapsus constructeur/destructeur)

Cool. Donc trop de précautions, je vire ça. Merci. je vais gagner au moins 20 octets


Merci beaucoup pour vos explications, chaque fois j'y vois plus clair.

Par contre, il me semble que le destructeur des variables membres déjà construites est appelé (je rappelle au passage que le destructeur d'un pointeur nu ne fait rien).

si l'exception est lancée dans le corps du constructeur, ce sont les destructeurs de tous les membres qui seront appelés, car tous les membres ont déjà été construits. Par contre si tu as des membres pointeurs, ce sont les pointeurs qui sont construits/détruits, ce qui veut dire qu'il faut que tu fasses le delete toi même
si l'exception est lancée par l'un des constructeur du member intialisation list, en effet, ce ne sont que les membres construits jusque là (et pas celui qui a balancé l'exception) qui seront détruits

Link> tu voulais dire "pointeur nul", je suppose ?

Non, je voulais bien dire "pointeur nu", dans le sens de "pointeur bête", ou "pointeur non-intelligent".

ok, je pensais au cas "p=NULL;delete p;" qui est prévu par le standard et qui ne fait rien ^^

Y at-t-il un moyen officiel d'accéder à la date/heure du système en C++ ? Si possible, un moyen portable nix/Win, ça serait parfait.

http://www.cplusplus.com/reference/clibrary/ctime/

(t'as aussi un truc qui s'appelle Google hein ^^)

tu as tout bêtement les fonctions de la libc, time et localtime (faut inclure ctime au lieu de time.h)
sinon en c++ tu as boost.date_time. les fonctions de boost sont toujours très très puissantes mais pas toujours faciles à utiliser (téléchargement et il faudra que tu les compiles toit même, ça peut être relou)
commence déjà avec ctime

Ah ben cool, je pensais pas que c'était fait ainsi simple
Je pensais avoir une lib tierce partie à utiliser...

QDateTime::currentDateTime()

QRoue::reinventer() ?

Pas vraiment, étant donné que l'implémentation repose sur les fonctions système. Mais il y a aussi: les millisecondes, avec les APIs par plateforme (time, prévu dans le standard C, ne donne que les secondes), l'utilisation automatique de localtime et le stockage du tout dans une classe pratique à utiliser.

Zerosquare (./505) :
QRoue::reinventer() ?

C'est un peu le principe de Qt, de réinventer la roue. Mais au moins il le fait bien.

Ca a ces avantages : tu peux réaliser la plupart des programmes en n'investissant dans l'apprentissage que d'une seule bibliothèque, même si c'est vrai que c'est dommage quand ca vient en concurrence des standards.

Sinon, il y a aussi KDateTime::currentUtcDateTime, KDateTime::currentLocalDateTime et KDateTime::currentDateTime(const KDateTime::‍Spec &spec).

(Comme d'habitude, KDE étend Qt avec des fonctionnalités supplémentaires. KDateTime utilise QDateTime en interne.)

Folco va être super content de dépendre de 100 Mo de libs

Et surtout d'un OS non realtime, lui à qui ça a l'air de tant tenir à coeur