[C++]Unire più file .exe

[cionci]

Tra l'altro il thread sul linguaggio da cui iniziare c'è già stato, inutile ripetere le stesse cose. Certo il richiedente non aveva le stesse tue esigenze.
http://www.hwupgrade.it/forum/showth...light=imparare

[Mazda RX8]

ragazzi, vi dovete mettere d'accordo...

[cdimauro]

Originariamente inviato da gugoXX

Vabbe' basta.
Lo faccio in C# (e qualcosa di C++/asm) proprio perche' cosi' poi studiamo i confronti di linguaggio.
A vista continuo a sostenere che non ci sia cosi' grande differenza.
spero che la CPUID possa essere usata anche dal ring3, altrimenti lascio.

Sì, l'avevo scritto prima che poteva essere usata.

Per intanto leggendo il tuo codice ho visto che devo restituire 4 registri e non 1 solo. Dal C++ lo saprei fare in modo semplice con una struct (cosi' evito marshaling pesanti verso il C#). Qualche altro suggerimento?

Mi spiace non averti potuto dare qualche suggerimento, ma generalmente non arrivo a stare in piedi fino alle 3 di notte.

Poi ho trovato un punto da migliorare ovvero la tua funzione
BitSetToStringList
Non ho ancora piena proprieta' di LINQ, ma se tutto va bene provo a stupirti un po' li'.

Ehm... Io non l'ho scritta con una sola riga usando un'opportuna list comprehension per non farmi randellare da Fran, perché altrimenti me ne sarei potuto uscire così:

def BitSetToStringList(Value, Names):
  return [Name for Shift, Name in enumerate(Names) if Name and ((Value >> Shift) & 1)]

Rivedendola non sembra (A ME!!! ) neppure tanto complessa e illeggibile, ma ho preferito evitare per i motivi di cui sopra.

I nibble fanno proprio pena pero' cribbio. Ma come gli e' venuto in mente? Usare i nibble... vabbe'. Mi sa che copio il tuo codice perche' non mi viene in mente nulla di meglio.

Vabbé, quella è la parte più semplice, perché in quel registro i primi 4 campi sono, appunto, dei nibble: ce ne sono altri che mi pare non siano usati, ma hanno un'ampiezza diversa da 4 bit.

Ho visto che ti sei passato il tempo stanotte e hai fatto un gran lavoro: complimenti.

Tornando a quanto decevi all'inizio del messaggio, personalmente, confrontando le due versioni, mi sembra più semplice e più leggibile quella in Python (e non ho messo nemmeno un commento ).
L'impressione che ho è che il messanismo tipo "LINQ" di C# che hai usato soffra di analoghi problemi di leggibilità di cui si lamentano gli altri per le list comprehension di Python, e che mi hanno costretto a usare una variabile locale di appoggio autoesplicativa per identificare il risultato dell'operaziome.

E' una prima impressione, comunque. Così, "a naso", come si suol dire.

Vediamo cosa dicono anche gli altri.

[cdimauro]

Originariamente inviato da Mazda RX8

ragazzi, vi dovete mettere d'accordo...

Confronta le due versioni e vedi quale ti sembra più semplice.

Fanno lo stesso lavoro (a parte quello in Python che calcola pure la frequenza della CPU usando un thread).

[cionci]

Originariamente inviato da Mazda RX8

ragazzi, vi dovete mettere d'accordo...

E' impossibile mettersi d'accordo

Ribadisco. Secondo me non fanno le stesse cose, se un giorno avessi la necessità di scrivere codice a basso livello in un linguaggio C-Style ci metteresti molto di più a passare da Python a quel linguaggio. Necessità messa in evidenza tra l'altro dal codice di Cesare: non a caso si è appoggiato ad una libreria esterna scritta in C++ per recuperare i dati relative alla CPU (e non tutti quelli che volevi te).

[cionci]

Originariamente inviato da cdimauro

Confronta le due versioni e vedi quale ti sembra più semplice.

Non puoi confrontare quei due programmi, non fanno le stesse cose. L'unico modo per confrontarli è usando la stessa libreria.

[cdimauro]

Originariamente inviato da cionci

E' impossibile mettersi d'accordo

Ribadisco. Secondo me non fanno le stesse cose, se un giorno avessi la necessità di scrivere codice a basso livello in un linguaggio C-Style ci metteresti molto di più a passare da Python a quel linguaggio. Necessità messa in evidenza tra l'altro dal codice di Cesare: non a caso si è appoggiato ad una libreria esterna scritta in C++ per recuperare i dati relative alla CPU (e non tutti quelli che volevi te).

Se avessi usato IronPython "consumando" il codice C++ per la CPUID non sarebbe cambiato niente.

Per il codice a basso livello è un discorso inutile, visto che finora è possibile tranquillamente "aggirare" il problema.

Originariamente inviato da cionci

Non puoi confrontare quei due programmi, non fanno le stesse cose.

Infatti il mio calcola anche la frequenza della CPU , ma togliendo questo fanno ESATTAMENTE la stessa cosa.

L'unico modo per confrontarli è usando la stessa libreria.

Non c'è problema: lo faccia qualcuno.

Tanto cambierebbe poco dal codice di gugoXX: invece di usare l'API scritta in C++, si usa quella di libreria. Amen.

[cionci]

Tanto ognuno resta della sua idea, inutile andare avanti

[gugoXX]

Originariamente inviato da cdimauro

Confronta le due versioni e vedi quale ti sembra più semplice.

Fanno lo stesso lavoro (a parte quello in Python che calcola pure la frequenza della CPU usando un thread).

Comunque prima di approcciare una parte funzionale di un linguaggio di programmazione e' bene che si impari la parte procedurale, con cui puoi fare comunque tutto.
Poi, (secondo me dopo qualche anno) potra' pensare a fare di piu', se quella e' la sua strada oppure se e' un matematico.
Non baserei la sua scelta sul fatto che la parte funzionale di uno o dell'altro sono piu' o meno belle.

Io, fossi in uno che deve iniziare oggi da zero, prenderei un qualsiasi linguaggio procedurale, anche brutto purche' semplice, e ci passerei sopra un po', per poi passare agli OO procedurali (e se poi proprio mi dovesse piacere, agli OO Funzionali).
Non che i funzionali siano indispensabili. Se ne puo' fare a meno.
Una volta capiti pero' il codice resta piu' compatto. Putroppo non sono sempre cosi' leggibili. Si potrebbero fare salti mortali con i funzionali, ma secondo me e' bene restare molto semplici proprio per evitare di dover perdere tempo prezioso a "capire" cosa si sarebbe voluto fare, magari durante fasi di Debug.

PS: Io i commenti li metto comunque sempre
E sono un fautore dell'arte del commento in azienda. C'e' chi sa commentare e chi non lo sa fare.
Quello che quasi tutti scrivono e' COSA sta facendo il codice
Tipo: Faccio un ciclo che sposta questo in quell'altro, accende un pixel e pulisce la memoria.
Putroppo non serve a nulla commentare cosi'. Lo vedo benissimo anche io cosa sta facendo quel codice.
Non e' necessario che me lo ripeti qui.
Quello che mi serve sapere e' PERCHE' hai fatto quelle cose.
Meno codice il piu' delle volte equivale meno errori

Fosse per me io partire con un linguaggio procedurale che non abbia bisogno di troppi tecniciscmi per partire.
Un paio di settimane o un mesetto di QBasic per esempio andrebbe bene, esistesse ancora.

Impara il concetto di variabile.
Stampa qualcosina a caso, leggi come fare per accettare cose da tastiera e stampare stringhe sul video.
Impara il costrutto IF..THEN..ELSE
Impara bene cosa sono e cosa servono gli array, che sono la base di tutto.
Impara il concetto di ciclo e come farlo nel linguaggio scelto.
Inizierei dal goto per esempio, capendo bene il suo funzionamento.
Capito cosa serve cercherei di capire i suoi problemi e quindi perche' si deve passare ai cicli controllati piu' complessi.
(Ho inziato con la famiglia Commodore, il cui Basic integrato in ROM aveva solo il goto (e le chiamate a subroutine). L'ho usato per 4 anni e sono ancora vivo)
Mescola questi concetti insieme e si possono gia' fare cose interessanti.

Il tuo target e' comunque molto lontano, ma non scoraggiarti.
Meglio, se vuoi puoi gia' copiare e incollare i pezzi di programma che abbiamo scritto finora. Ma e' come usare il pesce pescato da noi. Se vuoi la canna e' molto lontana.
Ma ricorda anche che questa canna puo' servirti non solo per divertirti (sempre se ti piace), ma anche proprio per mangiare.

[cdimauro]

Originariamente inviato da cionci

Tanto ognuno resta della sua idea, inutile andare avanti

Ma di quale idea parli? Ma dico, stiamo scherzando?

I due programmi sono FUNZIONALMENTE IDENTICI. A parte una piccola differenza di formattazione (e poi ovviamente i risultati diversi a causa delle due architetture su cui sono stati lanciati) FANNO LA STESSA COSA.

Tu, invece, ti stai fissando sul COME lo fanno. E questo mi sembra OVVIO, visto che i linguaggi usati sono DIVERSI, e si appoggiano a soluzioni diverse per prelevare i dati "grezzi" che servono.

Ma, come si suol dire, chi se ne frega? Il RISULTATO è quello, non si scappa.

Posto che l'output sia lo stesso, si possono confrontare le soluzioni nei due diversi linguaggi, e qui starà a Mazda giudicare.

x gugoXX: concordo (a parte sul goto, che ODIO ) e ti assicuro che per imparare a programmare Python è pure più semplice del QBasic, ma ti offre la possibilità di sperimentare, oltre che col paradigma procedurale, con quello funzionale, a oggetti e con la metaprogrammazione.

[cionci]

Non sono d'accordo sull'inizio in un linguaggio procedurale, secondo me il paradigma ad oggetti è egualmente intuitivo, anzi, molto spesso si può riportare più facilmente a paragoni con la vita quotidiana che fanno sicuramente bene alla comprensione.

[cionci]

Originariamente inviato da cdimauro

Ma di quale idea parli? Ma dico, stiamo scherzando?

I due programmi sono FUNZIONALMENTE IDENTICI. A parte una piccola differenza di formattazione (e poi ovviamente i risultati diversi a causa delle due architetture su cui sono stati lanciati) FANNO LA STESSA COSA.

Tu, invece, ti stai fissando sul COME lo fanno. E questo mi sembra OVVIO, visto che i linguaggi usati sono DIVERSI, e si appoggiano a soluzioni diverse per prelevare i dati "grezzi" che servono.

Ma, come si suol dire, chi se ne frega? Il RISULTATO è quello, non si scappa.

Posto che l'output sia lo stesso, si possono confrontare le soluzioni nei due diversi linguaggi, e qui starà a Mazda giudicare.

Che vuol dire scusa ? Ribadisco per l'ennesima volta il concetto. Se mi servisse un parametro a basso livello che non esiste in una libreria esterna come diavolo lo scrivo in Python ? Devo ad ogni costo imparare C++...e passare da Python a C++ non è facile, al contrario del passaggio da C# a C++.
Praticamente tutti i linguaggi permettono di utilizzare DLL esterne, allora qualsiasi linguaggio è ugualmente adatto a realizzare un'applicazione di monitoring hardware ?

[cdimauro]

Originariamente inviato da cionci

Che vuol dire scusa ? Ribadisco per l'ennesima volta il concetto. Se mi servisse un parametro a basso livello che non esiste in una libreria esterna come diavolo lo scrivo in Python ? Devo ad ogni costo imparare C++...e passare da Python a C++ non è facile, al contrario del passaggio da C# a C++.

E' inutile bagnarsi prima dell'acqua: è un'ipotesi, e pure molto remota.

Altrimenti facciamo una cosa: visto che gugoXX è dovuto ricorrere all'ASSEMBLY per invocare l'istruzione CPUID, facciamolo partire da questo linguaggio. Tanto se in futuro dovrà scendere a basso livello, gli servirà, giusto?

Praticamente tutti i linguaggi permettono di utilizzare DLL esterne, allora qualsiasi linguaggio è ugualmente adatto a realizzare un'applicazione di monitoring hardware ?

Dipende dal tipo di applicazione. Per programmi come quello che servono a Mazda e alla maggior parte della gente comune, penso di sì.

Su questa base poi è da vedere il COSTO della realizzazione dell'applicazione, e qui possiamo confrontare le soluzioni coi diversi linguaggi.

[gugoXX]

Secondo me Mazda dovrebbe capire che
imparare a programma
e
fare il suo programmino

Sono 2 cose molto distanti.
Non partirei a pensare cosa fare per imparare a programmare il piu' velocemente possibile per poter fare il mio programmino.
Se non ci fossero state le parti di WMI gia' pronte per C# o per IronPython, quindi se fossimo dovuti andare a prendere i dati dirattamente della SDK (Cosa che con il Python che stai usando tu cdimauro, dovresti fare o sbaglio?)
allora saremmo comunque in grado di farlo.
Ma l'ordine di complessita' e' molto piu' alto. Ci si deve sporcare le mani con chiamate di sistema, e quelle sono anche abbastanza incasinate.

Insomma, secondo me, se vuoi imparare a programmare dimentica il tuo programmino.
Se invece vorresti imparare a programmare solo per fare il tuo programmino, lascia perdere. Fatti un po' di copia incolla, impara come piazzare due textbox su una form (in C# o IronPython) e hai finito.

[cdimauro]

Originariamente inviato da gugoXX

se fossimo dovuti andare a prendere i dati dirattamente della SDK Cosa che con il Python che stai usando tu cdimauro, dovresti fare o sbaglio?) allora saremmo comunque in grado di farlo.
Ma l'ordine di complessita' e' molto piu' alto. Ci si deve sporcare le mani con chiamate di sistema, e quelle sono anche abbastanza incasinate.

Esattamente e, per quanto mi riguarda, fra chiamate di sistema o una DLL non c'è nessuna differenza.

Per il resto, concordo con quanto hai scritto.

[cionci]

Chiaro che non debba imparare a programmare per farsi il suo programmino, ma averlo in mente come obiettivo e fare le sue scelte di conseguenza secondo me è fondamentale. Anche solo per una questione di motivazione.

Comunque, visto che i dati sono a disposizione, perché non fate l'esatto equivalente di questo screenshot, interfaccia utente compresa ?
Almeno alla fine si chiarirà le sue idee e deciderà.

[shinya]

Originariamente inviato da Mazda RX8

ragazzi, vi dovete mettere d'accordo...

"Mettersi d'accordo" tra programmatori è un problema NP-completo.

[cdimauro]

Sull'interfaccia utente non c'ho mai lavorato, per cui chiederò aiuto a qualcuno che c'ha già smanettato.

Per le altre informazioni, appena ho un po' di tempo vedo dove poterle recuperare per Intel e AMD, e aggiorno il programma.

[cdimauro]

Originariamente inviato da shinya

"Mettersi d'accordo" tra programmatori è un problema NP-completo.

Peggio: è un problema indecidibile...

[Mazda RX8]

Originariamente inviato da gugoXX

Secondo me Mazda dovrebbe capire che
imparare a programma
e
fare il suo programmino

Sono 2 cose molto distanti.
Non partirei a pensare cosa fare per imparare a programmare il piu' velocemente possibile per poter fare il mio programmino.
Se non ci fossero state le parti di WMI gia' pronte per C# o per IronPython, quindi se fossimo dovuti andare a prendere i dati dirattamente della SDK (Cosa che con il Python che stai usando tu cdimauro, dovresti fare o sbaglio?)
allora saremmo comunque in grado di farlo.
Ma l'ordine di complessita' e' molto piu' alto. Ci si deve sporcare le mani con chiamate di sistema, e quelle sono anche abbastanza incasinate.

Insomma, secondo me, se vuoi imparare a programmare dimentica il tuo programmino.
Se invece vorresti imparare a programmare solo per fare il tuo programmino, lascia perdere. Fatti un po' di copia incolla, impara come piazzare due textbox su una form (in C# o IronPython) e hai finito.

io voglio imparare a programmare...