Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C++ Probleme de compilation avec un constructeur

Probleme de compilation avec un constructeur

16 réponses
Avatar
Jude
Bonjour

Pour une classe bigint (exo de td d'info scolaire)
je voudrais realiser un constructeur comme celui ci
Un bigint possede un entier taille et un vecteur Nt

BigInt::BigInt(string chaine) {

taille=chaine.size();

Nt=vector<int>(taille-1);

for(int i=taille-1;i<0;i--) {
Nt[taille-i]=chaine[taille-i+1]-'0';
}
}

Le but serait de rentrer les differents caracteres de chaine dans Nt

Le probleme est :

bigint.cc:23: error: le C++ ISO interdit la définition de types à
l'intérieur
de return type
bigint.cc:23: error: return type specification for constructor invalid

Voilà si vous voyez l'erreur, ou s'il vous faut plus de renseignements,
je vous remercie dejà pour votre reponse.

--
Jude
Pas très bon, mais debutant
Signaler un problème avec ce contenu

6 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2
Avatar
Samuel Krempp
le Monday 04 April 2005 09:37, écrivit :
Pourrais-tu citer une référence ? J'ai jetté un oeil et n'ai
rien trouvé.


Je ne sais pas où le chercher dans la norme C++ non plus.

Dans la norme C, §5.2.1/3, on a « In both the source and
execution basic character sets, the value of each character
after 0 in the above list of decimal digits shall be one greater
than the value of the previous. » Je ne trouve pas où on le dit
dans la norme C++, mais je ne crois pas que l'intention était
d'être différent de C ici. (Au moins, cette différence
n'apparaît pas dans l'appendice C.1.)


qd j'ai eu besoin de cette garantie, j'ai écrit dans mes notes :
22.2.1.1.2/13
In addition, for any digit character c, the expression
(do_narrow(c,dfault)?-0?) evaluates to the digit value of the character.

--
Sam


Avatar
Samuel Krempp
le Sunday 03 April 2005 19:57, écrivit :


BigInt::BigInt (string const& chaine) {
for (string::const_iterator i= chaine.begin(); i ! >>> chaine.end(); ++i)
{
chiffres.push_back (*i - '0'); // même remarque sur "
-'0' ".
}
}



Oui vous avez raison de vouloir discuter sur le -'0' car cela ne marche
pas (une indication de notre prof d'info).
Je cherche en fait juste a vouloir convertir en un entier le caractere
contenue dans ma chaine.
Il y a t'il une commande speciale?


Si votre prof vous a dit que ça ne marchait pas sans vous en dire plus,
c'est sans doute qu'il s'attend à ce que vous fassiez ça en exercice.
Aussi, réfléchissez-y, ça n'a rien de difficile, de faire une fonction
qui prend un char en paramètre et qui renvoye l'entier int correspondant.


ben.. il n'y a pas d'autre moyen. bon, on peut ajouter un narrow sur *i,
pour reconnaître comme chiffre d'éventuels caractères locaux en plus de
'0'-'9', mais c'est un détail - et ce n'est pas forcément désirable.
dans le fond il n'y a pas d'autre moyen que c-'0'.

Peut-être le prof pensait que c'était une bidouille, et qu'il attend plutôt
une utilisation de stringstream pour convertir la chaine en entier. Mais de
toute façon c'est justement ce que fera l'extraction vers entier du
stringstream..

--
Sam



Avatar
Samuel Krempp
le Saturday 02 April 2005 23:06, écrivit :

Nt=vector<int>(taille-1);
// J'ai de gros doutes sur le "-1"

for(int i=taille-1;i<0;i--) {


et aussi de gros doutes sur le 'i<0' :)

--
Sam

Avatar
kanze
Samuel Krempp wrote:
le Monday 04 April 2005 09:37, écrivit :
Pourrais-tu citer une référence ? J'ai jetté un oeil et
n'ai rien trouvé.


Je ne sais pas où le chercher dans la norme C++ non plus.

Dans la norme C, §5.2.1/3, on a « In both the source and
execution basic character sets, the value of each character
after 0 in the above list of decimal digits shall be one
greater than the value of the previous. » Je ne trouve pas
où on le dit dans la norme C++, mais je ne crois pas que
l'intention était d'être différent de C ici. (Au moins,
cette différence n'apparaît pas dans l'appendice C.1.)


qd j'ai eu besoin de cette garantie, j'ai écrit dans mes notes :
22.2.1.1.2/13
In addition, for any digit character c, the expression
(do_narrow(c,dfault)?-0?) evaluates to the digit value of the
character.


Intéressant. J'avoue que ce n'est vraiement pas dans §22 que je
serais allé chercher une information sur des contraintes de
l'implémentation du compilateur:-). Mais au moins, l'auteur de
ces lignes croyait que la garantie explicite de la norme C
valait pour C++ aussi.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34



Avatar
Samuel Krempp
le Monday 04 April 2005 15:21, écrivit :
Intéressant. J'avoue que ce n'est vraiement pas dans §22 que je
serais allé chercher une information sur des contraintes de
l'implémentation du compilateur:-).


c'est une contrainte sur les charsets, et puisque ça s'applique à toute
locale je trouve pas ça si surprenant que ça apparaisse au chapitre des
locales (comme is_digit d'ailleurs).

Par contre c'est vrai que pour le 'basic source character set', cette
garantie n'est pas donnée dans §2.2, et il faut penser à l'obtenir par
déduction des propriétés des locales et de leur interaction avec le basic
charset.

Mais au moins, l'auteur de
ces lignes croyait que la garantie explicite de la norme C
valait pour C++ aussi.


ils ont peut être choisir de ne pas (ré-)exprimer la garantie au paragraphe
§2.2 par souci de minimalisme ? (et d'obfuscatisme aussi :)

--
Sam

Avatar
kanze
Samuel Krempp wrote:
le Monday 04 April 2005 15:21, écrivit :
Intéressant. J'avoue que ce n'est vraiement pas dans §22 que
je serais allé chercher une information sur des contraintes
de l'implémentation du compilateur:-).


c'est une contrainte sur les charsets,


Plus ou moins. Tel que c'est présenté, c'est surtout une
contrainte sur le resultat de la fonction do_narrow.

et puisque ça s'applique à toute locale je trouve pas ça si
surprenant que ça apparaisse au chapitre des locales (comme
is_digit d'ailleurs).


Je ne trouve pas étonnant qu'il y a des contraintes sur des jeux
de caractères introduits par les locales. Je ne trouve rien
d'anormal que cette phrase s'y situe. Ce que je ne trouve pas
normal, c'est qu'il n'y a pas de réstrictions au niveau du
langage (sections 1 à 16) sur la représentation des caractères
de base. D'autant plus que la norme C en comporte une, claire et
nette. Alors, je ne sais pas si la différence est exprès (et que
l'auteur de la section 22 n'a pas été informé du changement, ou
ne s'en est pas aperçu), ou si ce n'est qu'un oubli. Le texte
dans §2.2 a l'air d'avoir été bien rémanié par rapport au texte
dans la norme C. Selon l'humeur, on peut penser :

-- avec tant de rémaniement, c'est facile à oublier quelque
chose, ou

-- il y a quand même une liste assez courte et simple des
contraintes ; si une en manque, ça doit être exprès.

(Dans la pratique, évidemment, ça doit être extrèmement rare de
nos jours d'avoir à faire à un jeu de caractères qui n'est pas
basé sur ASCII, et la seule exception que je vois, c'est
l'EBCDIC. La risque de ne pas trouver les chiffres contigus et
dans l'ordre est donc quasi null.)

Par contre c'est vrai que pour le 'basic source character
set', cette garantie n'est pas donnée dans §2.2, et il faut
penser à l'obtenir par déduction des propriétés des locales et
de leur interaction avec le basic charset.


Tout à fait. Or, c'est bien dans §2.2 qu'on élicide des
contraintes sur les « basic character set » (source ou
execution).

Mais au moins, l'auteur de ces lignes croyait que la
garantie explicite de la norme C valait pour C++ aussi.


ils ont peut être choisir de ne pas (ré-)exprimer la garantie
au paragraphe §2.2 par souci de minimalisme ? (et
d'obfuscatisme aussi :)


Je n'y crois pas. Il y a malgré tout une assez nette séparation
entre la bibliothèque et le langage de base. La section 22
spécifie surtout le comportement des locales, et non des
caractèristiques du langage de base. Je ne crois pas qu'il soit
l'intention de qui que ce soit d'introduire des contraintes sur
la langage dans les sections de la bibliothèque, simplement par
le biais qu'il serait impossible d'implémenter la bibliothèque
si ces contraintes n'existaient pas.

Je pars donc du principe que l'auteur de ce passage croyait que
la contrainte existait dans le langage de base, et que son but
était d'étendre la contrainte aux resultats de do_narrow.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34


1 2