Newsgroup: it.comp.macintosh
Titolo: Sviluppare applicazioni in C++

Ciao a tutti
Sto cercando della documentazione completa su come sviluppare 
applicazioni (grafiche) in C++ su OSX.
Mi pare di aver capito che dovrei buttarmi su Carbon (dico bene?), ma di 
esempi e documenti fatti bene non ne ho trovati.
Altra cosa che mi e' parsa interessante e' la possibilita' che offre 
l'Object-C di legarsi a delle classi Java ( come nell'esempio: 
http://www.awprofessional.com/articles/article.asp?p=428071&seqNum=2
)
C'e' la stessa possibilita' potendo fare uso di C++ ?
E per quanto riguarda al classico C cosa si puo' fare ?
grazie infinite a tutti quanti

 E per quanto riguarda al classico C cosa si puo' fare ?
Di tutto, se si è ben disposti verso X11.

 esempi e documenti fatti bene non ne ho trovati.
Si', hai capito bene (anche se Carbon e' tutto C procedurale). Hai
cercato .cpp in /Developer/Examples/Carbon?
 - ∞

 E per quanto riguarda al classico C cosa si puo' fare ?
Fare tutto. Comodamente un po' tanto di meno.
Oppure usi.. Carbon. O qualche libreria cross-platform.
-- 
Ricordo che alla libertà di parola, è associata anche la libertà 
di pensiero. Purtroppo vedo che sempre più spesso si fa uso della 
prima e non della seconda.

 
No, okay X11 e il layer BSD, ma intendevo proprio il poter fare uso 
magari di un Bridge verso C da Object C, oppure scrivere tutto in C 
legandosi a Cococa (ma suppongo a priori che quest'ultima soluzione sia 
impossibile)
Grazie
Ciao

 Se appena puoi, evita.
Come da risposta a Guido...non intendo la volonta' di sviluppare tutto 
in java, ma solo per le parti "nascoste", tramite il bridging che 
permette di legarsi da Object-C a classi Java
Quindi, mi chiedevo se fosse possibile fare un bridging verso C++/C
Grazie
Ciao

 > E per quanto riguarda al classico C cosa si puo' fare ?
Per un progetto a linea di comando...beh puoi farlo con quello che ti è
più comodo. XCode è un buon prodotto e la compilazione e vari settaggi
sono ben assistiti.
-- 
www.malcom-mac.com/blog
software development for Mac/Win
nemo - cocoa newsgroups reader for macintosh

 impossibile)
Objective-C è un superset di C. In realtà, a parte un piccolo runtime,
il codice objc viene tradotto dal compilatore in C. Quindi puoi mixare
tranquillamente Objc,c e c++ senza problemi (sia per la gui che per il
codice in se).


 Cocoa si, come no, a me interessa potermi legare col C++ e/o C
Come ho già detto puoi mixare objc,c e c++ senza problemi all'interno
dello stesso sorgente.


 codice in se).
Esatto. L'unica cosa che non puoi fare è ereditare una classe ObjC da
una C++ e viceversa. Per il resto codice C++ o C è perfettamente ammesso
all'interno di codice ObjC.
Se hai una libreria in C o in C++ puoi senza *alcun* problema chiamarla
da codice ObjC. Per libreria però escludo:
1) librerie grafiche
2) librerie che gestiscono "eventi"
3) librerie multithread "esterne".


 
grazie per tutte le delucidazioni.
max

 grazie per tutte le delucidazioni.
de nada ;)


 ??? Non credo siano cocoa.
Del primo sono sicuro perché mi ricordo un'intervista
di Architosh agli sviluppatori di SketchUp proprio a
proposito. Lightroom usa un bridge Objective-C-Lua,
anche se in questo caso la maggior parte del codice
non è C ma proprio quel linguaggio di scripting
brasiliano.

 brasiliano.
Pssst:
http://www.pixelballistics.com/Software/LuaObjCBridge/Contents.html
 - ∞

 grazie per tutte le delucidazioni.
Ah attento attento! Se vuoi mixare Objective-C e C++ nello stesso
sorgente, devi rinominare il file sorgente in .mm invece di .m (cosi'
lui capisce che il codice e' C++, non C liscio, oltre alle estensioni di
Objective-C).
 - ∞

 Objective-C).
Aggiunta dell'aggiunta. Se usi Xcode basta fare mela-i sulla classe e
impostare il tipo di sorgente.


 impostare il tipo di sorgente.
Questa e' una bella cosa, ma e' "persistente" solo nel singolo progetto
Xcode. Modificando l'estensione, sia gcc che eventuali nuovi progetti di
Xcode che incorporano quel file non avranno problemi a capirlo.
 - ∞

 Xcode che incorporano quel file non avranno problemi a capirlo.
Si certo però se usi solo xcode può passare. In effetti a lui potrebbe
creare problemi quindi è meglio la tua ;)


 brasiliano.
eh? o_O; il linguaggio dei plugin di freePOPs?
-- 
"Oggi piů che a baciare si pensa a smanettare al computer su Internet"
                                                    -- Barbara Alberti

 
In realta' a me piacerebbe poter fare tutto tramite vim e compilatore a 
riga di comanda nel piu' classico stile del gcc e dei Makefile.
Giocoforza faccio uso di XCode, che reputo pulito e lineare e quindi 
tutto sommato fatto bene, ma come tutti questi tipi di strumenti, mi da 
sempre l'idea di non avere il controllo completo sullo sviluppo, e cio' 
non lo reputo un bene in assoluto.
grazie a tutti
ciao
	MaX
PS:
provengo dal mondo Linux

 provengo dal mondo Linux
Ehehehe questo spiega tutto quello sopra ;-)
Beh allora fai come ti ha detto prima l0ne prima e vai tranquillo ^^


 riga di comanda nel piu' classico stile del gcc e dei Makefile.
man xcodebuild


 non lo reputo un bene in assoluto.
Hai tanto controllo in Xcode quanto ne hai a lavorare con un Makefile
con regole coi wildcard.
E' solo che bisogna prenderci un po' la mano coi target e le dipendenze,
e che purtroppo sono in mezzo a una transizione maledetta per cui alcuni
target sono in un modo e altri in un altro (*), per cui non e' proprio
omogeneo.
Speriamo in Xcode 3...
 - ∞
(*) Il predecessore di Xcode, Project Builder, usava un simil-make
chiamato Jam e i target dei progetti di PB erano veri e propri target
Jam (era un grosso frontend sopra i makefile in pratica). Xcode ha un
sistema "nuovo" di build ("target nativi") ma purtroppo non e' ancora in
grado di fare tutto quello che faceva Jam, e pertanto deve supportare
entrambi i tipi di target (es.: non sa compilare sorgenti Java tutti
insieme, perche' e' "fisso" nello stile C di compilazione
prima-file-oggetto-separatamente-e-poi-link, che con Java non funziona).
Per quei tipi di progetto bisogna usare target nonnativi (jam).