Re-Bonjour,
Apres l'insistance de certain(s) ... nouveau post
Voici un petit exemple MC++ que j'essaye de faire compiler:
namespace managedDll
{
public __value class VecDouble;
public __value class VecFloat
{
public:
void SetValue(VecDouble vec)
{
// TODO
}
};
public __value class VecDouble
{
public:
void SetValue(VecFloat vec)
{
// TODO
}
};
}
J'ai l'erreur suivante a la compil:
error C2027: use of undefined type 'managedDll::VecDouble'
Le fait que mes methodes soient inline ne change rien au pb car elles ne
sont pas implementees.
Par contre tout se passe bien si mes methodes SetValue ont pour signature
(Vec(Double | Float) &vec). Le probleme est que le & n'est pas logique
car
quand je veux appeler mes methodes depuis du code depuis du C# je suis
oblige de declarer un objet puis de faire appel a la methode en precisant
ref
VecDouble vec = new VecDouble();
vecFloat.SetValue(ref vec);
Alors que je voudrais ecrire vecFloat.SetValue(new VecDouble())
Je suis convaincu de l'existance d'une super solution ... mais je l'ai pas
encore trouvee :-(
Jerome
Re-Bonjour,
Apres l'insistance de certain(s) ... nouveau post
Voici un petit exemple MC++ que j'essaye de faire compiler:
namespace managedDll
{
public __value class VecDouble;
public __value class VecFloat
{
public:
void SetValue(VecDouble vec)
{
// TODO
}
};
public __value class VecDouble
{
public:
void SetValue(VecFloat vec)
{
// TODO
}
};
}
J'ai l'erreur suivante a la compil:
error C2027: use of undefined type 'managedDll::VecDouble'
Le fait que mes methodes soient inline ne change rien au pb car elles ne
sont pas implementees.
Par contre tout se passe bien si mes methodes SetValue ont pour signature
(Vec(Double | Float) &vec). Le probleme est que le & n'est pas logique
car
quand je veux appeler mes methodes depuis du code depuis du C# je suis
oblige de declarer un objet puis de faire appel a la methode en precisant
ref
VecDouble vec = new VecDouble();
vecFloat.SetValue(ref vec);
Alors que je voudrais ecrire vecFloat.SetValue(new VecDouble())
Je suis convaincu de l'existance d'une super solution ... mais je l'ai pas
encore trouvee :-(
Jerome
Re-Bonjour,
Apres l'insistance de certain(s) ... nouveau post
Voici un petit exemple MC++ que j'essaye de faire compiler:
namespace managedDll
{
public __value class VecDouble;
public __value class VecFloat
{
public:
void SetValue(VecDouble vec)
{
// TODO
}
};
public __value class VecDouble
{
public:
void SetValue(VecFloat vec)
{
// TODO
}
};
}
J'ai l'erreur suivante a la compil:
error C2027: use of undefined type 'managedDll::VecDouble'
Le fait que mes methodes soient inline ne change rien au pb car elles ne
sont pas implementees.
Par contre tout se passe bien si mes methodes SetValue ont pour signature
(Vec(Double | Float) &vec). Le probleme est que le & n'est pas logique
car
quand je veux appeler mes methodes depuis du code depuis du C# je suis
oblige de declarer un objet puis de faire appel a la methode en precisant
ref
VecDouble vec = new VecDouble();
vecFloat.SetValue(ref vec);
Alors que je voudrais ecrire vecFloat.SetValue(new VecDouble())
Je suis convaincu de l'existance d'une super solution ... mais je l'ai pas
encore trouvee :-(
Jerome
Pourquoi vouloir absolument faire du MC++? Y a t il une raison précise?
Parce que si vous démarrez un projet, il faut déjà se poser la question de
l'intêret du C/C++, et ensuite, si ces langages sont vraiment nécessaires,
comme vous utilisez C# d'un coté, il est plus simple de faire du "pur"
en C# et le reste en C++ "normal", avec des exports DLL standards (extern
"C").
Mais faire du .NET objet etc..., en C++... ca n'a pas grand intêret, à mon
humble avis...
Simon.
www.softfluent.com
"Jerome" a écrit dans le message de news:
%
> Re-Bonjour,
>
> Apres l'insistance de certain(s) ... nouveau post
>
> Voici un petit exemple MC++ que j'essaye de faire compiler:
>
> namespace managedDll
> {
> public __value class VecDouble;
> public __value class VecFloat
> {
> public:
> void SetValue(VecDouble vec)
> {
> // TODO
> }
> };
> public __value class VecDouble
> {
> public:
> void SetValue(VecFloat vec)
> {
> // TODO
> }
> };
> }
>
> J'ai l'erreur suivante a la compil:
> error C2027: use of undefined type 'managedDll::VecDouble'
> Le fait que mes methodes soient inline ne change rien au pb car elles ne
> sont pas implementees.
>
> Par contre tout se passe bien si mes methodes SetValue ont pour
> (Vec(Double | Float) &vec). Le probleme est que le & n'est pas logique
> car
> quand je veux appeler mes methodes depuis du code depuis du C# je suis
> oblige de declarer un objet puis de faire appel a la methode en
> ref
>
> VecDouble vec = new VecDouble();
> vecFloat.SetValue(ref vec);
>
> Alors que je voudrais ecrire vecFloat.SetValue(new VecDouble())
>
> Je suis convaincu de l'existance d'une super solution ... mais je l'ai
> encore trouvee :-(
>
> Jerome
>
>
Pourquoi vouloir absolument faire du MC++? Y a t il une raison précise?
Parce que si vous démarrez un projet, il faut déjà se poser la question de
l'intêret du C/C++, et ensuite, si ces langages sont vraiment nécessaires,
comme vous utilisez C# d'un coté, il est plus simple de faire du "pur"
en C# et le reste en C++ "normal", avec des exports DLL standards (extern
"C").
Mais faire du .NET objet etc..., en C++... ca n'a pas grand intêret, à mon
humble avis...
Simon.
www.softfluent.com
"Jerome" <jlague@NOSPAMmc.com> a écrit dans le message de news:
%238Du3ahjFHA.3960@TK2MSFTNGP12.phx.gbl...
> Re-Bonjour,
>
> Apres l'insistance de certain(s) ... nouveau post
>
> Voici un petit exemple MC++ que j'essaye de faire compiler:
>
> namespace managedDll
> {
> public __value class VecDouble;
> public __value class VecFloat
> {
> public:
> void SetValue(VecDouble vec)
> {
> // TODO
> }
> };
> public __value class VecDouble
> {
> public:
> void SetValue(VecFloat vec)
> {
> // TODO
> }
> };
> }
>
> J'ai l'erreur suivante a la compil:
> error C2027: use of undefined type 'managedDll::VecDouble'
> Le fait que mes methodes soient inline ne change rien au pb car elles ne
> sont pas implementees.
>
> Par contre tout se passe bien si mes methodes SetValue ont pour
> (Vec(Double | Float) &vec). Le probleme est que le & n'est pas logique
> car
> quand je veux appeler mes methodes depuis du code depuis du C# je suis
> oblige de declarer un objet puis de faire appel a la methode en
> ref
>
> VecDouble vec = new VecDouble();
> vecFloat.SetValue(ref vec);
>
> Alors que je voudrais ecrire vecFloat.SetValue(new VecDouble())
>
> Je suis convaincu de l'existance d'une super solution ... mais je l'ai
> encore trouvee :-(
>
> Jerome
>
>
Pourquoi vouloir absolument faire du MC++? Y a t il une raison précise?
Parce que si vous démarrez un projet, il faut déjà se poser la question de
l'intêret du C/C++, et ensuite, si ces langages sont vraiment nécessaires,
comme vous utilisez C# d'un coté, il est plus simple de faire du "pur"
en C# et le reste en C++ "normal", avec des exports DLL standards (extern
"C").
Mais faire du .NET objet etc..., en C++... ca n'a pas grand intêret, à mon
humble avis...
Simon.
www.softfluent.com
"Jerome" a écrit dans le message de news:
%
> Re-Bonjour,
>
> Apres l'insistance de certain(s) ... nouveau post
>
> Voici un petit exemple MC++ que j'essaye de faire compiler:
>
> namespace managedDll
> {
> public __value class VecDouble;
> public __value class VecFloat
> {
> public:
> void SetValue(VecDouble vec)
> {
> // TODO
> }
> };
> public __value class VecDouble
> {
> public:
> void SetValue(VecFloat vec)
> {
> // TODO
> }
> };
> }
>
> J'ai l'erreur suivante a la compil:
> error C2027: use of undefined type 'managedDll::VecDouble'
> Le fait que mes methodes soient inline ne change rien au pb car elles ne
> sont pas implementees.
>
> Par contre tout se passe bien si mes methodes SetValue ont pour
> (Vec(Double | Float) &vec). Le probleme est que le & n'est pas logique
> car
> quand je veux appeler mes methodes depuis du code depuis du C# je suis
> oblige de declarer un objet puis de faire appel a la methode en
> ref
>
> VecDouble vec = new VecDouble();
> vecFloat.SetValue(ref vec);
>
> Alors que je voudrais ecrire vecFloat.SetValue(new VecDouble())
>
> Je suis convaincu de l'existance d'une super solution ... mais je l'ai
> encore trouvee :-(
>
> Jerome
>
>
OUI OUI la raison est que j'interface un SDK C++ pour en faire un SDK .NET
et que nous avons fait le choix du managed C++ pour des raisons de
performances. J'ai pris l'exemple du C# car le premier utilisateur
utilisera
le C#.
Il me semble bien que ce language est fait pour ca ... non ?
Mais je suis loin d'etre au premier probleme rencontre ... je crois que ce
language n'est pas assez "mature".
J'ose esperer qu'il y a une solution a ce probleme ... sans quoi ce
probleme
remet en cause notre choix.
Jerome.
"Simon Mourier" a écrit dans le message de
news:Pourquoi vouloir absolument faire du MC++? Y a t il une raison précise?
Parce que si vous démarrez un projet, il faut déjà se poser la question
de
l'intêret du C/C++, et ensuite, si ces langages sont vraiment
nécessaires,
comme vous utilisez C# d'un coté, il est plus simple de faire du "pur"
.NETen C# et le reste en C++ "normal", avec des exports DLL standards (extern
"C").
Mais faire du .NET objet etc..., en C++... ca n'a pas grand intêret, à
mon
humble avis...
Simon.
www.softfluent.com
"Jerome" a écrit dans le message de news:
%
> Re-Bonjour,
>
> Apres l'insistance de certain(s) ... nouveau post
>
> Voici un petit exemple MC++ que j'essaye de faire compiler:
>
> namespace managedDll
> {
> public __value class VecDouble;
> public __value class VecFloat
> {
> public:
> void SetValue(VecDouble vec)
> {
> // TODO
> }
> };
> public __value class VecDouble
> {
> public:
> void SetValue(VecFloat vec)
> {
> // TODO
> }
> };
> }
>
> J'ai l'erreur suivante a la compil:
> error C2027: use of undefined type 'managedDll::VecDouble'
> Le fait que mes methodes soient inline ne change rien au pb car elles
> ne
> sont pas implementees.
>
> Par contre tout se passe bien si mes methodes SetValue ont pour
signature> (Vec(Double | Float) &vec). Le probleme est que le & n'est pas logique
> car
> quand je veux appeler mes methodes depuis du code depuis du C# je suis
> oblige de declarer un objet puis de faire appel a la methode en
precisant> ref
>
> VecDouble vec = new VecDouble();
> vecFloat.SetValue(ref vec);
>
> Alors que je voudrais ecrire vecFloat.SetValue(new VecDouble())
>
> Je suis convaincu de l'existance d'une super solution ... mais je l'ai
pas> encore trouvee :-(
>
> Jerome
>
>
OUI OUI la raison est que j'interface un SDK C++ pour en faire un SDK .NET
et que nous avons fait le choix du managed C++ pour des raisons de
performances. J'ai pris l'exemple du C# car le premier utilisateur
utilisera
le C#.
Il me semble bien que ce language est fait pour ca ... non ?
Mais je suis loin d'etre au premier probleme rencontre ... je crois que ce
language n'est pas assez "mature".
J'ose esperer qu'il y a une solution a ce probleme ... sans quoi ce
probleme
remet en cause notre choix.
Jerome.
"Simon Mourier" <simon_mourier@botmail.com> a écrit dans le message de
news:uaQe9ujjFHA.1148@TK2MSFTNGP12.phx.gbl...
Pourquoi vouloir absolument faire du MC++? Y a t il une raison précise?
Parce que si vous démarrez un projet, il faut déjà se poser la question
de
l'intêret du C/C++, et ensuite, si ces langages sont vraiment
nécessaires,
comme vous utilisez C# d'un coté, il est plus simple de faire du "pur"
.NET
en C# et le reste en C++ "normal", avec des exports DLL standards (extern
"C").
Mais faire du .NET objet etc..., en C++... ca n'a pas grand intêret, à
mon
humble avis...
Simon.
www.softfluent.com
"Jerome" <jlague@NOSPAMmc.com> a écrit dans le message de news:
%238Du3ahjFHA.3960@TK2MSFTNGP12.phx.gbl...
> Re-Bonjour,
>
> Apres l'insistance de certain(s) ... nouveau post
>
> Voici un petit exemple MC++ que j'essaye de faire compiler:
>
> namespace managedDll
> {
> public __value class VecDouble;
> public __value class VecFloat
> {
> public:
> void SetValue(VecDouble vec)
> {
> // TODO
> }
> };
> public __value class VecDouble
> {
> public:
> void SetValue(VecFloat vec)
> {
> // TODO
> }
> };
> }
>
> J'ai l'erreur suivante a la compil:
> error C2027: use of undefined type 'managedDll::VecDouble'
> Le fait que mes methodes soient inline ne change rien au pb car elles
> ne
> sont pas implementees.
>
> Par contre tout se passe bien si mes methodes SetValue ont pour
signature
> (Vec(Double | Float) &vec). Le probleme est que le & n'est pas logique
> car
> quand je veux appeler mes methodes depuis du code depuis du C# je suis
> oblige de declarer un objet puis de faire appel a la methode en
precisant
> ref
>
> VecDouble vec = new VecDouble();
> vecFloat.SetValue(ref vec);
>
> Alors que je voudrais ecrire vecFloat.SetValue(new VecDouble())
>
> Je suis convaincu de l'existance d'une super solution ... mais je l'ai
pas
> encore trouvee :-(
>
> Jerome
>
>
OUI OUI la raison est que j'interface un SDK C++ pour en faire un SDK .NET
et que nous avons fait le choix du managed C++ pour des raisons de
performances. J'ai pris l'exemple du C# car le premier utilisateur
utilisera
le C#.
Il me semble bien que ce language est fait pour ca ... non ?
Mais je suis loin d'etre au premier probleme rencontre ... je crois que ce
language n'est pas assez "mature".
J'ose esperer qu'il y a une solution a ce probleme ... sans quoi ce
probleme
remet en cause notre choix.
Jerome.
"Simon Mourier" a écrit dans le message de
news:Pourquoi vouloir absolument faire du MC++? Y a t il une raison précise?
Parce que si vous démarrez un projet, il faut déjà se poser la question
de
l'intêret du C/C++, et ensuite, si ces langages sont vraiment
nécessaires,
comme vous utilisez C# d'un coté, il est plus simple de faire du "pur"
.NETen C# et le reste en C++ "normal", avec des exports DLL standards (extern
"C").
Mais faire du .NET objet etc..., en C++... ca n'a pas grand intêret, à
mon
humble avis...
Simon.
www.softfluent.com
"Jerome" a écrit dans le message de news:
%
> Re-Bonjour,
>
> Apres l'insistance de certain(s) ... nouveau post
>
> Voici un petit exemple MC++ que j'essaye de faire compiler:
>
> namespace managedDll
> {
> public __value class VecDouble;
> public __value class VecFloat
> {
> public:
> void SetValue(VecDouble vec)
> {
> // TODO
> }
> };
> public __value class VecDouble
> {
> public:
> void SetValue(VecFloat vec)
> {
> // TODO
> }
> };
> }
>
> J'ai l'erreur suivante a la compil:
> error C2027: use of undefined type 'managedDll::VecDouble'
> Le fait que mes methodes soient inline ne change rien au pb car elles
> ne
> sont pas implementees.
>
> Par contre tout se passe bien si mes methodes SetValue ont pour
signature> (Vec(Double | Float) &vec). Le probleme est que le & n'est pas logique
> car
> quand je veux appeler mes methodes depuis du code depuis du C# je suis
> oblige de declarer un objet puis de faire appel a la methode en
precisant> ref
>
> VecDouble vec = new VecDouble();
> vecFloat.SetValue(ref vec);
>
> Alors que je voudrais ecrire vecFloat.SetValue(new VecDouble())
>
> Je suis convaincu de l'existance d'une super solution ... mais je l'ai
pas> encore trouvee :-(
>
> Jerome
>
>
Il y a certainement des solutions à ce problème. Mais C# c'est très
performant aussi.
Finalement, peu de projets (je vois météo, calculs scientifiques, moteurs
jeux, etc...) requièrement absolument C/C++. Et souvent certains
C/C++ gagneraient paradoxalement à être écrits en C# (ou VB.NET) pour des
raisons de faible compétence des développeurs en C/C++.
Si c'est pour faire une application "de gestion", C/C++ ne sert
à rien, surtout si vous avez déjà du C# dans votre solution. Et quand bien
même on a vraiment besoin de C/C++ pour des endroits bien spécifiques et
identifiés, autant le faire "à l'ancienne" avec des exports de DLL et
intéropérer avec .NET de manière simple, plutôt que de se casser la tête
avec MC++.
My 0.02?
Simon.
www.softfluent.com
"Jerome" a écrit dans le message de news:
elIOf%
> OUI OUI la raison est que j'interface un SDK C++ pour en faire un SDK
> et que nous avons fait le choix du managed C++ pour des raisons de
> performances. J'ai pris l'exemple du C# car le premier utilisateur
> utilisera
> le C#.
>
> Il me semble bien que ce language est fait pour ca ... non ?
> Mais je suis loin d'etre au premier probleme rencontre ... je crois que
> language n'est pas assez "mature".
>
> J'ose esperer qu'il y a une solution a ce probleme ... sans quoi ce
> probleme
> remet en cause notre choix.
>
> Jerome.
>
> "Simon Mourier" a écrit dans le message de
> news:
>> Pourquoi vouloir absolument faire du MC++? Y a t il une raison précise?
>> Parce que si vous démarrez un projet, il faut déjà se poser la question
>> de
>> l'intêret du C/C++, et ensuite, si ces langages sont vraiment
>> nécessaires,
>> comme vous utilisez C# d'un coté, il est plus simple de faire du "pur"
> .NET
>> en C# et le reste en C++ "normal", avec des exports DLL standards
>> "C").
>>
>> Mais faire du .NET objet etc..., en C++... ca n'a pas grand intêret, à
>> mon
>> humble avis...
>>
>> Simon.
>> www.softfluent.com
>>
>>
>> "Jerome" a écrit dans le message de news:
>> %
>> > Re-Bonjour,
>> >
>> > Apres l'insistance de certain(s) ... nouveau post
>> >
>> > Voici un petit exemple MC++ que j'essaye de faire compiler:
>> >
>> > namespace managedDll
>> > {
>> > public __value class VecDouble;
>> > public __value class VecFloat
>> > {
>> > public:
>> > void SetValue(VecDouble vec)
>> > {
>> > // TODO
>> > }
>> > };
>> > public __value class VecDouble
>> > {
>> > public:
>> > void SetValue(VecFloat vec)
>> > {
>> > // TODO
>> > }
>> > };
>> > }
>> >
>> > J'ai l'erreur suivante a la compil:
>> > error C2027: use of undefined type 'managedDll::VecDouble'
>> > Le fait que mes methodes soient inline ne change rien au pb car elles
>> > ne
>> > sont pas implementees.
>> >
>> > Par contre tout se passe bien si mes methodes SetValue ont pour
> signature
>> > (Vec(Double | Float) &vec). Le probleme est que le & n'est pas
>> > car
>> > quand je veux appeler mes methodes depuis du code depuis du C# je
>> > oblige de declarer un objet puis de faire appel a la methode en
> precisant
>> > ref
>> >
>> > VecDouble vec = new VecDouble();
>> > vecFloat.SetValue(ref vec);
>> >
>> > Alors que je voudrais ecrire vecFloat.SetValue(new VecDouble())
>> >
>> > Je suis convaincu de l'existance d'une super solution ... mais je
> pas
>> > encore trouvee :-(
>> >
>> > Jerome
>> >
>> >
>>
>>
>
>
Il y a certainement des solutions à ce problème. Mais C# c'est très
performant aussi.
Finalement, peu de projets (je vois météo, calculs scientifiques, moteurs
jeux, etc...) requièrement absolument C/C++. Et souvent certains
C/C++ gagneraient paradoxalement à être écrits en C# (ou VB.NET) pour des
raisons de faible compétence des développeurs en C/C++.
Si c'est pour faire une application "de gestion", C/C++ ne sert
à rien, surtout si vous avez déjà du C# dans votre solution. Et quand bien
même on a vraiment besoin de C/C++ pour des endroits bien spécifiques et
identifiés, autant le faire "à l'ancienne" avec des exports de DLL et
intéropérer avec .NET de manière simple, plutôt que de se casser la tête
avec MC++.
My 0.02?
Simon.
www.softfluent.com
"Jerome" <jlague@NOSPAMmc.com> a écrit dans le message de news:
elIOf%23ojFHA.1480@TK2MSFTNGP10.phx.gbl...
> OUI OUI la raison est que j'interface un SDK C++ pour en faire un SDK
> et que nous avons fait le choix du managed C++ pour des raisons de
> performances. J'ai pris l'exemple du C# car le premier utilisateur
> utilisera
> le C#.
>
> Il me semble bien que ce language est fait pour ca ... non ?
> Mais je suis loin d'etre au premier probleme rencontre ... je crois que
> language n'est pas assez "mature".
>
> J'ose esperer qu'il y a une solution a ce probleme ... sans quoi ce
> probleme
> remet en cause notre choix.
>
> Jerome.
>
> "Simon Mourier" <simon_mourier@botmail.com> a écrit dans le message de
> news:uaQe9ujjFHA.1148@TK2MSFTNGP12.phx.gbl...
>> Pourquoi vouloir absolument faire du MC++? Y a t il une raison précise?
>> Parce que si vous démarrez un projet, il faut déjà se poser la question
>> de
>> l'intêret du C/C++, et ensuite, si ces langages sont vraiment
>> nécessaires,
>> comme vous utilisez C# d'un coté, il est plus simple de faire du "pur"
> .NET
>> en C# et le reste en C++ "normal", avec des exports DLL standards
>> "C").
>>
>> Mais faire du .NET objet etc..., en C++... ca n'a pas grand intêret, à
>> mon
>> humble avis...
>>
>> Simon.
>> www.softfluent.com
>>
>>
>> "Jerome" <jlague@NOSPAMmc.com> a écrit dans le message de news:
>> %238Du3ahjFHA.3960@TK2MSFTNGP12.phx.gbl...
>> > Re-Bonjour,
>> >
>> > Apres l'insistance de certain(s) ... nouveau post
>> >
>> > Voici un petit exemple MC++ que j'essaye de faire compiler:
>> >
>> > namespace managedDll
>> > {
>> > public __value class VecDouble;
>> > public __value class VecFloat
>> > {
>> > public:
>> > void SetValue(VecDouble vec)
>> > {
>> > // TODO
>> > }
>> > };
>> > public __value class VecDouble
>> > {
>> > public:
>> > void SetValue(VecFloat vec)
>> > {
>> > // TODO
>> > }
>> > };
>> > }
>> >
>> > J'ai l'erreur suivante a la compil:
>> > error C2027: use of undefined type 'managedDll::VecDouble'
>> > Le fait que mes methodes soient inline ne change rien au pb car elles
>> > ne
>> > sont pas implementees.
>> >
>> > Par contre tout se passe bien si mes methodes SetValue ont pour
> signature
>> > (Vec(Double | Float) &vec). Le probleme est que le & n'est pas
>> > car
>> > quand je veux appeler mes methodes depuis du code depuis du C# je
>> > oblige de declarer un objet puis de faire appel a la methode en
> precisant
>> > ref
>> >
>> > VecDouble vec = new VecDouble();
>> > vecFloat.SetValue(ref vec);
>> >
>> > Alors que je voudrais ecrire vecFloat.SetValue(new VecDouble())
>> >
>> > Je suis convaincu de l'existance d'une super solution ... mais je
> pas
>> > encore trouvee :-(
>> >
>> > Jerome
>> >
>> >
>>
>>
>
>
Il y a certainement des solutions à ce problème. Mais C# c'est très
performant aussi.
Finalement, peu de projets (je vois météo, calculs scientifiques, moteurs
jeux, etc...) requièrement absolument C/C++. Et souvent certains
C/C++ gagneraient paradoxalement à être écrits en C# (ou VB.NET) pour des
raisons de faible compétence des développeurs en C/C++.
Si c'est pour faire une application "de gestion", C/C++ ne sert
à rien, surtout si vous avez déjà du C# dans votre solution. Et quand bien
même on a vraiment besoin de C/C++ pour des endroits bien spécifiques et
identifiés, autant le faire "à l'ancienne" avec des exports de DLL et
intéropérer avec .NET de manière simple, plutôt que de se casser la tête
avec MC++.
My 0.02?
Simon.
www.softfluent.com
"Jerome" a écrit dans le message de news:
elIOf%
> OUI OUI la raison est que j'interface un SDK C++ pour en faire un SDK
> et que nous avons fait le choix du managed C++ pour des raisons de
> performances. J'ai pris l'exemple du C# car le premier utilisateur
> utilisera
> le C#.
>
> Il me semble bien que ce language est fait pour ca ... non ?
> Mais je suis loin d'etre au premier probleme rencontre ... je crois que
> language n'est pas assez "mature".
>
> J'ose esperer qu'il y a une solution a ce probleme ... sans quoi ce
> probleme
> remet en cause notre choix.
>
> Jerome.
>
> "Simon Mourier" a écrit dans le message de
> news:
>> Pourquoi vouloir absolument faire du MC++? Y a t il une raison précise?
>> Parce que si vous démarrez un projet, il faut déjà se poser la question
>> de
>> l'intêret du C/C++, et ensuite, si ces langages sont vraiment
>> nécessaires,
>> comme vous utilisez C# d'un coté, il est plus simple de faire du "pur"
> .NET
>> en C# et le reste en C++ "normal", avec des exports DLL standards
>> "C").
>>
>> Mais faire du .NET objet etc..., en C++... ca n'a pas grand intêret, à
>> mon
>> humble avis...
>>
>> Simon.
>> www.softfluent.com
>>
>>
>> "Jerome" a écrit dans le message de news:
>> %
>> > Re-Bonjour,
>> >
>> > Apres l'insistance de certain(s) ... nouveau post
>> >
>> > Voici un petit exemple MC++ que j'essaye de faire compiler:
>> >
>> > namespace managedDll
>> > {
>> > public __value class VecDouble;
>> > public __value class VecFloat
>> > {
>> > public:
>> > void SetValue(VecDouble vec)
>> > {
>> > // TODO
>> > }
>> > };
>> > public __value class VecDouble
>> > {
>> > public:
>> > void SetValue(VecFloat vec)
>> > {
>> > // TODO
>> > }
>> > };
>> > }
>> >
>> > J'ai l'erreur suivante a la compil:
>> > error C2027: use of undefined type 'managedDll::VecDouble'
>> > Le fait que mes methodes soient inline ne change rien au pb car elles
>> > ne
>> > sont pas implementees.
>> >
>> > Par contre tout se passe bien si mes methodes SetValue ont pour
> signature
>> > (Vec(Double | Float) &vec). Le probleme est que le & n'est pas
>> > car
>> > quand je veux appeler mes methodes depuis du code depuis du C# je
>> > oblige de declarer un objet puis de faire appel a la methode en
> precisant
>> > ref
>> >
>> > VecDouble vec = new VecDouble();
>> > vecFloat.SetValue(ref vec);
>> >
>> > Alors que je voudrais ecrire vecFloat.SetValue(new VecDouble())
>> >
>> > Je suis convaincu de l'existance d'une super solution ... mais je
> pas
>> > encore trouvee :-(
>> >
>> > Jerome
>> >
>> >
>>
>>
>
>
Re-Bonjour,
Apres l'insistance de certain(s) ... nouveau post
Voici un petit exemple MC++ que j'essaye de faire compiler:
namespace managedDll
{
public __value class VecDouble;
public __value class VecFloat
{
public:
void SetValue(VecDouble vec)
{
// TODO
}
};
public __value class VecDouble
{
public:
void SetValue(VecFloat vec)
{
// TODO
}
};
}
J'ai l'erreur suivante a la compil:
error C2027: use of undefined type 'managedDll::VecDouble'
Le fait que mes methodes soient inline ne change rien au pb car elles ne
sont pas implementees.
Par contre tout se passe bien si mes methodes SetValue ont pour signature
(Vec(Double | Float) &vec). Le probleme est que le & n'est pas logique
quand je veux appeler mes methodes depuis du code depuis du C# je suis
oblige de declarer un objet puis de faire appel a la methode en precisant
ref
VecDouble vec = new VecDouble();
vecFloat.SetValue(ref vec);
Alors que je voudrais ecrire vecFloat.SetValue(new VecDouble())
Je suis convaincu de l'existance d'une super solution ... mais je l'ai pas
encore trouvee :-(
Jerome
Re-Bonjour,
Apres l'insistance de certain(s) ... nouveau post
Voici un petit exemple MC++ que j'essaye de faire compiler:
namespace managedDll
{
public __value class VecDouble;
public __value class VecFloat
{
public:
void SetValue(VecDouble vec)
{
// TODO
}
};
public __value class VecDouble
{
public:
void SetValue(VecFloat vec)
{
// TODO
}
};
}
J'ai l'erreur suivante a la compil:
error C2027: use of undefined type 'managedDll::VecDouble'
Le fait que mes methodes soient inline ne change rien au pb car elles ne
sont pas implementees.
Par contre tout se passe bien si mes methodes SetValue ont pour signature
(Vec(Double | Float) &vec). Le probleme est que le & n'est pas logique
quand je veux appeler mes methodes depuis du code depuis du C# je suis
oblige de declarer un objet puis de faire appel a la methode en precisant
ref
VecDouble vec = new VecDouble();
vecFloat.SetValue(ref vec);
Alors que je voudrais ecrire vecFloat.SetValue(new VecDouble())
Je suis convaincu de l'existance d'une super solution ... mais je l'ai pas
encore trouvee :-(
Jerome
Re-Bonjour,
Apres l'insistance de certain(s) ... nouveau post
Voici un petit exemple MC++ que j'essaye de faire compiler:
namespace managedDll
{
public __value class VecDouble;
public __value class VecFloat
{
public:
void SetValue(VecDouble vec)
{
// TODO
}
};
public __value class VecDouble
{
public:
void SetValue(VecFloat vec)
{
// TODO
}
};
}
J'ai l'erreur suivante a la compil:
error C2027: use of undefined type 'managedDll::VecDouble'
Le fait que mes methodes soient inline ne change rien au pb car elles ne
sont pas implementees.
Par contre tout se passe bien si mes methodes SetValue ont pour signature
(Vec(Double | Float) &vec). Le probleme est que le & n'est pas logique
quand je veux appeler mes methodes depuis du code depuis du C# je suis
oblige de declarer un objet puis de faire appel a la methode en precisant
ref
VecDouble vec = new VecDouble();
vecFloat.SetValue(ref vec);
Alors que je voudrais ecrire vecFloat.SetValue(new VecDouble())
Je suis convaincu de l'existance d'une super solution ... mais je l'ai pas
encore trouvee :-(
Jerome
Je viens de trouver la solution ... il suffit de ne pas declarer la
VecFloat::SetValue inline ... j'etais persuade d'avoir essaye.
Merci a tous quand meme !
Jerome
"Jerome" a écrit dans le message de
news:%
> Re-Bonjour,
>
> Apres l'insistance de certain(s) ... nouveau post
>
> Voici un petit exemple MC++ que j'essaye de faire compiler:
>
> namespace managedDll
> {
> public __value class VecDouble;
> public __value class VecFloat
> {
> public:
> void SetValue(VecDouble vec)
> {
> // TODO
> }
> };
> public __value class VecDouble
> {
> public:
> void SetValue(VecFloat vec)
> {
> // TODO
> }
> };
> }
>
> J'ai l'erreur suivante a la compil:
> error C2027: use of undefined type 'managedDll::VecDouble'
> Le fait que mes methodes soient inline ne change rien au pb car elles ne
> sont pas implementees.
>
> Par contre tout se passe bien si mes methodes SetValue ont pour
> (Vec(Double | Float) &vec). Le probleme est que le & n'est pas logique
car
> quand je veux appeler mes methodes depuis du code depuis du C# je suis
> oblige de declarer un objet puis de faire appel a la methode en
> ref
>
> VecDouble vec = new VecDouble();
> vecFloat.SetValue(ref vec);
>
> Alors que je voudrais ecrire vecFloat.SetValue(new VecDouble())
>
> Je suis convaincu de l'existance d'une super solution ... mais je l'ai
> encore trouvee :-(
>
> Jerome
>
>
Je viens de trouver la solution ... il suffit de ne pas declarer la
VecFloat::SetValue inline ... j'etais persuade d'avoir essaye.
Merci a tous quand meme !
Jerome
"Jerome" <jlague@NOSPAMmc.com> a écrit dans le message de
news:%238Du3ahjFHA.3960@TK2MSFTNGP12.phx.gbl...
> Re-Bonjour,
>
> Apres l'insistance de certain(s) ... nouveau post
>
> Voici un petit exemple MC++ que j'essaye de faire compiler:
>
> namespace managedDll
> {
> public __value class VecDouble;
> public __value class VecFloat
> {
> public:
> void SetValue(VecDouble vec)
> {
> // TODO
> }
> };
> public __value class VecDouble
> {
> public:
> void SetValue(VecFloat vec)
> {
> // TODO
> }
> };
> }
>
> J'ai l'erreur suivante a la compil:
> error C2027: use of undefined type 'managedDll::VecDouble'
> Le fait que mes methodes soient inline ne change rien au pb car elles ne
> sont pas implementees.
>
> Par contre tout se passe bien si mes methodes SetValue ont pour
> (Vec(Double | Float) &vec). Le probleme est que le & n'est pas logique
car
> quand je veux appeler mes methodes depuis du code depuis du C# je suis
> oblige de declarer un objet puis de faire appel a la methode en
> ref
>
> VecDouble vec = new VecDouble();
> vecFloat.SetValue(ref vec);
>
> Alors que je voudrais ecrire vecFloat.SetValue(new VecDouble())
>
> Je suis convaincu de l'existance d'une super solution ... mais je l'ai
> encore trouvee :-(
>
> Jerome
>
>
Je viens de trouver la solution ... il suffit de ne pas declarer la
VecFloat::SetValue inline ... j'etais persuade d'avoir essaye.
Merci a tous quand meme !
Jerome
"Jerome" a écrit dans le message de
news:%
> Re-Bonjour,
>
> Apres l'insistance de certain(s) ... nouveau post
>
> Voici un petit exemple MC++ que j'essaye de faire compiler:
>
> namespace managedDll
> {
> public __value class VecDouble;
> public __value class VecFloat
> {
> public:
> void SetValue(VecDouble vec)
> {
> // TODO
> }
> };
> public __value class VecDouble
> {
> public:
> void SetValue(VecFloat vec)
> {
> // TODO
> }
> };
> }
>
> J'ai l'erreur suivante a la compil:
> error C2027: use of undefined type 'managedDll::VecDouble'
> Le fait que mes methodes soient inline ne change rien au pb car elles ne
> sont pas implementees.
>
> Par contre tout se passe bien si mes methodes SetValue ont pour
> (Vec(Double | Float) &vec). Le probleme est que le & n'est pas logique
car
> quand je veux appeler mes methodes depuis du code depuis du C# je suis
> oblige de declarer un objet puis de faire appel a la methode en
> ref
>
> VecDouble vec = new VecDouble();
> vecFloat.SetValue(ref vec);
>
> Alors que je voudrais ecrire vecFloat.SetValue(new VecDouble())
>
> Je suis convaincu de l'existance d'une super solution ... mais je l'ai
> encore trouvee :-(
>
> Jerome
>
>
Je viens de trouver la solution ... il suffit de ne pas declarer la
methode
VecFloat::SetValue inline ... j'etais persuade d'avoir essaye.
Merci a tous quand meme !
Jerome
"Jerome" a écrit dans le message de
news:%Re-Bonjour,
Apres l'insistance de certain(s) ... nouveau post
Voici un petit exemple MC++ que j'essaye de faire compiler:
namespace managedDll
{
public __value class VecDouble;
public __value class VecFloat
{
public:
void SetValue(VecDouble vec)
{
// TODO
}
};
public __value class VecDouble
{
public:
void SetValue(VecFloat vec)
{
// TODO
}
};
}
J'ai l'erreur suivante a la compil:
error C2027: use of undefined type 'managedDll::VecDouble'
Le fait que mes methodes soient inline ne change rien au pb car elles ne
sont pas implementees.
Par contre tout se passe bien si mes methodes SetValue ont pour signature
(Vec(Double | Float) &vec). Le probleme est que le & n'est pas logique
carquand je veux appeler mes methodes depuis du code depuis du C# je suis
oblige de declarer un objet puis de faire appel a la methode en precisant
ref
VecDouble vec = new VecDouble();
vecFloat.SetValue(ref vec);
Alors que je voudrais ecrire vecFloat.SetValue(new VecDouble())
Je suis convaincu de l'existance d'une super solution ... mais je l'ai
pas
encore trouvee :-(
Jerome
Je viens de trouver la solution ... il suffit de ne pas declarer la
methode
VecFloat::SetValue inline ... j'etais persuade d'avoir essaye.
Merci a tous quand meme !
Jerome
"Jerome" <jlague@NOSPAMmc.com> a écrit dans le message de
news:%238Du3ahjFHA.3960@TK2MSFTNGP12.phx.gbl...
Re-Bonjour,
Apres l'insistance de certain(s) ... nouveau post
Voici un petit exemple MC++ que j'essaye de faire compiler:
namespace managedDll
{
public __value class VecDouble;
public __value class VecFloat
{
public:
void SetValue(VecDouble vec)
{
// TODO
}
};
public __value class VecDouble
{
public:
void SetValue(VecFloat vec)
{
// TODO
}
};
}
J'ai l'erreur suivante a la compil:
error C2027: use of undefined type 'managedDll::VecDouble'
Le fait que mes methodes soient inline ne change rien au pb car elles ne
sont pas implementees.
Par contre tout se passe bien si mes methodes SetValue ont pour signature
(Vec(Double | Float) &vec). Le probleme est que le & n'est pas logique
car
quand je veux appeler mes methodes depuis du code depuis du C# je suis
oblige de declarer un objet puis de faire appel a la methode en precisant
ref
VecDouble vec = new VecDouble();
vecFloat.SetValue(ref vec);
Alors que je voudrais ecrire vecFloat.SetValue(new VecDouble())
Je suis convaincu de l'existance d'une super solution ... mais je l'ai
pas
encore trouvee :-(
Jerome
Je viens de trouver la solution ... il suffit de ne pas declarer la
methode
VecFloat::SetValue inline ... j'etais persuade d'avoir essaye.
Merci a tous quand meme !
Jerome
"Jerome" a écrit dans le message de
news:%Re-Bonjour,
Apres l'insistance de certain(s) ... nouveau post
Voici un petit exemple MC++ que j'essaye de faire compiler:
namespace managedDll
{
public __value class VecDouble;
public __value class VecFloat
{
public:
void SetValue(VecDouble vec)
{
// TODO
}
};
public __value class VecDouble
{
public:
void SetValue(VecFloat vec)
{
// TODO
}
};
}
J'ai l'erreur suivante a la compil:
error C2027: use of undefined type 'managedDll::VecDouble'
Le fait que mes methodes soient inline ne change rien au pb car elles ne
sont pas implementees.
Par contre tout se passe bien si mes methodes SetValue ont pour signature
(Vec(Double | Float) &vec). Le probleme est que le & n'est pas logique
carquand je veux appeler mes methodes depuis du code depuis du C# je suis
oblige de declarer un objet puis de faire appel a la methode en precisant
ref
VecDouble vec = new VecDouble();
vecFloat.SetValue(ref vec);
Alors que je voudrais ecrire vecFloat.SetValue(new VecDouble())
Je suis convaincu de l'existance d'une super solution ... mais je l'ai
pas
encore trouvee :-(
Jerome
Re-Bonjour,
Apres l'insistance de certain(s) ... nouveau post
Finalement, peu de projets (je vois météo, calculs scientifiques, moteurs
de
jeux, etc...) requièrement absolument C/C++. Et souvent certains
programmes
C/C++ gagneraient paradoxalement à être écrits en C# (ou VB.NET) pour des
raisons de faible compétence des développeurs en C/C++.
Re-Bonjour,
Apres l'insistance de certain(s) ... nouveau post
Finalement, peu de projets (je vois météo, calculs scientifiques, moteurs
de
jeux, etc...) requièrement absolument C/C++. Et souvent certains
programmes
C/C++ gagneraient paradoxalement à être écrits en C# (ou VB.NET) pour des
raisons de faible compétence des développeurs en C/C++.
Re-Bonjour,
Apres l'insistance de certain(s) ... nouveau post
Finalement, peu de projets (je vois météo, calculs scientifiques, moteurs
de
jeux, etc...) requièrement absolument C/C++. Et souvent certains
programmes
C/C++ gagneraient paradoxalement à être écrits en C# (ou VB.NET) pour des
raisons de faible compétence des développeurs en C/C++.
> enleve le premier public. quand tu fais une forward decl, faut pas
mentionner la visiblité. par contre, faut le "comportement"
> enleve le premier public. quand tu fais une forward decl, faut pas
mentionner la visiblité. par contre, faut le "comportement"
> enleve le premier public. quand tu fais une forward decl, faut pas
mentionner la visiblité. par contre, faut le "comportement"