Newsgroup: it.comp.lang.c++
Titolo: Oggetto DataGrid Control Version 6, (OLEDB)

Qualcuno sa dirmi come utilizzare tale oggetto?
Ho l'esigenza di inserire dei dati in una griglia in esecuzione, ed in VB
riesco a farlo benissimo
utilizzando il DataGrid Control, ma in Visual C++ non riesco a farlo.
Conoscete qualche esempio o sapete darmi qualche suggerimento?
Grazie!!!

Ciao,
Questo newsgroup si occupa del linguaggio C++ in quanto tale, e non di
aspetti specifici di particolari implementazioni. Per questo non e' il
posto piu' adatto per porre domande specifiche come la tua.
Potresti avere piu' fortuna su uno dei seguenti gruppi:
Per Win32 (95, 98, NT): it.comp.programmare.win32
Per Dos/Win 3.x: it.comp.os.dos
Per Linux:      it.comp.os.linux.development
Per C++Builder: i gruppi borland.public.cppbuilder.*, disponibili sul
                server 
newsgroups.borland.com
 (prevalentemente in 
                inglese, ma si puo' postare anche in italiano)
Grazie,
Nicola Musatti

 Per Dos/Win 3.x: it.comp.os.dos
[snip]
Ma hai un programmino che fa sto post in maniera automatica ????
-- 
Posted from [194.214.173.28] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 Ma hai un programmino che fa sto post in maniera automatica ????
Se lo avessi ce ne sarebbero molti di piu' :-)
Ciao,
Nicola

 Se lo avessi ce ne sarebbero molti di piu' :-)
incubo! ;)
ma non sarebbe meglio ignorare i post OT?
magari poi si fa un 'cazziatone' a chi tenta di affrontare argomenti OT ;-)))
ciao
xaero

 magari poi si fa un 'cazziatone' a chi tenta di affrontare argomenti OT ;-)))
Se rispondi subito i beneducati che non si sono resi conto che stavano
inviando un messaggio fuori tema ringraziano e si spostano altrove; i
maleducati si offendono e non postano piu' (a dire il vero a volte ci
vogliono insulti piu' diretti per farli desistere :-).
Almeno in questo posto ogni newbie non posta piu' di un messaggio OT.
Ciao,
Nicola

 Ciao,
l'unica cosa che ottieni e l'aumento dei messaggi inutili ....
sei un incubo bastaaaaaaaa


Come il tuo? Prova a contare quante persone tra quelle che hanno
ricevuto il mio messaggio hanno rispedito messaggi OT. Se non ti piace
trasferisciti su it.comp.programmare.win32 dove le tue domande preferite
sono in argomento.
Ciao,
Nicola


almeno il nome dovresti leggerlo,non sono io che ho scritto il messaggio
Cmq non mi riferivo tanto a questo ma all'insistenza del tuo messaggio che
infastidisce e in fin dei conti non ha parlato di patate
un po di tolleranza e che caspita
l'hai presa come un crociata per non so quale motivo assurdo......
va beh contento tu....

 un po di tolleranza e che caspita
Non mi sono spiegato bene: sono cosciente che non sei l'autore
originale, ma ho anche notato che di preferenza rispondi a domande che
qui sono OT. Per questo potresti trovare maggior rispondenza ai tuoi
interessi su i.c.p.w .
Sul fatto che il mio messaggio automatico infastidisca e' una questione
di opinioni. In generale in passato le persone che maggiormente
contribuiscono alla qualita' del gruppo mi hanno sempre incoraggiato.
Quanto alla tolleranza, mi pare che rispondere cortesemente a messaggi
che sono atti di maleducazione e di scarso rispetto verso chi frequenta
il newsgroup sia piu' che sufficiente.
Ciao,
Nicola

 sei un incubo bastaaaaaaaa
Non sono d' accordo...
Penso che invece quello di Nicola sia uno dei metodi migliori per fare 
capire alla gente che e' OT in modo pacato.
La tecnica di ignorare i messaggi OT non funziona per il semplice fatto che 
non tutti sanno che alcuni messaggi debbano essere ignorati perche' OT, e si 
generebbero quindi thread OT...
Del resto se hai capito il manifesto del NG quando leggi il sub di un nuovo 
thread OT sai gia' che c'e' il messaggio di Nicola pronto, ed eviti di 
leggerlo no ? :-)
Un discorso aparte potrebbe essere fatto sulla elasticita' di questi OT, 
anche se in questo caso specifico direi che ci sta tutta :-)
-- 
- Dado : Extreme Snowboarder
*-> I believe I can fly, I believe I can touch the sky <-*

 contribuiscono alla qualita' del gruppo mi hanno sempre incoraggiato.
questo newsgroup non è solo per i fans del tuo messaggio
ma cmq volevo chiudere la questione dicendo che dovresti mettere un prefisso
nell'oggetto
al tuo messaggio per evitarci di leggerlo ogni volta e filtrarlo magari
....(noi non fans ci annoiamo) :))
grazie

 contribuiscono alla qualita' del gruppo mi hanno sempre incoraggiato.
Non sono tra le persone che contribuiscono attivamente al newsgroup, ma lo
seguo quasi giornalmente, e mi associo al lungo elenco di coloro che ti
incoraggiano
Alessandro Bosetti

 ....(noi non fans ci annoiamo) :))
Il problema e' che alcuni newsreader creano un nuovo thread se il
subject cambia, e questo mi pare peggio.
Ciao,
Nicola

 va beh contento tu....
Non sono per nulla della tua stessa opinione.
Purtroppo qui non si fa altro che parlare di cose che non riguardano
il C++ e se non ci fosse nessuno che lo ricorda ad ogni nuovo entrato
si finirebbe per non parlare mai di C++.
Ad esempio una volta chiesi (non innocentemente) a tal
Maurizio Loreti: "perche' parli di puntatore NULL, cosa e' NULL"?
In un gruppo sul C++, fu una provocazione che stranamente
nessuno accolse.
Forse perche' la maggior parte della gente vuole solo che gli si risolva
il problema che un programma vada in core senza riflettere sul perche' ?


 nessuno accolse.
Dallo standard (18.1/3):
"The macro NULL is an implementation-defined C++ null pointer constant
in this International Standard ... Possible definitions include 0 and
0L, but not (void*)0."
Qualche volta anche noi pignoli sorvoliamo :-)
Ciao,
Nicola

 grazie
visto che usi Outlook Express, basta che ti crei una regola per le news, che
controla se mittente=="Nicola Musatti" e il messaggio contiene la frase
"Questo newsgroup si occupa del linguaggio C++ in quanto tale" ignora il
messaggio, oppure elimina il messaggio, o quello che vuoi.
non c'è nessun bisogno di creare complicazioni inutili.
--
ciao
xaero

 non c'è nessun bisogno di creare complicazioni inutili.
mi correggo.
ho detto una cavolata.
il controllo nel corpo del messaggio funziona solo per le regole e-mail.
sorry :)
--
ciao
xaero

 Nicola
Mmmmmmm non mi piace.
Continuo a provocare:
void f(int);
void f(int*);
se ora faccio:
f(NULL);
quale delle due verra' chiamata? uno si aspetterebbe la f(int*)!!!!!!
N.B. So quale verra' chiamata, e' giusto per fare una volta tanto
un thread costruttivo.


 quale delle due verra' chiamata? uno si aspetterebbe la f(int*)!!!!!!
Uno che *non* conosce bene il C++ :-) Se non sbaglio tempo addietro
propose una versione typesafe di NULL basata su template, qualcosa del
tipo:
template <typename T> struct { operator T * () { return 0; } } NULL;
(Non credo che fosse proprio cosi', ma rende l'idea)
Ciao,
Nicola

 funzioni della libreria standard.
Io invece sono per il contrario... 
In fin dei conti lo standard definisce NULL come 0 o 0L, e non usarlo solo 
per una adesione maniacale allo standard porta alla conclusione che molto 
probabilmente il codice sara' molto meno leggibile.
In fin dei conti nella vita reale non si programma solo codice "ideale" ma 
lo si deve anche far funzionare, e far mantenere...
Se togliessi tutti i NULL dal mio codice i miei colleghi mi sparerebbero 
nelle palle, perche' effettivamente meno leggibile. E quando devi finire un 
prodotto te ne freghi altamente che ai puristi del C++ "non piace piu' di 
tanto"... Soprattutto se vai a creare codice che sara' difficilmente 
mantenibile...
Secondo me c'e' modo e modo di aderire allo standard.


 probabilmente il codice sara' molto meno leggibile.
Non sono d'accordo. Chi *studia* il C++ *deve* sapere che in C++ i
puntatori nulli sono identificati da qualsiasi espressione costante
intera di valore zero, la piu' semplice delle quali e' per l'appunto 0 .
Usare invece una macro, inventata in C e che per svariati compilatori
era definita in un modo che in C++ non sarebbe stato valido non mi pare
un aumento di leggibilita'.
Tieni conto che questo uso dello zero e' stato introdotto proprio
perche' non era possibile avere la certezza che NULL fosse definita in
modo accettabile per il C++.
Mi riferisco al fatto che in talune implementazioni la definizione era
#define NULL (void *)0
In C++ pero' non esiste conversione automatica da puntatore a void ad
altri tipi di puntatori.
In soldoni quello che tu chiami leggibilita' a me pare piuttosto un
fraintendimento, ovvero una confusione rispetto al confine tra C++ e C.
Ciao,
Nicola

 un aumento di leggibilita'.
Lo sarebbe, almeno per chi programma da molto tempo...
Il mio esempio non era riferito alla definizione errata che alcuni 
compilatori assegnavano a NULL, ma alla sua leggibilta' quando questo e' 
corettamente definito 0 o 0L secondo lo standard.
A mio avviso se leggo una chiamata a funzione del tipo :
f(NULL, 0, NULL);
La leggo meglio che non :
f(0L, 0, 0L);
o peggio :
f(0, 0, 0);
Ed aderisco anche allo standard, qualsiasi programmatore farebbe piu' fatica
a leggere la seconda o la terza che non la prima.
Sul fatto che poi NULL possa essere error-prone poiche' non implica un cast 
a void* sono d'accordo.
Sul fatto che alcuni programmatori C++ non sanno che NULL non viene definito 
come (void*)0 sono altresi' d' accordo.


f(0, 0, 0);
per non parlare di
  f(false, 0, 0x1966-6502);
Scherzi a parte io mi sono abituato a usare 0 invece di NULL,
ma non vedo nulla di male nell'uso di NULL. Anzi... a volte uso
un po' l'uno e un po' l'altro (probabilmente la peggiore delle
cose... ma nelle chiamate delle API di Windows mi viene piu'
naturale seguire quello standard -- e comunque sono cose che
sono "entrate nelle dita" ;) ).
Io credo che sarebbe stato molto meglio in C++ eliminare la
possibilita' di usare espressioni costanti e accettare invece
solo literal (quale grado di liberta' dia l'uso di espressioni
costanti in questo contesto proprio non l'ho capito) se non
addirittura introdurre una bella keyword (magari 'NULL' ;) )
per questo scopo.
Credo che una keyword per il puntatore nullo sarebbe stata
meglio spesa che ad esempio la tutt'altro che essenziale 'mutable'.
Ho chiesto delucidazioni su questo punto in comp.lang.c++.moderated
senza pero' ottenere nessuna informazione utile.
Andrea
--
Andrea Griffini, Programmer
http://www.netservers.com/~agriff

 wrote in message
MPG.15ddbd7d6...@newsproxy.camb.scee.sony.co.uk...


magari poi si fa un 'cazziatone' a chi tenta di affrontare argomenti OT ;-)))
Secondo me no... il risultato e' che chi fa il posting
crede che nessuno lo abbia letto. Oppure si lamenta del
fatto di essere ignorato.
Il ero abbastanza convinto che il massimo della gentilezza
fosse rispondere se in grado e comunque ridirigere la
persona verso altri newsgroup dedicati... purtroppo ho
anche verificato che spesso una volta ottenuta la risposta
chi fa il posting semplicemente se ne va e ignora allegramente
l'errore commesso, con l'effetto di tornare in seguito a
fare domante OT senza nemmeno provare newsgroup dedicati.
Ora forse credo anche io che rimandare l'autore ad un
newsgroup dedicato sia in fondo la cosa piu' giusta...


 meglio spesa che ad esempio la tutt'altro che essenziale 'mutable'.
Perche' tutt'altro che essenziale ? 


 f(NULL, 0, NULL);
Io la leggerei in questo modo (penso che lo fai anche tu e i tuoi colleghi):
chiamo f con
1) il primo parametro puntatore 'null'.
2) secondo parametro 0.
3) terzo parametro puntatore 'null'.
Peccato che non corrisponde al vero, provare per credere
come ho gia detto se hai una funzione con overload
che prende tre interi viene chiamata quella.....
Se vuoi + leggibilita' la ottieni cosi':
TYPE1* type1Null = 0;
TYPE1* type2Null = 0;
f(type1Null, 0, type2Null);
e stai sicuro che se qualcuno in una libreria che usi
guarda caso ha definito f(int, int, int) non perdi una
settimana a capire cosa sta succedendo.


Perche' tutt'altro che essenziale ? 
Prima che venisse introdotta la keyword "mutable" quando ci
si rendeva conto che il concetto di "const-correctness" fisico
del C++ era troppo limitato si utilizzavano dei const_cast
per agire sui membri che era necessario modificare.
Onestamente il grande valore aggiunto da "mutable" non lo
vedo visto che comunque il compilatore non puo' fare assunzioni
riguardo al fatto che i membri di un oggetto acceduto
tramite un reference o puntatore a const non possono cambiare
(per via del possibile aliasing). Possono cambiare tutti da
una chiamata all'altra...
  struct X
  {
    int x1,x2;
    const void foo();
  };
  int bar(const X& a) // reference a const
  {
    int t=a.x1+a.x2;
    a.foo();         // metodo const
 
    int s=a.x1+a.x2; // <--- il compilatore e' comunque
                     // obbligato a rifare il calcolo
                     // anche se ha chiamato solo foo()
    return s-t;
  }
La keyword "mutable" e' fra l'altro un dettaglio implementativo
e il suo impatto e' di norma molto limitato (o cosi' dovrebbe
essere... a chi usa una classe non dovrebbe fregare un bel
niente del fatto che questa si tenga una cache o quali siano
i membri dati necessari per questa cache... non sono cose
belle da scrivere in un .h; lo si cerca di fare solo se
costretti da motivi specifici).
Questo e' il motivo percui secondo me il C++ non avrebbe
perso molta della sua usabilita' se non ci fosse stata la
keyword "mutable": non aiuta il compilatore e non aiuta un
granche' neanche i programmatori nemmeno nel ristretto ambito
per cui e' stata pensata. Con const_cast si sarebbe potuto
secondo me andare avanti benissimo.
Nota che non sto dicendo che "mutable" sia assolutamente
inutile o dannosa... solo che secondo me sarebbe stato
piu' importante avere una keyword per il puntatore nullo
visti i problemi subdoli che puo' generare.
Anche i template sono forse un'altra area in cui qualche
keyword in piu' avrebbe dato una mano piu' importante al C++
che "mutable" (solo un'impressione... non sono un esperto
di template-che-fanno-anche-il-caffe' ma credo che se nella
forma attuale le cose fossero cosi' semplici e chiare per i
compilatori non ci troveremmo ancora oggi -- lo standard e'
di qualche annetto fa -- con problemi seri di conformita';
credo di aver sentito che c'e' chi con cattiveria ha detto
che con le attuali specifiche formali per i template un
compilatore ha bisogno di una monetina per poter compilare
un programma C++).
Come nota finale di colore ti dico che ad esempio in tutti
gli include della libreria standard fornita con il BCC55
esistono un solo un paio di attributi mutable.
Tu sei invece convinto che si tratti di qualcosa di cosi'
essenziale ? Quali sono i motivi per cui non era sufficiente
continuare ad usare const_cast nelle parti di implementazione
dei metodi const ?


 incoraggiano
anche se questo mio post puo' essere a buon titolo essere annoverato tra i 
messaggi inutili mi associo anche io.
Anto
-- 
Antonio Cuni, 19 anni, studente
Brainbench C++ Master: 4.6, higher than 98% of all previous test takers.
C Language: 3.32, higher than 79% of all previous test takers.
Guida C/C++ di Programmazione.it: 
http://cpp.programmazione.it

 dei metodi const ?
Perche' puoi violare anche un const se hai in mano un oggetto const,
non solo se e' const "this". 
Ti diro', io toglieriei invece il const_cast!!
---
Gaetano


 messaggi inutili mi associo anche io.
Che inutili, fondamentali direi :-)
Ciao,
Nicola

Ti diro', io toglieriei invece il const_cast!!
E gli oggetti sullo stack. E i puntatori. E magari faresti
tutti i metodi virtuali e tutti gli oggetti che derivano
da un unico oggetto (in modo da poter creare contenitori
eterogenei). E un bel garbage collector!!! Eh?
Ma perche' non passi a Java allora ? :))))


 Ma perche' non passi a Java allora ? :))))
Ti diro' quasi quasi allo C#!
Bando alle min**iate mica ho detto che quella roba non mi e'
utile, anzi se un giorno dovessi diventare un javarolo non
so quanta gente mi riderebbe dietro... e poi per le applicazioni
che mi piace scrivere non vorrei che qualcuno di sua iniziativa
si metta a ripulirmi la memoria nel bel mezzo di una parte 
critica del programma dove mi serve tutta la CPU.


 le gambe.
a cosa ti riferisci in particolare?


Penso si riferisca in particolare all'ambiguita' tra inizializzazione
diretta e dichiarazione di funzione:
a b(c);
Secondo lo standard ogni qualvolta un'istruzione come la precedente puo'
essere interpretata come dichiarazione, deve essere interpretata come
tale.
Ciao,
Nicola



Il caso piu' semplice (e frequente, al punto di essere una FAQ) e'
quando si usa qualcosa come
   MyClass x();
credendo di definire una istanza e invece si sta solamente dichiarando
una funzione. Un caso un po' piu' subdolo e citato dallo standard e'
il seguente:
  struct S
  {
    S(int); // Costruttore
  };
  void foo(double x)
  {
    S w(int(x));
    // La riga precedente dichiara una funzione w
    // che accetta un parametro di tipo intero.
    // Le parentesi attorno al nome del parametro sono
    // considerate superflue e ignorate, come anche
    // il nome del parametro viene ignorato.
  }
Se poi si aggiunge al cocktail anche la forma senza "*" di
dichiarazione di puntatore a funzione si possono raggiungere
livelli veramente assurdi. In C come in C++ infatti e'
possibile dichiarare indifferentemente:
   void foo(int (*f)()); // puntatore a funzione
   void foo(int (*)());  // idem ma senza nome
   void foo(int f());    // sempre puntatore a funzione
                         // (forma implicita)
   void foo(int ());     // idem ma senza nome (!!!)
Il tutto puo' portare a cose come (esempio tratto da
"Effective STL"):
  void foo()
  {
    ifstream dataFile("ints.dat");
    list<int> data(istream_iterator<int>(dataFile),
                   istream_iterator<int>());
    ...
  }
Questo codice, in apparenza, sembra voler leggere il
contenuto di un file (interi) in una lista chiamata
"data". Purtroppo pero' il C++ fa un altro ragionamento:
buona la prima istruzione di apertura file infatti la
seconda puo' invece essere interpretata come dichiarazione!
La dichiarazione e' quella di una funzione chiamata
"data" che restituisce una lista di interi e che accetta
due parametri: il primo e' un istream_iterator<int> (il
nome del parametro e' "dataFile" ma viene ignorato, come
le parentesi extra attorno al nome) il secondo invece
e' un puntatore a funzione che non accetta parametri
e torna un istream_iterator<int> (dichiarazione di
tipo 4 con puntatore implicito e senza nome parametro).
Il risultato e' che non si ottiene nessun errore di
compilazione in quel punto ma il simbolo data viene
ad avere tutt'altro tipo (voleva essere solo una lista
di interi e invece e' una funzione). Questo si tradurra'
molto probabilmente in 2/3 mila caratteri di improperi
quasi incomprensibili al primo successivo uso di
quella variabile con ulteriore depistaggio del
programmatore che cerchera' il problema nel posto
sbagliato (ovvero nel successivo uso e non nella
dichiarazione di "data" visto che quella ha compilato).
La cosa che mi spaventerebbe un po' se dovessi
scrivere un compilatore C++ e' questa sintassi in cui
l'ultima virgola di un costrutto complesso e' in grado
di cambiare il significato logico di cose anche molto
distanti. Per fare un esempio i parametri passati
potrebbero essere 5, tutti ambigui e un "1" aggiunto
in coda. Quel semplice "1" renderebbe impossibile
considerare l'intera espressione come dichiarazione
e quindi l'unica possibilita' e' quella che si
tratti di una definizione con inizializzazione.
Questo pero' significa che durante l'analisi del
costrutto, quando ad esempio venivano incontrate le
parentesi "extra", il compilatore deve tenere il piede
in due staffe sino a quella profondita' ... se in fondo
trova un "1" allora si tratta di parentesi non extra e
con un significato se invece questo "1" non c'e' e il
tutto e' ambiguo allora quelle parentesi sono extra
e il significato e' completamente diverso.
Non c'e' da stupirsi se gli implementatori di
compilatori hanno avuto e hanno qualche problema con
il parsing del C++.
Un possibile workaround per la dichiarazione di prima e'
ad esempio aggiungere un paio di parentesi in modo da
mettere fuori gioco la possibilita' che si tratti di una
dichiarazione di funzione:
  void foo()
  {
    ifstream dataFile("ints.dat");
    list<int> data((istream_iterator<int>(dataFile)),
                   istream_iterator<int>());
    ...
  }
Pero' Meyers sullo stesso testo informa che ha avuto a
che fare anche di recente con compilatori in cui il
sistema non funzionava e in cui, addirittura, la
dichiarazione veniva interpretata con il giusto significato
*solo* se le parentesi *NON* erano presenti (il contrario
di quando dicono le regole).
