Newsgroup: it.comp.programmare.win32
Titolo: passaggio progetti visual c a vs2003

Ciao ragazzi...
chiedo la vostra consulenza per un problema di tipo logistico.
In azienda abbiamo diversi progetti sviluppati in Visual C (GDI non
MFC) con Visual Studio 6.
La mia intenzione è di passare tutto in visual studio .NET.
Ora...avevo provato a convertire una copia di uno di questi progetti in
VS2003. La conversione aveva avuto buon esito....ho cmpilato il tutto
senza problemi.
Ora il mio dubbio è solo che, vista la complessità dei progetti in
questione, eseguendo la conversione, non mi ritrovi nel tempo qualche
errore dovuto proprio a questo passaggio (gestione della memoria ecc.
ecc.).
Qualcuno di voi mi può dire qualcosa o ha avuto qualche esperienza?
Grazie!

 Qualcuno di voi mi può dire qualcosa o ha avuto qualche esperienza?
Noi in ditta abbiamo fatto lo stesso passaggio l'anno scorso. Progetto molto 
grande, in 5 persone ci abbiamo messo circa 2 mesi. Non è facilissimo, ma 
neanche impossibile. La fatica vale il vantaggio. Comunque ora non passate a 
2003 ma a 2005! 
-- 
Luc

Perché due mesi....così tanto?
Io intendevo solo la conversione brutale del progetto, ma sempre con il
compilatore C...
Tu forse intendi l'utilizzo del framework nel progetto....o no?
Scusa la confusione....

 Perché due mesi....così tanto?
45 progetti tra exe/dll/ocx, ogniuno con una media di 25/30 file .cpp... 
-- 
Luc

ah ok!! :)
Nel mio caso sono 5 progetti da 10/12 file .c
Quindi credo ci metterò molto meno........
Hai dovuto usare qualche particolare accorgimento o hai semplicemente
aperto quel progetto con VS NET e eseguito la conversione?
Nessun problema dopo?

 Nessun problema dopo?
Problemi di entita medio/bassa. Molti casini con STL e Templates... 
-- 
Luc

grazie luc!!
mi sei stato molto utile...

2003 ma a 2005! 
Si però, con la versione Beta del 2005 vengon fuori dei casini che riguardano le nuove regole del C++
che io non ho capito come risolvere.
Tu lo sai?
Ciao
F

 Tu lo sai?
L'adeguamento allo standard ISO C++ ha comportato diverse 'breaking 
changes'.
Qui puoi trovare dei suggerimenti:
http://msdn.microsoft.com/visualc/previous/migrating/default.aspx
e poi:
http://www.codeguru.com/cpp/cpp/cpp_managed/moving/article.php/c9523/
http://msdn.microsoft.com/chats/transcripts/vstudio/vstudio_061704.aspx
-- 
Raffaele Rialdi
Microsoft .NET MVP 
http://mvp.support.microsoft.com
 -
http://italy.mvps.org
 UGIdotNET - User Group Italiano .NET
http://www.ugidotnet.org
 Weblog: 
http://blogs.ugidotnet.org/raffaele


http://msdn.microsoft.com/chats/transcripts/vstudio/vstudio_061704.aspx
Si ho già guardato le pagine che mi hai suggerito, ma non ci ho capito un gran chè.
Se qualcuno lo spiegasse in Italiano non sarebbe male.
Le domande più impellenti sono :
Se acquisto VS2005 devo correggere parte del mio codice?
O lo fa il compilatore?

 O lo fa il compilatore?
Pre 'breaking changes' si intendono quelle modifiche al linguaggio per cui 
il compilatore non può più compilarle.
Di conseguenza è necessario modificare il sorgente in modo da adeguarlo alle 
nuove regole del linguaggio.
Detto questo, qualsiasi variazione automatica fatta da un wizard sarebbe 
altamente a rischio perché è imprevedibile l'impatto che può avere anche la 
più piccola variazione sul resto del listato.
Il compilatore quindi non può che sengalarti gli errori (spesso suggerendoti 
anche la modifica da fare) ma resta a te valutare come risolvere l'errore.
Spesso le modifiche sono banali ma dipende fortemente dal modo in cui è 
stato scritto il sorgente.
Faccio un esempio:
for(int i=0; i<10; i++)  { ...}
la visibilità di i nel passato era anche al di fuori del for. Adesso invece 
è solo internamente alle graffe del for.
Ci sono quindi almeno due casi:
- non modificare nulla perchè i viene solo usato all'interno
- spostare int i al di fuori perchè i è usato anche all'esterno


- spostare int i al di fuori perchè i è usato anche all'esterno
Ho capito!
Per il caso che hai suggerito, per esempio, mi tocca ricontrollare tutto il codice che ho scitto!
Ottimo!

 tutto il codice che ho scitto! Ottimo!
ok :-)
Secondo me ti conviene installarti vs2005 (anche la demo va benissimo) e 
vedere la gravità degli errori riportati.
Strada praticona ma nettamente più semplice da percorrere.


Strada praticona ma nettamente più semplice da percorrere.
Si, in effetti, penso che farò così (chi nn lo farebbe?)
Spero di capirci nelle spiegazioni degli errori!
:))
Ciao
F

 Secondo me ti conviene installarti vs2005 (anche la demo va benissimo)
la demo č diversa dalla beta2?perchč la beta 2 ha tra i vari bug uno che mi 
ha bloccato per circa un mese e che riguarda il caricamento delle dll.
Lo dico cosě solo a titolo informativo, visto che ho avuto questo problema.
ciao
marco

 problema. ciao
La demo è la RTM. La beta è una beta :-) cioè una versione che è in fase di 
sviluppo ...
Non conosco il bug specifico ma ragionevolmente non dovrebbe esserci.
Nel caso hai il product feedback:
http://lab.msdn.microsoft.com/productfeedback/default.aspx


 
http://lab.msdn.microsoft.com/productfeedback/default.aspx
ahi...allora comincio a disperare, comincia a darmi lo stesso problema con 
il VS2005 professional, nessuna beta 2...
in parole povere: ho una dll fatta in embedded c++ e un modulo c#che deve 
usare delle funzioni della dll. al momento di caricarla mi da un errore del 
genere:
Can't find an Entry Point 'InitializeTAPI' in a PInvoke DLL 
'\Windows\DLL_Palm.dll'.
premetto che dll_palm.dll è stata caricata nel palmare e ho fatto 
l'importazione con l'attributo dllimport. prima pensavo dipendesse dal fatto 
che fosse beta 2 e stavo impazzendo ma ora non so come fare...
qualche idea sulla causa?cosa sbaglio?
grazie se puoi essermi di aiuto!
marco 

 '\Windows\DLL_Palm.dll'.
Questo messaggio non mi fa proprio pensare ad un bug.
Se effettivamente DLL_Palm.dll contiene la InitializeTAPI (controlla 
comunque) potrebbe essere in una calling convention diversa.
Questo lo puoi verificare con dumpbin.
Io di solito marco le funzioni da esportare in questo modo:
extern "C" __declspec(dllexport) void __cdecl MyCall(...)


 extern "C" __declspec(dllexport) void __cdecl MyCall(...)
avevo provato così ma senza l'ultima parte, cioè " __cdecl ", ora aggiorno e 
vedo che succede
ps: se faccio il dumpbin sulla dll che teoricamente è per il palmare ma 
risiede cmq sull'hd del PC, mi dà le giuste informazioni o dovrei eseguire 
il comando sul palmare?in linea teorica anche se lo faccio sul PC va bene, 
in fin dei conti dumpbin non fa altro che andare a leggere un elenco con le 
funzioni esportate giusto?
grazie ancora per l'aiuto intanto, farò sapere dei risultati.
marco 

 sviluppo ...
perdona l'ignoranza, per cosa sta l'acronimo RTM?ready to qualcosa? 

> perdona l'ignoranza, per cosa sta l'acronimo RTM?ready to qualcosa?
Release To Manufacturing, cioč la versione definitiva.


 grazie ancora per l'aiuto intanto, farò sapere dei risultati.
Prego
