[C++]Unire più file .exe

[cdimauro]

Non ho mai mancato di fornire argomentazioni, comunque.

Tra l'altro se ti vai a rileggere il thread, non sono intervenuto proponendo Python "a gamba tesa", ignorando il topic: ne ho parlato quando l'utente ha detto di essere completamente a digiuno di programmazione e aveva l'esigenza di IMPARARE A PROGRAMMARE. Cerchiamo di contestualizzare...

Quanto alla possibilità che sviluppi driver, beh, che dire: mi sembra DECISAMENTE PREMATURO.

Ci lamentiamo dei programmatori che "sovraingegnerizzano" il codice, perché "magari in futuro X, Y e Z potranno servire, anche se al momento non ce ne facciamo una mazza", e poi facciamo ipotesi su quello che in futuro (REMOTO, visto che scrivere driver non è certo roba da poco: vedi messaggi di Alberto) potrebbe fare uno che non sa nemmeno cos'è una variabile...

[cionci]

Quindi secondo te uno che inizia dovrebbe automaticamente cominciare con Python sempre e comunque ? Secondo me dipende anche dalle motivazioni per cui inizia a programmare.
Di conseguenza io ho consigliato C# per diminuire il suo percorso di apprendimento, visto che un giorno vorrebbe andare a lavorare a basso livello.
Credo che un percorso di apprendimento Python -> C# -> C++ sia ben più lungo di un percorso C# -> C++, nonostante la supposta facilità di apprendimento del Python rispetto al C#, soprattutto considerando la distanza fra questi due linguaggi.

[cdimauro]

Il concetto per me (lo sottolineo: è una mia opinione) è semplice: con Python imparerebbe più velocemente, e una volta acquisita la mentalità del programmatore passare a un altro linguaggio non sarebbe difficile.

E' una mia opinione, e l'ho semplicemente espressa, come fanno altri che propongo C#, Java, C++ (!), C (!!), assembly, ecc. ecc.

[fek]

Originariamente inviato da cdimauro

Ecco perché ti dico che con Python la shell (interattiva) è già inclusa, mentre con linguaggi come C# (o Java, che ha javac.exe per compilare e java.exe per eseguire l'applicazione) devi andare a cercare soluzioni di terze parti.

Io ti conosco come persona ragionevole, non in questa veste da Criceto, davvero.

Per usare Python da shell devi scaricare qualcosa? Si'. L'ambiente.
Per usare C# da shell devi scaricare qualcosa? Si'. Il programmino che ti fa da shell.

Che sia terze parti, prime parti, prodotto dal padre eterno in persona non cambia nulla, C# puo' essere usato da shell esattamente come Python scaricando l'apposito strumento. Con C# neppure ti serve l'SDK, ti basta il programmino. Come volevasi dimostrare.

[tomminno]

Originariamente inviato da ^TiGeRShArK^

beh..
ho paura solo ad immaginare cosa sia dato che il BELLISSIMO visual studio nemmeno mi rinomina il nome delle classi in seguito ad una copia e mi sono accorto che aveva fatto un casino tremendo solo una volta che ho riaperto il file originale e non funzionava + una mazza dato che avevo fatto refactor -> rename a manetta..

Cioè hai fatto copia e incolla del codice di una classe e lui non ha cambiato il nome della classe?
A me sembra un comportamento normale.
E suppongo anche che tu abbia fatto il refactor a diritto, per cui trovandosi con un conflitto di nomi 2 classi uguali nello stesso namespace ha fatto casini.

Forse in un caso simile potrebbe avvisare del problema e non eseguire le modifiche.

meno male che c'è il santissimo SVN altrimenti sarebbe stata la volta buona che sarei partito dritto dritto per redmond...

Con Ankh ci metti un secondo a tornare indietro.

Ma cazzarola..
Un editor completamente gratuito come eclipse fa 'sta cosa da tempo immemore..

Cioè se fai copia e incolla del codice di una intera classe lui ti rinomina la classe?
Personalmente non vorrei mai un comportamento simile.

possibile che nel 2008 ancora devo smazzarmi le cose a mano io?!?

Pensa che per il C++ non ci sono proprio strumenti di refactor...
E Refactor! effettua il refactoring solo all'interno del file cpp e relativo h, bello strumento di refactoring!
M$ prevede di fornire uno strumento di refactoring C++ per il successore del successore di VS2008

ah.. ovviamente mi è capitato proprio in questo istante... per questo da quasto post traspare tutto il mio "amore" verso visual studio....

Per linguaggi come C# (ovviamente), ma anche C++ devo ancora trovare un IDE migliore.

Se penso che sotto Linux non c'è un IDE C++ che abbia la possibilità di muovere a piacere l'istruzione attuale durante il debug, nè di visualizzare il contenuto delle classi... A volte mi chiedo come si faccia a sviluppare così.

La produttività di un linguaggio, secondo me, è legata anche all'IDE.

[gugoXX]

Originariamente inviato da tomminno

La produttività di un linguaggio, secondo me, è legata anche all'IDE.

Quoto.
Comunque a me basta l'intellisense e un robusto debug e sono contento.

Ho scoperto da poco che con VisualStudio posso piazzare breakpoint non solo sul codice C#, ma anche sul javascript e pure sul TSql delle stored procedure di Sql-Server.
In questo modo si puo' seguire tutta la catena dei 3 livelli, quando si deve andare a cercare un baco ben nascosto.

[mindwings]

Riporto un link che ho postato altrove dove ci sono delle considerazioni
interessanti fatte sa Steve Yegge

Qui le caratteristiche per un linguaggio mainstream :
http://steve-yegge.blogspot.com/2007...-language.html

in sintesi riporto : ( Edit: nel link vi sono le motivazioni per ogni Rule )

• Rule #1: C-like syntax.

• Rule #2: Dynamic typing with optional static types.

• Rule #3: Performance

• Rule #4: Tools

• Rule #5: Kitchen Sink

1. Object-literal syntax for arrays and hashes
2. Array slicing and other intelligent collection operators
3. Perl 5 compatible regular expression literals
4. Destructuring bind (e.g. x, y = returnTwoValues())
5. Function literals and first-class, non-broken closures
6. Standard OOP with classes, instances, interfaces, polymorphism, etc.
7. Visibility quantifiers (public/private/protected)
8. Iterators and generators
9. List comprehensions
10. Namespaces and packages
11. Cross-platform GUI
12. Operator overloading
13. Keyword and rest parameters
14. First-class parser and AST support
15. Static typing and duck typing
16. Type expressions and statically checkable semantics
17. Solid string and collection libraries
18. Strings and streams act like collections

• Rule 6: Multi-Platform

altre considerazioni :
I think a truly great language would support Erlang-style concurrency, would have a simpler syntax and a powerful macro system, and would probably have much better support for high-level declarative constructs, e.g. path expressions, structural dispatch (e.g. OCaml's match ... with statement) and query minilanguages. Among other things.The features I've outlined are basically the minimal set of requirements for not sucking. At least off the top of my head; I've probably overlooked a few.

[fek]

Originariamente inviato da ^TiGeRShArK^

beh..
ho paura solo ad immaginare cosa sia dato che il BELLISSIMO visual studio nemmeno mi rinomina il nome delle classi in seguito ad una copia e mi sono accorto che aveva fatto un casino tremendo solo una volta che ho riaperto il file originale e non funzionava + una mazza dato che avevo fatto refactor -> rename a manetta..
meno male che c'è il santissimo SVN altrimenti sarebbe stata la volta buona che sarei partito dritto dritto per redmond...
Ma cazzarola..
Un editor completamente gratuito come eclipse fa 'sta cosa da tempo immemore..
possibile che nel 2008 ancora devo smazzarmi le cose a mano io?!?
ah.. ovviamente mi è capitato proprio in questo istante... per questo da quasto post traspare tutto il mio "amore" verso visual studio....

Ti lamenti per poco. Usa Visual Studio su una codebase da 2M di loc e poi troverai nuovi significati al termine "frustrazione".

[^TiGeRShArK^]

Originariamente inviato da tomminno

Cioè hai fatto copia e incolla del codice di una classe e lui non ha cambiato il nome della classe?

no, ho proprio copiato il file dal solution explorer e l'ho incollato nella stessa directory.
Ovviamente non poteva avere un nome di file uguale essendoci già il file originale nella stessa directory.

A me sembra un comportamento normale.

A me no dato che il nome del file era uguale a quello della classe nel file originale.
Invece nel file di destinazione il nome della classe era uguale al nome del file originario.

E suppongo anche che tu abbia fatto il refactor a diritto, per cui trovandosi con un conflitto di nomi 2 classi uguali nello stesso namespace ha fatto casini.

Poi ho iniziato a lavorare con il designer (dato che era un Dialog) per modificare il secondo dialog, eliminando componenti che non mi servivano, aggiungendone altri e rinominandoli e mi è scoppiato tutto.
Ovviamente me ne sono accorto solo quando sono andato a riaprire il file originale nel designer....

Forse in un caso simile potrebbe avvisare del problema e non eseguire le modifiche.

eh.. mi pare anche il minimo

Con Ankh ci metti un secondo a tornare indietro.

what is Ankh?

Cioè se fai copia e incolla del codice di una intera classe lui ti rinomina la classe?
Personalmente non vorrei mai un comportamento simile.

Con eclipse se copi il file nella stessa directory ti rinomina anche la classe seguendo il nome del nuovo file.
Ma in effetti fa lo stesso anche se fai un semplice rename di file o se lo sposti di package.
Tutto in automatico e finora non mi pare mai di averlo visto creare casini.

Pensa che per il C++ non ci sono proprio strumenti di refactor...
E Refactor! effettua il refactoring solo all'interno del file cpp e relativo h, bello strumento di refactoring!
M$ prevede di fornire uno strumento di refactoring C++ per il successore del successore di VS2008

ennesimo motivo per non programmare in c++... come se non ce ne fossero già abbastanza

Per linguaggi come C# (ovviamente), ma anche C++ devo ancora trovare un IDE migliore.

Infatti pure io per .Net sto usando Visual Studio.......

Se penso che sotto Linux non c'è un IDE C++ che abbia la possibilità di muovere a piacere l'istruzione attuale durante il debug, nè di visualizzare il contenuto delle classi... A volte mi chiedo come si faccia a sviluppare così.

La produttività di un linguaggio, secondo me, è legata anche all'IDE.

yes..
l'IDE ti migliora di moltissimo la produttività.

[^TiGeRShArK^]

Originariamente inviato da fek

Ti lamenti per poco. Usa Visual Studio su una codebase da 2M di loc e poi troverai nuovi significati al termine "frustrazione".

e ci credo
per fortuna per progetti grandi ho sempre usato Eclipse...altrimenti mi sarei sparato credo
questo qui è un progettino da poche migliaia di LOCs

[tomminno]

Originariamente inviato da fek

Ti lamenti per poco. Usa Visual Studio su una codebase da 2M di loc e poi troverai nuovi significati al termine "frustrazione".

Esistono alternative più valide di VS in questi casi?

[tomminno]

Originariamente inviato da ^TiGeRShArK^

Poi ho iniziato a lavorare con il designer (dato che era un Dialog) per modificare il secondo dialog, eliminando componenti che non mi servivano, aggiungendone altri e rinominandoli e mi è scoppiato tutto.
Ovviamente me ne sono accorto solo quando sono andato a riaprire il file originale nel designer....

Ah! Le partial class
Avendo copiato il file lui ha preso come riferimento sottostante la stessa partial class (generata automaticamente dall'editor) del file originale.

In questo caso è un problema che niente ha a che vedere con il refactoring, questo è proprio un problema intrinseco del funzionamento del C# dal 2.0 in poi.

what is Ankh?

Plugin SVN per VS.

Con eclipse se copi il file nella stessa directory ti rinomina anche la classe seguendo il nome del nuovo file.
Ma in effetti fa lo stesso anche se fai un semplice rename di file o se lo sposti di package.
Tutto in automatico e finora non mi pare mai di averlo visto creare casini.

Java non usa le partial class per l'interfaccia grafica, generando sotto banco tonnellate di codice altamente incomprensibile, come fa C# per mezzo dell'editor.

ennesimo motivo per non programmare in c++... come se non ce ne fossero già abbastanza

Sinceramente a me il C++ piace e non capisco tutto questo astio nei confronti di questo linguaggio.

M$ sta spingendo il .NET e tutto il resto è rimasto fermo, quindi chi sviluppa in C++ è un cretino da trascurare.

[fek]

Originariamente inviato da tomminno

Esistono alternative più valide di VS in questi casi?

Si'. La preghiera.

[cdimauro]

Originariamente inviato da fek

Io ti conosco come persona ragionevole, non in questa veste da Criceto, davvero.

Per usare Python da shell devi scaricare qualcosa? Si'. L'ambiente.
Per usare C# da shell devi scaricare qualcosa? Si'. Il programmino che ti fa da shell.

Che sia terze parti, prime parti, prodotto dal padre eterno in persona non cambia nulla, C# puo' essere usato da shell esattamente come Python scaricando l'apposito strumento. Con C# neppure ti serve l'SDK, ti basta il programmino. Come volevasi dimostrare.

No, il programmino non ti basta. Hai dimenticato da dove è partito questo ramo della discussione. Ecco qui: http://www.hwupgrade.it/forum/showpo...&postcount=213

Della shell possiamo fare a meno, infatti. Il concetto è che io questo:

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

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

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

codice lo posso eseguire così com'è.

Io posso:
- aprirmi un prompt dei comandi e digitare python Pippo.py per lanciarlo;
- trascinare l'icona di Pippo.py nel file pythonw.exe;
- aprirmi un prompt dei comandi, digitare python senza argomenti per lanciare la shell interattiva, e incollare il codice di cui sopra;
- usare qualunque IDE che abbia scaricato da qualunque posto e darglielo in pasto.

Il sorgente non mi cambia di una virgola: è quello. La scelta di come farlo eseguire, è tutta mia.

In C#, oltre al codice "nudo e crudo" che ti fa il lavoro vero e proprio devi inserire il "contorno" di cui parlavo prima:

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

namespace Stampofile
{ 
    class Program
    {
        static void Main(string[] args)
        {
            // Qui ci sta il codice vero e proprio.
        }
    }
}

Detto ciò, non vedo cosa ci sia di irragionevole nell'affermare che il "pacchetto base" di Python sia costituito da VM, "compilatore" e librerie standard: sono cose che trovi in qualunque "distribuzione" di questo ambiente.

Per lavorare in C# almeno un compilatore da riga di comando MS te lo dà, Mono su Linux & OS X pure.

Non v'è, dunque, alcuna differenza: qualcosa per compilare il codice devi averlo, per poi poterlo eseguire. Questo è il concetto fondamentale e spero che almeno su questo saremo tutti d'accordo.

Della shell, infatti, possiamo farne a meno, non c'è problema: tanto la questione che era stata sollevata era un'altra, e cioé che il codice di cui sopra in Python non richiede nessun "contorno", qualunque sia l'ambiente sul quale lo farai girare: command line, shell interattiva, IDE, ecc.

Poi ognuno è libero di scaricarsi tutte le utility di questo mondo, non c'è problema.

[fek]

Originariamente inviato da cdimauro

No, il programmino non ti basta. Hai dimenticato da dove è partito questo ramo della discussione.

Non e' vero la Shell basta e avanza per eseguire codice C#.

Io posso:
- aprirmi un prompt dei comandi e digitare python Pippo.py per lanciarlo;
- trascinare l'icona di Pippo.py nel file pythonw.exe;
- aprirmi un prompt dei comandi, digitare python senza argomenti per lanciare la shell interattiva, e incollare il codice di cui sopra;
- usare qualunque IDE che abbia scaricato da qualunque posto e darglielo in pasto.

Esattamente come in C#.

Il sorgente non mi cambia di una virgola: è quello. La scelta di come farlo eseguire, è tutta mia.

Esattamente come in C#.

In C#, oltre al codice "nudo e crudo" che ti fa il lavoro vero e proprio devi inserire il "contorno" di cui parlavo prima:

Non devi, puoi. Quando usi una shell o un programmino di scripting e' perfettamente equivalente a Python quando usa una shell. Chi produce questo pezzo di software e' del tutto ortogonale alla soluzione del problema "Eseguire codice C# come un linguaggio di scripting".

Della shell, infatti, possiamo farne a meno, non c'è problema: tanto la questione che era stata sollevata era un'altra, e cioé che il codice di cui sopra in Python non richiede nessun "contorno", qualunque sia l'ambiente sul quale lo farai girare: command line, shell interattiva, IDE, ecc.

Quel codice di Python non richiede alcun contorno perche' quel contorno e' stato scritto da qualcun altro nell'interprete. Esattamente come quel contorno per C# puo' essere scritto da qualcun altro.

L'ambiente .NET, inoltre, ti fornisce la flessibilita' di poterlo (non doverlo) scrivere da solo dove necessario.

Stai facendo grossa confusione fra l'ambiente che fa da host al linguaggio, e la grammatica del linguaggio. Scrivere o meno quel contorno non e' una caratteristica del linguaggio, ma dell'ambiente nel quale questo linguaggio e' ospitato.

Mi sembra di discutere con Criceto :|

[cdimauro]

OK, quindi puoi scrivere questo:

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);

codice così com'è, e ti funzionerà?

Giusto per capire.

[cionci]

Fortunatamente no
Sono l'unico che on ci vede assolutamente alcun vantaggio nel poterlo fare ? Se ci fate caso è la stessa cosa che permette di fare il "blasonato" PHP

[fek]

Originariamente inviato da cdimauro

OK, quindi puoi scrivere questo:

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);

codice così com'è, e ti funzionerà?

Giusto per capire.

Assolutamente si'. Tutta la parte di Code Generation e CodeDom di C# e' ottima.

[cdimauro]

Originariamente inviato da cionci

Fortunatamente no
Sono l'unico che on ci vede assolutamente alcun vantaggio nel poterlo fare ? Se ci fate caso è la stessa cosa che permette di fare il "blasonato" PHP

Non è questione di vantaggio o meno: in Python non serve dover definire una classe con un metodo Main statico (come in Java) per poter lanciare un qualunque pezzo di codice.

La similitudine con PHP finisce qui: in Python ogni file è un modulo, con tutte le conseguenze del caso.

PHP, invece, è il degno erede del C: include a manetta.

Sono due approcci completamente diversi.

Originariamente inviato da fek

Assolutamente si'. Tutta la parte di Code Generation e CodeDom di C# e' ottima.

Mai sentito di queste cose: mi devo aggiornare.

Va bene, grazie

[fek]

Originariamente inviato da cionci

Fortunatamente no
Sono l'unico che on ci vede assolutamente alcun vantaggio nel poterlo fare ? Se ci fate caso è la stessa cosa che permette di fare il "blasonato" PHP

Non so sei l'unico, ma spesso e' volentieri poter generare codice da altro codice e compilarlo al volo (ovvero l'idea di base della shell della quale stavamo parlando) e' una cosa utilissima. Il sistema di generazione degli shader del quale parlavo, ad esempio, non e' altro che un generatore di codice HLSL, che usa il compilatore HLSL per generare i binari. Ma logicamente e' equivalente a generare codice C# (o leggerlo da tastiera, o da file, o da dove pare a Cesare ), compilarlo e eseguirlo.