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++ Initialisation de variable (!)

Initialisation de variable (!)

23 réponses
Avatar
Aurélien REGAT-BARREL
Hello à tous,
Je ne comprends pas pourquoi dans l'exemple suivant b3 est considéré comme
la déclaration d'un prototype de fonction (VC++ 7.1, MingW 3.3.1), d'autant
plus que b2 est valide.

class A
{
public:
A( int ) {}
};

class B
{
public:
B( A a1, A a2 ) {};
};

int main()
{
int i1 = 0;
int i2 = 0;

A a1( 0 );
A a2( 0 );

B b1( a1, a2 );
B b2( A( 0 ), A( 0 ) );
// warning C4930 : 'B b3(A,A)' : fonction prototypée non appelée
// (était-ce la définition de variable souhaitée ?)
B b3( A( i1 ), A( i2 ) );
}

La suite du programme montre bien que b3 est considéré comme une fonction.
Merci.

--
Aurélien REGAT-BARREL
Signaler un problème avec ce contenu

3 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 3
Avatar
Aurelien REGAT-BARREL
J'appelle bien du .Net depuis du C++ non ?


Ce n'est pas du C++, mais du C++ managé. Il comporte des mots clefs
spécifique, et doit être compilé avec le flag /clr.


Oui. Je pense que ça dépend de ce que tu recherches. Je me suis placé dans
l'optique "voilà j'ai une appli qu'on développe depuis 5 ans en C++, on veut
passer à .Net, mais on aimerait bien ne pas tout devoir redévelopper d'un
coup". Donc, dans ton projet, tu utilises .Net, faut juste recompiler tout
le projet avec /clr.
J'avais pas pensé à "je veux utiliser directement du .Net comme si ça n'en
n'était pas, je veux rester en C++ non managé". A peu de choses près c'est
comme demander à appeler du Java, du Python, ... directement. Il faut un
wrapper quelque part. Là Managed C++ te génère seul le wrapper, t'as pas à
utiliser SWIG ou JNI. Tu recompiles en /clr certes, mais ça change pas grand
chose, ton code non managé reste non managé.

Maintenant, ce que je voudrait, c'est plutôt ce genre de situation :

#include <dotnet.h>
#include <string>
#include <iostream>

int main()
{
std::string s( "coucou" );
std::cout << s << " avec coutn";

// Ici, éventuellement quelquechose du style
// DotNet::LoadMSILInterpreter();
System::Console::Write( s );
System::Console::WriteLine( " avec System::Console" );
return 0;
}


Ce n'est pas pur caprice. Nous avons du code non managé existant, que nous
voulons majoritairement portable. Et nous voudrions dans une des couches
basses de ce code faire appel à des fonctions managées (le remoting.NET).
Recompiler tout notre code (y compris le code d'autres bibliothèques, dont
nous n'avons pas les sources, mais qui utilisent des callback sur des
fonctions de notre code) en /clr, simplement pour en avoir un petit bout
qui fasse appel à des fonctions managées semble excessif...


Tout à fait. Faut te faire un module à part qui fait office de wrapper. Un
truc du genre:

// dotnet.h
void ConsoleWrite( const std::string & );

// dotnet.cpp
#using <mscorlib.dll>

void ConsoleWrite( const std::string & S )
{
Systemm::Console::Write( S.c_str() );
}

Pour info ne pas mettre le S devant les strings passées à .Net:
System::Console::WriteLine( " avec System::Console" );

au lieu de
System::Console::WriteLine( S" avec System::Console" );
ça marche, c'est juste que tu te paye la génération d'un wrapper avec
marshaling de ton char * en __wchar_t __gc[].

Je suis prèt à appeler toutes les fonctions de bibliothèque nécessaires,
mais souhaite le faire depuis un code C++ standard.


C++ CLI va visiblement plus dans ce sens. Sutter a fait la comparaison que
- Managed C++ = C++ + CLI
- C++ CLI = C++ x CLI
Apparement il travaille sur une meilleure intégration avec la STL. Y'a un
namespace stdcli dans ses exemples mais j'ai pas trouvé beaucoup d'infos
dessus.
#using <mscorlib.dll> a disparu aussi, mais pas vraiment en fait. C'est
juste une astuce comme on les aime bien, comme ça doit être placé en début
de tout fichier compilé avec /clr, ben il se sont dit que le fait de
compiler en /clr ferait désormais un #using <mscorlib.dll> implicite et donc
plus besoin de l'écrire.
Le code suivant compile avec VC++ 2005:

using namespace System; // pour Console
using namespace stdcli::language; // pour array

void main()
{
array<int>^ v = gcnew array<int>( 10 );
for ( int i = 0; i < v->Length; ++i )
{
Console::Write( v[ i ] );
}
}


Avatar
kanze
"Aurélien REGAT-BARREL" wrote in
message news:<41a72621$0$6729$...

Pourquoi faire simple quand on peut faire compliqué... Z'ont même
pas été fichus de pondre des mots-clés commençant par "__" -- c'est
pourtant une technique assez classique pour définir des mots-clefs
spéfiques à un compilo et/ou un système.


C'est déjà fait avec Managed C++, et c'est imbitable comme syntaxe.
Faut pourrir ton code de mot clés genre __gc et c'est super lourd.
Y'en a un qui est "marrant" : __identifier, qui permet d'utiliser un
mot clé comme identifieur.


Il y a un contexte où ça pourrait être intéressant, même en C++.
Considérons quelque chose comme :

extern "Fortran" int class( int ) ;

où le nom de la fonction en Fortran est class (et qu'il s'agit d'une
fonction dans une vieille bibliothèque que tu ne peux pas modifier).

Mais évidemment, il existe d'autres solutions. Par exemple, le caractère
_ n'est pas légal en Fortran (ou au moins, il ne l'était pas la dernière
fois que j'ai fait du Fortran). L'implémentation C++ pourrait donc
exiger, ou simplement permettre, que les noms des extern "Fortran" soit
décorés d'un f_, par exemple :

extern "Fortran" int f_class( int ) ;

pour référer à la fonction dont le nom est « class » en Fortran. (Note
bien qu'il faut de toute façon que l'implémentation fasse quelque chose
de spécial, puisqu'en Fortran, « class », « CLASS » et « cLaSs » sont le
même nom. Ce qui résoud aussi le problème -- l'implémentation peut
exiger que les noms « Fortran » soit tout en majuscules. Mais le
problème pourrait se présenter pour d'autres langages.)

On pourrait aussi se poser la question si le problème est assez répandu
pourqu'on cherche à le résoudre. Si le Cobol, avec ses milliers de mots
clé, avait un « extern "X" », peut-être. Mais est-ce que ça vaut la
peine pour le C++. (A priori, le seul cas qui me paraît intéressant de
tête c'est celui de Fortan, et là, on peut jouer sur la case. Autrement,
je vois assez peu de grandes bibliothèques qu'on risque d'hériter et
qu'on ne pourrait pas modifier. Et évidemment, quelqu'un qui développe
une bibliothèque en Ada aujourd'hui, avec l'idée qu'elle pourrait être
universelle, ferait en tout cas attention d'éviter des mots clés C++.)

--
James Kanze GABI Software http://www.gabi-soft.fr
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
adebaene
Loïc Joly wrote in message news:<41a8263b$0$16353$...
int main()
{
std::string s( "coucou" );
std::cout << s << " avec coutn";

// Ici, éventuellement quelquechose du style
// DotNet::LoadMSILInterpreter();
System::Console::Write( s );
System::Console::WriteLine( " avec System::Console" );
return 0;
}


Ca existe plus ou moins mais en beaucoup plus bas-niveau et beaucouc
plus indirect : Il est possible de "hoster" l'environnement
d'execution .NET dans n'importe quelle application non managée : voire
CorBindToRuntimeEx et ses petits copains. Ceci-dit, tu n'aura pas une
intégration directe des sources : une fois le runtime chargé, tu peux
par exemple lui faire charger et executer une assembly existante
(voire en compiler une à la volée).

Arnaud

1 2 3