Compilation de classe : erreur constructeur : "expected `)' before '=' token"

Version imprimable

Bonjour,

Je tente de compiler une classe d'envoi d'emails via utilisation d'un socket.

J'ai cependant ce message d'erreur lors de la compilation :

Citation:

expected `)' before '=' token

, à la ligne où je déclare le constructeur de ma classe :

Code:

Mail(ipSMTP="serveurmail.com", port=25)

Je suspecte que le problème vienne des deux attributs de type string déclarés avant la méthode init de la classe :

Voici le contenu de mail.h contenant la classe Mail :

Code:

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
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
 
#if defined (WIN32)
    #include <winsock2.h>
    typedef int socklen_t;
#elif defined (linux)
    #include <sys/types.h>
    #include <sys/socket.h>
    #include <netinet/in.h>
    #include <arpa/inet.h>
    #include <unistd.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;
#endif
 
#include <string>
#include <iostream>
 
 
using namespace std;
 
class Mail
{
      private :
 
      public :
             SOCKET sock;
             SOCKADDR_IN sin;
             char buffer[255];
             int erreur;
             int port;
             string message;
             string ipSMTP;
 
              Mail(ipSMTP="serveurmail.com", port=25)
              {
                   #if defined (WIN32)
                    WSADATA WSAData;
                    erreur = WSAStartup(MAKEWORD(2,2), &WSAData);
                     #else
                        erreur = 0;
                     #endif
 
                   message = "";
 
                   /* Création de la socket */
                    sock = socket(AF_INET, SOCK_STREAM, 0);
 
                    /* Configuration de la connexion */
                    sin.sin_addr.s_addr = inet_addr(ipSMTP.c_str());
                    sin.sin_family = AF_INET;
                    sin.sin_port = htons(port);
              }
 
              ~Mail()
              {
                   /* On ferme la socket précédemment ouverte */
                        closesocket(sock);
 
                        #if defined (WIN32)
                            WSACleanup();
                        #endif
              }
 
              void envoi()
              {
                   //Instructions d'envoi d'email par la socket via le SMTP
              } 
};

Merci d'avance de votre aide !

Niusha

14/12/2011, 15h35
dragonjoker59
Tu te trompes en fait sur la manière d'utiliser un constructeur.
Effectivement ça sert à initialiser les valeurs des membres de la classe, mais tu t'y prends très mal.
Tu peux te faire un constructeur par défaut :
Code:

1 2 3 4 5 Mail() : ipSMTP( "serveurmail.com" ) // Initialisation des membres , port( 25 ) { }
Tu peux aussi faire un constructeur spécifié :
Code:

1 2 3 4 5 Mail( string const & p_ipSmtp, int p_port) : opSMTP( p_ipSmtp ) , port( p_port ) { }

Euh si c'est possible ?

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
#include <string>
 
class Mail
{
private :
	int _port;
	std::string _ipSMTP;
public :
	Mail(const std::string& ipSMTP="serveurmail.com", int port=25)
	: _ipSMTP(ipSMTP), _port(port)
	{
	} 
};
 
int main() 
{
	Mail m ;
	Mail m2("server", 123 );
}

Citation:

Envoyé par themadmax

Euh si c'est possible ?

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
#include <string>
 
class Mail
{
private :
	int _port;
	std::string _ipSMTP;
public :
	Mail(const std::string& ipSMTP="serveurmail.com", int port=25)
	: _ipSMTP(ipSMTP), _port(port)
	{
	} 
};
 
int main() 
{
	Mail m ;
	Mail m2("server", 123 );
}

Oui merci ta solution fonctionne ! Voici mon code après modification :

Code:

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
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
class Mail
{
      private :
 
      public :
             SOCKET sock;
             SOCKADDR_IN sin;
             char buffer[255];
             int erreur;
 
             string message;
 
             string _ipSMTP;
             int _port;
 
             Mail(const string& ipSMTP="localhost", int port = 25)
                        : _ipSMTP(ipSMTP), _port(port)
             {
                   #if defined (WIN32)
                    WSADATA WSAData;
                    erreur = WSAStartup(MAKEWORD(2,2), &WSAData);
                     #else
                        erreur = 0;
                     #endif
 
 
                   // Création de la socket 
                    sock = socket(AF_INET, SOCK_STREAM, 0);
 
                    cout << "Creation de la socket. Serveur = " << ipSMTP.c_str() << "\n";
                    // Configuration de la connexion /
                    sin.sin_addr.s_addr = inet_addr(ipSMTP.c_str());
                    sin.sin_family = AF_INET;
                    sin.sin_port = htons(port);
             }
 
              ~Mail()
              {
                   /* On ferme la socket précédemment ouverte */
                        closesocket(sock);
 
                        #if defined (WIN32)
                            WSACleanup();
                        #endif
              }

14/12/2011, 17h01
themadmax
Je ne peux me retenir, il ne faut quasiment jamais utilisé de membre public.
Ben oui mais pourquoi?
Un exemple tu fais une classe avec un membre idx, tu l'utilise dans 147 de ton programme, et puis le client te dit mais moi je suis pas développeur mes index ne débute pas à 0 mais à 1. Soit tu fais 147 +1 dans ton code, mais la tu est tres con, soit tu change dans l'initialisation de l'index, mais dans ton code sa risque de mal se passer. Soit tu as fait un acceseur, et c'est trop de la bombe de balle et tu fait :
Code:

1 2 3 4 5 6 7 8 class Bidon { private: int _idx ; public: int getIdx() const { return _idx+1; } //c beau non ? void setIdx(int idx) { _idx = idx - 1 ; } };
14/12/2011, 17h34
niusha
Citation:
Envoyé par themadmax

Je ne peux me retenir, il ne faut quasiment jamais utilisé de membre public.
Ben oui mais pourquoi?
Un exemple tu fais une classe avec un membre idx, tu l'utilise dans 147 de ton programme, et puis le client te dit mais moi je suis pas développeur mes index ne débute pas à 0 mais à 1. Soit tu fais 147 +1 dans ton code, mais la tu est tres con, soit tu change dans l'initialisation de l'index, mais dans ton code sa risque de mal se passer. Soit tu as fait un acceseur, et c'est trop de la bombe de balle et tu fait :

Code:

1 2 3 4 5 6 7 8 class Bidon { private: int _idx ; public: int getIdx() const { return _idx+1; } //c beau non ? void setIdx(int idx) { _idx = idx - 1 ; } };
Oui je suis d'accord avec toi concernant la portée des attributs, ici je n'ai pas chercher à réfléchir mais effectivement je vais les passer en private ou protected et créer des getter et setter en cas de besoin.
14/12/2011, 18h36
koala01

Salut,

Citation:

Envoyé par niusha

Oui je suis d'accord avec toi concernant la portée des attributs, ici je n'ai pas chercher à réfléchir mais effectivement je vais les passer en private ou protected et créer des getter et setter en cas de besoin.

Cette réflexion montre sans doute que tu as une très mauvaise idée de la manière de concevoir ton application d'un point de vue orienté objet...

Tu sembles concevoir tes classes en fonction des membres qui les composent.

Si c'est un point de vue on ne peut plus correct en conception "non orienté objet", c'est, malheureusement un point de vue totalement erroné (j'aurais meme tendance à dire "obsolète") lorsqu'il est question de concevoir une application dans une optique orientée objet.

En effet, l'idée même de la conception orientée objet est de ne plus réfléchir en termes de donnée utilisées, mais en termes des services que tu peux attendre de la part des différentes classes que tu envisages d'utiliser.

Les données membres ne doivent donc plus être envisagées sous la forme de l'ensemble des données qu'il faut utiliser pour représenter un type particulier, mais bien comme ce qui es nécessaire pour permettre à ta classe de fournir les services au tu en attends.

En respectant ce principe, on se rend compte que l'utilisation d'accesseurs ou de mutateurs devient tout à fait marginale, la plupart des services offerts par la classes en prenant facilement la place ;)

Si tu respecte ce principe, et que tu respectes, en parallèle, le principe de la responsabilité unique, tu te rends compte que le fait de connaitre le serveur POP ou SMTP (ou le port sur lequel se connecter au serveur) ne fait pas partie des services que tu es en droit d'attendre de ta classe mail.

Cette responsabilité devrait échoir à... la classe qui devra soit récupérer les mails soit les envoyer ;)

La moralité de cette histoire, c'est : commence par déterminer exactement quelle responsabilité tes classes doivent avoir, en veillant à ce qu'elle reste unique, détermine ensuite les services que tu es en droit d'attendre de ces classes.

Les données qui permettront à tes classes de fournir les services attendus "tomberont" alors sous le sens, et ton design n'en sera que meilleur ;)
15/12/2011, 11h48
niusha

Citation:

Envoyé par koala01

Salut,Cette réflexion montre sans doute que tu as une très mauvaise idée de la manière de concevoir ton application d'un point de vue orienté objet...

Tu sembles concevoir tes classes en fonction des membres qui les composent.

Si c'est un point de vue on ne peut plus correct en conception "non orienté objet", c'est, malheureusement un point de vue totalement erroné (j'aurais meme tendance à dire "obsolète") lorsqu'il est question de concevoir une application dans une optique orientée objet.

En effet, l'idée même de la conception orientée objet est de ne plus réfléchir en termes de donnée utilisées, mais en termes des services que tu peux attendre de la part des différentes classes que tu envisages d'utiliser.

Les données membres ne doivent donc plus être envisagées sous la forme de l'ensemble des données qu'il faut utiliser pour représenter un type particulier, mais bien comme ce qui es nécessaire pour permettre à ta classe de fournir les services au tu en attends.

En respectant ce principe, on se rend compte que l'utilisation d'accesseurs ou de mutateurs devient tout à fait marginale, la plupart des services offerts par la classes en prenant facilement la place ;)

Si tu respecte ce principe, et que tu respectes, en parallèle, le principe de la responsabilité unique, tu te rends compte que le fait de connaitre le serveur POP ou SMTP (ou le port sur lequel se connecter au serveur) ne fait pas partie des services que tu es en droit d'attendre de ta classe mail.

Cette responsabilité devrait échoir à... la classe qui devra soit récupérer les mails soit les envoyer ;)

La moralité de cette histoire, c'est : commence par déterminer exactement quelle responsabilité tes classes doivent avoir, en veillant à ce qu'elle reste unique, détermine ensuite les services que tu es en droit d'attendre de ces classes.

Les données qui permettront à tes classes de fournir les services attendus "tomberont" alors sous le sens, et ton design n'en sera que meilleur ;)

Merci pour ces conseils, je vous montrerai le résultat final à l'occasion :)