Newsgroup: it.comp.lang.c
Titolo: C#

Scusate ma nella gerarchia it.comp.lang  non ho trovato un NG dedicato a C#.
- Qui si parla anche di C#  ?
- in caso contrario, potete indicarmi un NG adatto ??
Grazie.
John.

 - in caso contrario, potete indicarmi un NG adatto ??
Credo che la scelta migliore sia microsoft.public.it.dotnet.csharp
ciao
Giacomo

 Infatti la proposta di aprire i.c.l.csharp e' stata bocciata...
Come mai è stata bocciata la candidatura di aprire i.c.l.csharp.
Mi pare che sia un linguaggio ormai consolidato e non vedo ragioni se 
effettivamente già esistano i.c.l.visual-basic e i.c.l.pascal


al C# meno gli si da spago meglio è. Non conosco le ragioni della
bocciatura (probabilmente non ha raggiunto il numero di subscription
minimo durante il periodo di valutazione?) ma personalmente non posso
che esserne contento.
Ciao!

Ritengo che il tuo commento sia troppo estremo, io programmo 
regolarmente in c/c++ e ho provato il c#.
Sicuramente è un ottimo linguaggio potente e versatile. Io lo uso quando 
devo fare prototipazione perchè purtroppo non supporta mmx,sse e openmp.
Il bello del c# è che fai tante cose con una velocità incredibile, il 
brutto è che è gestito da MS e quindi è suo.



Sì, non sono mai stato diplomatico nelle mie esternazioni.
Anch'io programmo regolarmente in C# (purtroppo) e devo dire che sì,
per le stupidaggini è molto veloce (array/liste/interfacce/etc.) ma
appena cerchi di fare qualcosa un *minimo* fuori dagli schemi sei
finito. Basti pensare a quanto casino occorre fare per avere un
puntatore a funzione o ancora peggio richiamare una funzione in una
dll in C/C++.
Ad aggiungere antipatia poi sì, è il fatto che si tratta di un
linguaggio puramente commerciale che nessuno voleva.
Meglio tornare a programmare, prima che mi scaldi (programmare in C,
ovviamente! :D)
Ciao!


grazie del suggerimento. Purtroppo il server che uso (linuxfan) non lo 
ospita....<sigh>   :-(
Dovr� cercarlo da qualche altra parte.

 Ciao!
Infatti, la penso esattamente come te.
Io quello che non apprezzo del c/c++ � il fatto che sono poco 
aggiornati. Questo � ovviamente un pro per la compatibilit� ma, penso 
che sia ormai obbligatorio avere delle librerie preintegrate per gestire 
dati base come xml e socket (per fare un esempio). E poi non � possibile 
che dopo 10 anni di mmx e sse siamo ancora senza una base dati (classe) 
che permetta di lavorarci in nativo. Ti tocca sempre fare giochi stani 
per avere l'allineamento giusto.
Peccato.


Riguardo mmx e sse la filosofia C credo sia quella di lasciare il
compito di "ottimizzare" al compilatore. Questo non è possibile solo
per un ristretto range di programmatori (come te, a quanto ho capito),
per cui non è importante per chi fa standard "spostare il problema" a
livello di linguaggio o di librerie standard.
Per quanto riguarda l'aggiornamento e la ricchezza delle librerie
standard, il problema è sempre esistito: già dalla prima draft del C89
la maggior parte degli sviluppatori C pre-ANSI avevano già ognuno le
loro librerie per fare un po' tutto.. Del resto sia io nel mio piccolo
sia l'azienda dove attualmente lavoro nel suo grande abbiamo chili e
chili di librerie custom (e ovviamente diverse) con funzioni che vanno
dalle linked-list a funzioni sulle NURBS, dal controllo di interfaccia
allo IPC: anche se venissero standardizzate delle funzioni che
sostituissero le nostre (come ad esempio ogni tanto viene avanzata
l'ipotesi di standardizzare funzioni sulle liste), non le cambieremo
di certo - passeremo solamente a non essere più ANSI compliant, senza
aver fatto nulla e con tutti i problemi di qualità che ne
risulterebbero.
Ciao!

 mi scaldi (programmare in C, ovviamente! :D)
In effetti... io mi sono sempre rifiutato di usarlo solo
perché l'ho visto come una specie di puntare i piedi di MS
come a dire "ma come osate non accettare che siamo noi a
decidere quel che si deve fare o non fare in informatica?"
E giù un linguaggio, inutile visto che è appunto,
proprietario.
-- 
Tutti gli uomini sono mortali
il gatto è un animale
quindi Socrate ha la coda.


quindi standard.
Il problema non è tanto il linguaggio quanto la class library che a
parte tipi e cose basilari (che sono ecma pure quelle) è pensato e
progettato per rispecchiare le funzionalità di windows.
Lato server deve competere con php, java, python, ruby, ..... e la vedo
difficile visto che un server windows 2008 non mi da la stessa sicurezza
e affidabilità di *nix vari
lato client è molto avanzato (vedi silverligth, wpf) ma visto che il
mercato ormai è abbastanza disomogeneo... nel senso ha senso oggi
sviluppare una nuova applicazione desktop che non supporti ad esempio
osx? quindi sul fronte multipiattaforma è carentuccio... anche se mono e
varie librerie gui esistono alla fine o uno usa java o c++ e
qt/wxwidgets (e non ho contato lato giochi dove xna deve competere con
motori iper otimizzati come ogre o irrlicht che supportano pure varie
piattaforme)
Non dico che C# sia una cosa brutta di per se solo che ci sono in giro
alternative migliori.
ovviamente personalissime idee

 ovviamente personalissime idee
Il fatto con il C# è che non piace a *nessun* programmatore. O meglio,
anche se a lui può piacere, comunque ritiene che ci siano alternative
migliori.
Il motivo del perché viene utilizzato molto più di quanto sia "logico"
va ricercato in campi che esulano dai campi specifici degli
utilizzatori finali (come "esigenze di mercato" o "sinergia" o "chi-lo-
sa-di-cosa-parlano-io-scrivo-solo-codice", che si traduce in
"rimozione di supporto e documentazione per sistemi precedenti",
"marketing e propaganda a chi prende decisioni tecniche senza avere
una base applicativa", "sviluppo di nuove librerie non
retrocompatibili e solo sotto nuove tecnologie").
Che tutto questo faccia schifo nemmeno lo dico, ma del resto anche
scrivere codice è, in generale, un bel lavoro di m**da. :D
Ciao!

 migliori.
non è che semplicemente i prodotti microsoft stanno perdendo terreno?
Tante applicazioni oggigiorno vengono sviluppate come webapp e in questo
caso utilizzare 
asp.net
 ti lega a windows server... senza contare che
non da vantaggi rispetto ad altre soluzioni.
se sviluppi sul desktop ad un livello medio alto devi tenere conto di
osx (e se sei buono di cuore tieni di conto pure di noi linux user),
però c'è tutta una fascia di mercato dove C/C++ non conviene (oh per
inciso secondo me in questa fascia non conviene nemmeno C# e si trova
una bella fetta infatti di sviluppatori visual basic) ossia programmi
gestionali che si interfacciano a dabase finti come i famigerati file di
oracle, automatizzazione di office e simili.
C'è da dire che una killer application scritta in C# non si è ancora
vista... ok 
paint.net
 o sharpdevelop prodotti utili, funzionali, fatti
bene, etc... ma non certo killer app, non roba che ti fa dire "urca vale
la pena di leggere qualcosa su questo framework!"

 oracle, automatizzazione di office e simili.
volevo scrivere file mdb di access! scusate avevo un istanza di oracle
jdeveloper aperta e c'è scappato un lapis!

 migliori.
E' forte come affermazione. In primo luogo conosco tanti a cui piace
davvero. E io posso dire che e' un immenso peccato quanto sia legato a
MS.
Personalmente del gruppo dei linguaggi imperativi statici trovo che sia
assolutamente il piu' avanti. Ti danno closures, named parameters,
properties, introspezione.
Il fatto che io rientri in quelli che trovano ci siano alternative
migliori e' dovuto al fatto che io adoro i linguaggi dinamici (python,
ruby) e quelli dichiarativi (scheme, haskell, prolog, erlang). Questo fa
di me un programmatore molto atipico.
Ma davvero, il mio *unico* dubbio sulla piattaforma e' legato al fatto
che sono poco interessato a Windows e non ho valutato vermanete come si
pone mono nel tutto (oltre al fatto che per quanto ci facciano, mono e'
pur sempre il "clone").
-- 
-riko

 la pena di leggere qualcosa su questo framework!"
Ripesco questa vecchia discussione OT per porre una domanda.
Se si vogliono sviluppare delle applicazioni client che girino sul trio
m$/linux/osx qual'è la scelta migliore? Java? Che vorrei evitare visto
chenon mi piace a causa della grande logorroicità e conosco di fatto poco.
Qual è il framework più agevole e stabile? Esiste? Magari da utilizzare in
congiuntamente al C?
Attualmente ho fatto qualcosa con wxPython, ma mi sono abbastanza stufato
visti i frequenti bug e incongruenze soprattutto su OSX.
Ciao,
Francesco
-- 
Hobbit
blupicchio chiocciola yahoo punto it
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 
la verità? nessuna tre client diversi ognuno con le proprie librerie
native, puoi avere una base di codice per comune (ad esempio i dati,
controllo e trattamento, e la logica applicativa) ma poi le varie gui
devono essere:
win32/mfc/wpf, cocoa, gtk/qt
puoi usare un framework come qt e su windows e linux stai abbastanza
tranquillo ma su osx pur essendo basato su cocoa non è uguale al 100%.
Quindi in logica mvc e c++:
model e controller in C++ ansi standard
gui:
osx => objc cocoa, objc consente di mischiare pure codice c++ quindi
puoi istanziare classi conttroller (le view al model non devono accedere).
win32 => mfc, gestione eventi con table event, cstring e affini (oppure
una gui windows form, wpf che si interfaccia tramite pinvoke al tuo
codice o altri sistemi affini)
linux => qt con tutto quello che si porta dietro (moc, signal slot etc)
e ti agganci al codice C++, stesso discorso con wxwidgets o gkt.
Oppure te ne sbatti e usi wxwidgets o qt e buona notte se le
applicazioni sembrano native solo 99%.
Altra alternativa un framework gui su opengl così la tua applicazione
appare identica nei 3 ambienti ma diversa dalle app native (come ad
esempio fa blender) una libreria di questo tipo è nui:
http://www.libnui.net/
Questo solo per rimanere al C++
ma la logica si potrebbe applicare anche al C#
model e controllor in C#
view sempre in C# ma avendo tre interfacce basandosi su:
cocoa#, gtk#, wpf, ....
oppure java e swt
oppure realbasic
.
..
...
....
a me intriga sia la soluzione C++ e gui opengl
sia C# e le varie librerie (volendo hai pure monotouch per port su
iphone e presto qualcosa pure su android, sia chiaro che a me come
linguaggio il C# piace)


Io uso wxWidgets e va benissimo!
Non devi fare eccessive modifiche per i vari target e ti da un framework 
abbastanza completo.
Ci sono però delle limitazioni sui tipi di controlli che puoi utilizzare 
ma se non hai necessità strane, fa al caso tuo.

 ma se non hai necessità strane, fa al caso tuo.
mah
su osx nessun framework si comporta molto bene, men che meno wxwidgets
che sulle release stabili è ancora basato su carbon.
La versioni in via di sviluppo si basano su cocoa ma non sono ancora
complete al 100%.
Il problema sta su alcune versioni di osx in particolare 10.6 dove è
praticamente impossibile compilare versioni di carbon della libreria e
devi ripiegare su una release beta.
Che poi sia stabile e solida ok ma è comunque una beta.
Per dire...
Michelangelo

> 
http://www.libnui.net/
libnui sembra interessante. Non ho capito bene ancora come usarla, quanto
bene sia fatta la documentazione, particolare che considero importante.
Ho visto che ci sono i file di progetto per visual C e Xcode, per linux mi
sembra di aver capito che si affidi a cmake, giusto?
Diciamo che in generale vorrei un framework facile da usare in maniera da
concentrarmi sulla parte piů bella, l'algoritmo. Alla fine fare le cose
per hobby non deve risultare uno stress.... (parafrasando) .... se non č
un piacere che piacere č?!
Essendo nato prima dell'avvento alle masse della OOP vorrei stare il piů
possibile dentro il C lasciando fuori il C++ (se possibile ovviamente)


 ma se non hai necessità strane, fa al caso tuo.
Con il wrapper per Python e OS X ho avuto i miei buoni problemi. Mi chiedo
se la versione nativa funzioni meglio.


 
Se vuoi lasciare fuori il C++, direi che ti restano solo le librerie gtk
(che sono quelle di gnome, gimp, inkscape e le usa pure google chrome
per linux) ma anche queste, se pur con tutti i limiti del linguaggio,
cercano di "mimare" un approccio oop in puro C.

 tranquillo ma su osx pur essendo basato su cocoa non è uguale al 100%.
Se ci lavori bene, puoi tranquillamente farcela. Certo, non facilmente
come con Cocoa. 
-- 
-riko

 se la versione nativa funzioni meglio.
No. E' wx che fa schifo. 
-- 
-riko

 Io uso wxWidgets e va benissimo!
Se ignori OS X, si.
-- 
-riko