[C++]Unire più file .exe

[cdimauro]

Originariamente inviato da fek

Non credo finche' avro' un po' di senso critico.
Cesare, ormai consigli Python per tutto e questo dovrebbe farti suonare un campanello d'allarme. E' come se consigliassi di usare sempre un martello perche' ti ci trovi bene a piantare chiodi. Ma se provi a tagliartici le unghie dei piedi ti fai male

Non mi sembra d'aver consigliato di scrivere s.o. o driver con Python finora: il dominio applicativo è sempre stato tranquillamente alla portata di questo linguaggio.

Quando comincerò a farlo, siete autorizzati a chiamare la neuro.

Originariamente inviato da cionci

Infatti ho consigliato C#

Che non ho mai considerato un pessimo linguaggio mi pare. A me piacciono i linguaggi managed, solo che fra questi prediligo quelli più semplici e produttivi.

Originariamente inviato da 71104

non capisco ora come sia saltata fuori questa cosa dell'ottimo programmatore,

E' una consecutio: non si arriva a scrivere driver dalla mattina alla sera.

comunque:

1) non hai la minima idea delle proporzioni dei vari tratti della curva d'apprendimento; se per imparare a programmare in paradigma procedurale basta una settimana, per imparare a scrivere drivers sensati e che non diano schermata blu appena caricati... ma che dico, anche solo per caricare un driver nel kernel di Windows, servono un paio d'anni; se credi che sia un'esagerazione ti sbagli.

Ho già letto diverse volte i tuoi commenti in merito.

viste le proporzioni ed ipotizzando un niubbo (cioè uno a digiuno totale) che si ponga come obiettivo la realizzazione di un driver funzionante, consigliare di partire da Python è completamente fuor di luogo, è un allungamento inutile dei tempi; gli stai consigliando di imparare qualcosa che non gli servirà e che si potrebbe forse identificare come ciò che tu definisci l' "essere un ottimo programmatore".

Posto che gli auguro di non sviluppare mai un driver, con Python potrebbe apprendere velocemente a programmare e formarsi senza i tanti sbattimenti che trovi con linguaggi come C, C++ et similia.

Se, una volta maturato come programmatore, dovesse sentire l'esigenza di scendere così a basso livello, nessuno gli impedisce di imparare altri dettagli e altri linguaggi.

Ma al momento, come dici, è a totale digiuno e non sappiamo nemmeno se si fermerà al classico "Hello, world!"...

2, 3) embè?

Vedi all'inizio.

chiarissimo: non hai mai scritto drivers per Windows.
(e ora mi spara "per Windows no, ma su <esotica architettura anni '70 di un mondo che non c'è più, stile bus dati a 4 bit> programmavo col generatore di segnali digitali: davo in input uni e zeri e costruivo man mano gli opcode del codice macchina ")

No, non ho mai scritto driver per Windows e mi ritengo fortunato.

Originariamente inviato da 71104

un driver è un programma strano: è totamente privo di logica se non per un paio (a dir proprio tanto) d'algoritmi che può capitare di dover implementare in qualche routine e che sono descritti passo passo su MSDN in una maniera a prova di deficiente (praticamente leggi la descrizione del codice in inglese: "chiama questo passandogli questo e quest'altro, chiama quell'altro..."). un driver è solo un sacco di entry points che ti vengono chiamati e all'interno dei quali devi fare determinate cose, dettagliatamente descritte nello stile di cui sopra.

Chiaro. Il concetto di driver mica è cambiato con Windows.

stando così le cose i segmentation fault e le doppie delete sono praticamente impossibili, purché al programmatore sia chiaro quale routine di deallocazione vada associata a quale routine di allocazione (e questo Python non te lo insegna).

Lo puoi imparare dopo, quando ti servirà.

Comunque se puoi scrivere un driver con un qualunque linguaggio .NET, sulla carta puoi benissimo farlo anche con IronPython. Poi bisogna vedere se e quanto sarebbe conveniente farlo, ma qui fermo per mancanza di esempi e/o documentazione in materia.

[gugoXX]

Originariamente inviato da cdimauro

Che non ho mai considerato un pessimo linguaggio mi pare. A me piacciono i linguaggi managed, solo che fra questi prediligo quelli più semplici e produttivi.

cdimauro, penso che tu lo conosca quindi il C#.
Non ho trovato ancora un esempio in cui Python possa essere preso a modello per risolvere un problema piu' velocemente o piu' "elegantemente" del C#.
Mi aiuti a trovare qualcosa?

[cdimauro]

Non riguarda proprio C#, ma intanto puoi provare a leggere questo http://www.mindviewinc.com/downloads...LovePython.zip documento di Bruce Eckel.

Per quanto riguarda la "misura" della produttività, bisognerebbe fare delle prove. Io sono disponibile, eventualmente non si riescano a trovare in giro.

[gugoXX]

Certo che paragonare un linguaggio nuovo con uno vecchio di 30 anni (il C fra poco spegne 30 candeline) non mi sembra proprio equo.
E ho anche tanto l'impressione che il sig.Eckel il C# non l'abbia mai neppure aperto. (Annoiato perche' il C# ha tolto tutte le cose interessanti del C? E quali sarebbero le cose piu' interessanti del C, quelle che il C# ha tolto e il Phyton ha invece tenuto?)

Penso che il documento che mi hai passato non sia il campo giusto d'indagine. Il messaggio che mi ha passato e' che il Phyton e' un linguaggio adatto a chi non sa fare le cose e vuole farle velocemente.
Non e' pero' lo scopo degli addetti ai lavori. Un addetto ai lavori che "Si dimentica come fare per leggere un file" nel linguaggio di programmazione che usa per scopo professionale, mi sa che ha sbagliato mestiere.

Il C# comunque e'
byte[] eccoli = File.ReadAllBytes("Pippo.dat"); // se vuoi tutti i byte del file
string pippo = File.ReadAllText("Pippo.txt"); // se vuoi che ti venga invece restituita una stringa, supposto il file come file di testo.
Senza aprire, chiudere, dichiarare o fare alcunche'.
Se non se lo ricorda gli consiglio prima un corso di inglese, e poi di informatica.

Davvero, questo x10 nei confronti del C# non lo vedo proprio.

[cdimauro]

Quella presentazione è del 2001.

Gli esempi che hai fatto, ma in Python:

eccoli = open('Pippo.dat').read()
pippo = open('Pippo.Txt').readline()

Basta scriverli così come sono, e... funziona tutto.

Mi faresti vedere il sorgente completo in C# per eseguire quanto hai scritto prima?

Comunque sono esempietti. Vogliamo prendere qualcosa un po' complesso della banale lettura di qualche dato? Mettiamoci almeno qualche operazione di filtraggio / manipolazione, no?

[gugoXX]

Originariamente inviato da cdimauro

Quella presentazione è del 2001.

Gli esempi che hai fatto, ma in Python:

eccoli = open('Pippo.dat').read()
pippo = open('Pippo.Txt').readline()

Basta scriverli così come sono, e... funziona tutto.

Mi faresti vedere il sorgente completo in C# per eseguire quanto hai scritto prima?

Comunque sono esempietti. Vogliamo prendere qualcosa un po' complesso della banale lettura di qualche dato? Mettiamoci almeno qualche operazione di filtraggio / manipolazione, no?

Chiaro, solo esempietti, comunque e' proprio tutto li'

using System;  
using System.Collections.Generic;
using System.Text; 
using System.IO; 

namespace Stampofile
{ 
    class Program
    {
        static void Main(string[] args)
        {
            string pippo = File.ReadAllText("Pippo.txt");
            Console.WriteLine(pippo);
        }
    }
}

Le uniche 2 righe che ho scritto io sono proprio quelle li', dentro la Main.
Il resto e' stato scritto da lui, appena dopo aver creato un nuovo Programma di tipo "Console Application"

Per intenderci, il C# non e' stato studiato per fare Console Application, ovvero programmi su linea di comando. Il contorno sarebbe stato quasi tutto "bypasato" se il C# sapesse fare solo quello e se quindi molte di quelle cose fossero implicite.

Vogliamo provare a fare la stessa cosa scrivendo in una bella Finestra o applicazione grafica il contenuto del testo, in un controllo a piacere, tipo una TextBox? Anche senza alcuna interazione utente. Parte, legge pippo.txt e mette tutto il testo su una zona a piacere di una finestra.

Per condire il tutto, vogliamo poi invece provare a stampare magari, invece del testo, il numero delle 'a' che sono presenti nel testo letto? (Giusto per accogliere la tua proposta di cucinare i dati). Meglio se gli esempi li cerchi tu, io sono piu' bravo a risolvere gli esercizi piuttosto che inventarli.
E comunque per me non e' che "vince" chi scrive meno righe. Non mi interessa.
Secondo me vince chi scrive la cosa che si legge meglio oppure che usa un modo che difficilmente puo' portare ad errori di programmazione (peggio ancora errori che si beccano a RunTime come nel javascript)

[cionci]

Originariamente inviato da gugoXX

Le uniche 2 righe che ho scritto io sono proprio quelle li', dentro la Main.

Ora Cesare ti dirà che in Python bastano solo due righe senza il contorno perché Python è multiparadigma.
Una delle critiche che muovo a Python è proprio questa: permette di mescolare paradigmi diversi di programmazione, questa cosa cosa creerà problemi a chiunque debba iniziare a programmare con Python. Agli stessi livelli di chi inizia con C++.

[cdimauro]

Originariamente inviato da gugoXX

Chiaro, solo esempietti, comunque e' proprio tutto li'

using System;  
using System.Collections.Generic;
using System.Text; 
using System.IO; 

namespace Stampofile
{ 
    class Program
    {
        static void Main(string[] args)
        {
            string pippo = File.ReadAllText("Pippo.txt");
            Console.WriteLine(pippo);
        }
    }
}

Le uniche 2 righe che ho scritto io sono proprio quelle li', dentro la Main.
Il resto e' stato scritto da lui, appena dopo aver creato un nuovo Programma di tipo "Console Application"

Per intenderci, il C# non e' stato studiato per fare Console Application, ovvero programmi su linea di comando. Il contorno sarebbe stato quasi tutto "bypasato" se il C# sapesse fare solo quello e se quindi molte di quelle cose fossero implicite.

C# è un linguaggio non un IDE.

Vogliamo provare a fare la stessa cosa scrivendo in una bella Finestra o applicazione grafica il contenuto del testo, in un controllo a piacere, tipo una TextBox? Anche senza alcuna interazione utente. Parte, legge pippo.txt e mette tutto il testo su una zona a piacere di una finestra.

Non ho mai scritto applicazioni dotate di GUI in Python, quindi non potrei proseguire col confronto, a meno che qualcuno che c'abbia già lavorato non mi dia una mano (o sia lui stesso a "raccogliere la sfida").

Per condire il tutto, vogliamo poi invece provare a stampare magari, invece del testo, il numero delle 'a' che sono presenti nel testo letto? (Giusto per accogliere la tua proposta di cucinare i dati). Meglio se gli esempi li cerchi tu, io sono piu' bravo a risolvere gli esercizi piuttosto che inventarli.

Ecco qui:

print 'Nel testo letto ci sono %s caratteri a' % len([Ch for Ch in pippo if Ch == 'a'])



Comunque se definisco io i problemi da risolvere poi sarei tacciato d'esser di parte. Che lo faccia qualcun altro, che è meglio.

E comunque per me non e' che "vince" chi scrive meno righe. Non mi interessa.
Secondo me vince chi scrive la cosa che si legge meglio oppure che usa un modo che difficilmente puo' portare ad errori di programmazione (peggio ancora errori che si beccano a RunTime come nel javascript)

Qui stai già ponendo altre condizioni. Prima si parlava di produttività in quanto tale.

Originariamente inviato da cionci

Ora Cesare ti dirà che in Python bastano solo due righe senza il contorno perché Python è multiparadigma.
Una delle critiche che muovo a Python è proprio questa: permette di mescolare paradigmi diversi di programmazione, questa cosa cosa creerà problemi a chiunque debba iniziare a programmare con Python. Agli stessi livelli di chi inizia con C++.

No, ti dico che Python è un linguaggio a oggetti "puro", dove con ciò intendo che qualunque cosa è un oggetto.

Il poter esprimere dei concetti attraverso dei "paradigmi" è una semplice conseguenza logica delle PROPRIETA' che questi oggetti di Python mettono a disposizione.

Il concetto mi pare decisamente diverso, non trovi?

E problemi, comunque, non ne comporta. Non vedo perché dovrebbe comportarne. Se hai qualche esempio, fallo pure...

[cionci]

Originariamente inviato da cdimauro

C# è un linguaggio non un IDE.

C# e tutti i linguaggi .Net di MS sono fra i pochi che si possono identificare con l'ide. Chi programmerà in C# su Windows avrà sicuramente Visual Studio o Visual Studio Express.

Originariamente inviato da cdimauro

print 'Nel testo letto ci sono %s caratteri a' % len([Ch for Ch in pippo if Ch == 'a'])

Della serie: buttiamo a mare tutta quanto detto sulla leggibilità e sulla manutenibilità del codice.

[cdimauro]

Originariamente inviato da cionci

C# e tutti i linguaggi .Net di MS sono fra i pochi che si possono identificare con l'ide. Chi programmerà in C# su Windows avrà sicuramente Visual Studio o Visual Studio Express.

Python è multipiattaforma. C# pure. Stai limitando volutamente il dominio d'applicazione del linguaggio, e non mi pare giusto.

Della serie: buttiamo a mare tutta quanto detto sulla leggibilità e sulla manutenibilità del codice.

Non era l'oggetto del contendere, e comunque per chi ha masticato un po' di insiemistica a scuola la sintassi della list comprehension è facilmente intuibile.

[cionci]

Originariamente inviato da cdimauro

E problemi, comunque, non ne comporta. Non vedo perché dovrebbe comportarne. Se hai qualche esempio, fallo pure...

Non a te o a chi è padrone di altri linguaggi, ma a chi inizia Python come primo linguaggio: ho lodato per anni Java perché ti forzava ad esplicitare il paradigma di programmazione ad oggetti anche per un Hello World. Quindi rimango coerente con il mio pensiero: visto Python permette di mescolare programmazione procedurale e programmazione ad oggetti allora non è un bene per chi inizia, mi sembra che sia un ragionamento lineare, no ?

[cionci]

Originariamente inviato da cdimauro

Python è multipiattaforma. C# pure. Stai limitando volutamente il dominio d'applicazione del linguaggio, e non mi pare giusto.

Davvero c'è qualcuno che usa a livello produttivo C# su piattaforme diverse da Windows ? Se c'è qualcuno lo fa solo per la comodità di non doversi imparare un altro linguaggio.

[cionci]

Originariamente inviato da cdimauro

Non era l'oggetto del contendere, e comunque per chi ha masticato un po' di insiemistica a scuola la sintassi della list comprehension è facilmente intuibile.

Produttività va a braccetto con manutenibilità e leggibilità, imho Posso anche essere 10 volte più veloce in Python a scrivere un programma, ma se dopo un mio collega che lo legge e lo deve modificare è 10 volte più lento ho perso qualsiasi vantaggio di produttività.

[cdimauro]

Riccardo, mi riquoto:

Python è un linguaggio a oggetti "puro", dove con ciò intendo che qualunque cosa è un oggetto.

Il poter esprimere dei concetti attraverso dei "paradigmi" è una semplice conseguenza logica delle PROPRIETA' che questi oggetti di Python mettono a disposizione.

In soldoni: con Python lavori sempre e soltanto con OGGETTI, che ti mettono a disposizione delle PROPRIETA'.

In Java quando scrivi

int a = 1;

a NON è un oggetto.

Mentre in Python

a = 1

a contiene un oggetto.

I paradigmi di programmazione vengono fuori esclusivamente da come il programmatore utilizza gli strumenti / costrutti sintattici / oggetti (nel caso di Python, in particolare) che il linguaggio mette a disposizione.

[cdimauro]

Originariamente inviato da cionci

Davvero c'è qualcuno che usa a livello produttivo C# su piattaforme diverse da Windows ? Se c'è qualcuno lo fa solo per la comodità di non doversi imparare un altro linguaggio.

Mono non è per Windows, o sbaglio?

E non esiste soltanto perché qualcuno ha deciso di imparare un altro linguaggio.

Originariamente inviato da cionci

Produttività va a braccetto con manutenibilità e leggibilità, imho Posso anche essere 10 volte più veloce in Python a scrivere un programma, ma se dopo un mio collega che lo legge e lo deve modificare è 10 volte più lento ho perso qualsiasi vantaggio di produttività.

Certamente, ma tu stai facendo assunzione su cosa PER TE è leggibile oppure no.

Sei abituato a un approccio procedurale e/o a oggetti, non a uno funzionale / matematico, per cui un qualunque (perché Python non è certo il solo; tutt'altro) linguaggio permette di "operare" con insiemi di dati con costrutti come quello che ho usato ti sarà sempre poco leggibile.

Un matematico o una persona con una certa estrazione non la penserà certamente come te.

[gugoXX]

Comunque questa e' una soluzione "normale" in C#
che ritengo leggibile e di facile scrittura per quasi tutti.

string pippo = File.ReadAllText("Pippo.txt");

int t = 0;
foreach (char ch in pippo)            
    if (ch == 'a') t++;
            
Console.WriteLine("Ecco i caratteri 'a': "+t);

Se invece vogliamo fare i fighi, anche in C# si possono fare cose carine.
Restano comunque leggibili, e per chi le sa maneggiare sono anche molto potenti.

string pippo = File.ReadAllText("Pippo.txt");
int res=pippo.Where(u => u == 'a').Count();
Console.WriteLine("Ecco qui di nuovo i caratteri 'a': "+ res);

Dove quella u si legge
Prese pippo, estrai tutti i caratteri di pippo. Un carattere u e' da estrarre se e solo se u e' uguale ad 'a'. (E fino a li' abbiamo ancora una stringa).
Poi estrai invece il conteggio. Il conteggio restituisce un intero.

Ovviamente si puo' mettere anche qui tutto sulla stessa riga se vuoi, ma a me non piace proprio per nulla.
Quale e' il vantaggio di farlo? Scrivo piu' in fretta?
Io questa la boccio, e se mi permetti boccio anche la tua che non ha avuto voglia di scrivere almeno 2 righe.

Console.WriteLine("Ecco qui di nuovo i caratteri 'a': "+ File.ReadAllText("Pippo.txt").Where(u => u == 'a').Count() );

Io sono della scuola
1 riga = 1 concetto
Se una riga stampa, non la faccio contare.
Se una riga conta, non la faccio leggere da file.

[gugoXX]

[quote=cdimauro;21740061]In Java quando scrivi

int a = 1;

a NON è un oggetto.

[/code]
in C' si'.
Anche a e' un oggetto.

[cdimauro]

pippo = open('Pippo.txt').read()

t = 0
for ch in pippo:
  if ch == 'a': t += 1

print "Ecco i caratteri 'a': ", t

Così va bene? Mi sembra comunque più semplice e leggibile di quanto hai scritto C#, e a cui manca tutto il "contorno".

[cionci]

Originariamente inviato da cdimauro

I paradigmi di programmazione vengono fuori esclusivamente da come il programmatore utilizza gli strumenti / costrutti sintattici / oggetti (nel caso di Python, in particolare) che il linguaggio mette a disposizione.

Scusa, ma questo mi sembra solo un modo per aggirare il problema. In Python puoi fare solo programmazione procedurale (anzi, anche programmazione senza alcun paradigma esplicito, cioè scrivendo codice direttamente nel "modulo", alla php tanto per intendersi) ? La risposta è sì, in Java puoi ? La risposta è no. Questo crea problemi a chi inizia con Python ? Secondo me la risposta è sì.

Originariamente inviato da cdimauro

Mono non è per Windows, o sbaglio?

Certo, mi riferivo proprio a Mono. Chi è tanto masochista da usare Mono su linux a livello produttivo ?

[cdimauro]

Originariamente inviato da cionci

Scusa, ma questo mi sembra solo un modo per aggirare il problema. In Python puoi fare solo programmazione procedurale ? La risposta è sì, in Java puoi ? La risposta è no. Questo crea problemi a chi inizia con Python ? Secondo me la risposta è sì.

Anche in Java puoi fare solo programmazione procedurale, ed è inutile che ti mostri in che modo, perché lo puoi immaginare.

In Python hai la possibilità, combinando gli oggetti che ti mette a disposizione, di simulare diversi paradigmi di programmazione.

Certo, mi riferivo proprio a Mono. Chi è tanto masochista da usare Mono su linux a livello produttivo ?

Non io, ma a quanto pare qualcuno lo usa: http://www.mono-project.com/Companie...o_uses_Mono.3F