Newsgroup: it.comp.lang.c++
Titolo: VC++ express . NET

Ho bisogno di aiuto perché non trovo le opzioni giuste per 
includere la libreria standard STL in un programma (progetto 
impostato come console application win32)
Quando provo a scrivere
using namespace std;
o a istanziare oggetti tipo
std :: string Pippo;
esso mi cazzia dicendo
Error	1	error C2653: 'std' : is not a class or namespace name 
d:\sourcecode_vb_5\net\prova_stl_00\prova_stl_00\prova_stl_00.cpp	16
ciò malgrado io abbia incluso lo header con
#include <string>
e malgrado a design time l'intellisense mi esponga senza 
problemi i membri del namespace std medesimo.
Però poi il compilatore non lo trova.
Come faccio a includerlo ? Non esiste uno header chiamato <std> 
... boh, non mi ci oriento per niente. Ho anche aggiunto a mano 
una riga della directory di files include, da qualche parte 
nelle molte opzioni, ma senza effetto.
grazie di ogni aiuto
Soviet_Scornato_Mario

 Come faccio a includerlo ? Non esiste uno header chiamato <std> .... 


prova a vedere se è lo stesso problema
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1136318&SiteID=1

> opzioni, ma senza effetto.
Il tuo problema non riguarda gli include, che evidentemente il 
compilatore trova senza problemi. Devi invece guardare le opzioni del 
linker. Parallela alla directory include, ci deve essere una directory 
lib, guarda lì dentro. Al limite penso che potrai aggiungere a forza le 
librerie che ti servono nel progetto.
E.

 
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1136318&SiteID=1
grazie mille per l'aiuto, sei stato molto gentile.
Mo' le provo tutte, ma da quello che ho letto nel forum, in 
effetti mi pare un mezzo bug !
Speriamo che uno degli escamotage funga
ciao
Soviet

 lib, guarda lì dentro. 
minchia, oltre a essere un sacco di librerie, non so come capire 
quale versione contenga quello che certo !
Spero che fungano i consigli riportati da theFiller
ciao e grazie anche a te
Soviet


 
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1136318&SiteID=1
ok, ho "fatto".
Incredibilmente adesso il namespace std viene importato, e 
infatti svaniscono gli errori di compilazione relativi a ciò, ma 
compaiono una serie interminabile di
"unresolved externals" da parte del maledetto linker che non 
trova i simboli con enne maledette combinazioni di librerie di 
default, non di default, header precompilati SI/NO/NON SI SA, e 
boh ...
Veramente mi sembra tutto surreale. Cioè, mi pare di scontrarmi 
con un muro gommoso e assurdo che si possano correggere 
facilmente gli errori di sintassi del sorgente, ma non ci sia 
modo di sapere quali diavolo di librerie si aspetta questo 
linker per vedere cose invocate dall'interno di STL (di cui non 
conosco nessun dettaglio interno).
Su questo argomento (di come siano implementate le librerie 
standard o meno, e di come funzionino dal punto di vista del 
linking) so poco o nulla, ma avrei immaginato che contenessero 
dentro qualche meccanismo di "dipendenze" per non far mancare pezzi.
Un'altra cosa di cui probabilmente mi illudevo era che l'IDE 
potesse facilmente capire, scandendo gli HEADER e tenendone la 
lista complessiva, capire da sé di quali librerie avesse bisogno 
il programma. Forse perché c'erano meno opzioni, con gli IDE 
molto più datati non mi erano mai capitate queste necessità di 
indicare tutto (ma cosa ? e dove ?) per filo e per segno.
A quel punto è persino peggio che dover scrivere a mano dei 
makefile .... boh, non capisco
ciao
Soviet_scornato

 default, header precompilati SI/NO/NON SI SA, e boh ...
Mi sono scontrato su un problema simile qualche giorno fa. Cercavo di
costruire una dll di classi, alcune delle quali composte di oggetti
template della stl. Ovviamente (?) ciò non si può fare. Al che ho deciso
di utilizzare le classi container mfc (CArray). Ma cambiare tipo di
target dopo che VS ha creato i suoi file .cpp e .h (nonché le opzioni
del progetto) è da pazzi insensati.
Io attualmente in win sto utilizzando VS2003, spero tanto che con il
2005 (o almeno con il venturo 2008) abbiano risolto. CHe dite?

 Veramente mi sembra tutto surreale.
Con i prodotti Microsoft è normale. :-)
EMG
--
EMAG Software Homepage:     
http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: 
http://www.emagsoftware.it/spectrum
The Best of Spectrum Games: 
http://www.emagsoftware.it/tbosg
The EMG Music page:         
http://www.emagsoftware.it/emgmusic
 

 Soviet_scornato
la versione express è pensata per il .net.
Per adattarla al C++ ci sono una serie di operazioni da fare (tipo 
scaricare il sdk).
Non ricordo ora quali siano, ma si trova in rete un documento con le 
informazioni necessarie.
Ciao

 .... boh, non capisco
...infatti...
E.

 di utilizzare le classi container mfc (CArray).
In realta' std::vector (e credo anche std::string) li puoi esportare:
http://support.microsoft.com/kb/168958
Saluti,
The Librarian

 
http://support.microsoft.com/kb/168958
No, in realtà non va (VS2003): Credo che in tale versione std::vector
sia composta da qualche altra classe che va a sua volta esportata (forse
l'iteratore?)
La cosa davvero più semplice è dichiarare sull'header una classe
derivata mycontainer, e definire nel codice tale classe componendo il
template necessario (è un pattern di tipo delegate).
Non se se funziona anche definendo la classe come derivata per ereditarietà.

 Ciao

 E.

 l'accenno mi inquieta !
Be', si sa che i prodotti Microsoft, da Office a Visual Basic alle API 
stesse, sono basati su una logica contorta e spesso incomprensibile.


stesse, sono basati su una logica contorta e spesso incomprensibile.
Be', questo semplicemente non è vero. L'API di Windows non ha una
logica contorta e non mi sembra neanche che Office sia così astruso
come dici. Sorvolo su VB che ho visto di sfuggita (per fortuna).
Non sarà che hai qualche pregiudizio?

 Non sarà che hai qualche pregiudizio?
Non ho pregiudizi dato che Windows è la mia unica piattaforma di sviluppo. 
Quindi cerco di evidenziarne i punti che non vanno solo per poter vivere 
meglio. Ma capisco che la cosa possa essere soggettiva e quindi prendi ciò 
che ho detto come un punto di vista strettamente personale (benché condiviso 
da molti).
