Perché ci sono così pochi esperti nel database MQL5? - pagina 9
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
'MyStruct' - la dichiarazione in avanti non è supportata
Ecco fatto. Come ci si libera delle dipendenze cicliche nell'architettura?
Non ditemi che non possono esistere in un'architettura normale. L'unico modo (stampella) è quello di ridisegnare l'architettura aggiungendo un mucchio di classi base non necessarie, che si trasforma in una vera rottura di palle a causa della mancanza di ereditarietà multipla, che hai rifiutato, come ho capito, per non preoccuparti di implementare le dipendenze a losanga.
Ma avresti potuto semplicemente implementare la dichiarazione...
Bene, vediamo se gli "utenti inesperti imparziali" sono in grado di scrivere "qualcosa di veramente fondamentale" in MQL5, al contrario dei "programmatori di sistema professionisti".
Dove ho scritto che non possono, mia cara? Sì, possono, ma sarà qualcosa di rozzo e pesante.
Ecco fatto. Come ci si libera delle dipendenze cicliche nell'architettura?
Non permettiamo ancora descrizioni in avanti a causa del sistema di sicurezza in casi d'uso complessi.
Abbiamo un linguaggio con controlli molto stretti sia in fase di compilazione che di esecuzione. Non possiamo permetterci di avere un codice potenzialmente difettoso a causa di controlli rilassati. Il punto è che queste descrizioni potrebbero essere in librerie completamente diverse e non c'è ancora un modo rigoroso per controllare l'uso in questi casi. Approssimativamente, sarebbe possibile (ora non si può fare) condurre un attacco infilando una classe sinistra con altri metodi.
C'è già una soluzione al problema delle dichiarazioni in avanti delle dipendenze esterne e cicliche, ma la implementeremo dopo aver lanciato il terminale a 64 bit (compilatore, terminale, editor e tester). Abbiamo già preparato una build pubblica a 32/64 bit oggi - la rilasceremo questa settimana.
Finché non si inizia a scrivere un compilatore di codice gestito da soli, con enfasi diretta sulla sicurezza per il terminale/ambiente di esecuzione (C#/Java non c'entra nulla, perché non sono sicuri per l'ambiente), è difficile capire le ragioni delle azioni degli sviluppatori.
Bene, vediamo se "utenti inesperti imparziali" possono scrivere "qualcosa di veramente fondamentale" in MQL5 a dispetto dei "programmatori di sistema professionisti".
TheXpert:
Dove ho scritto che non possono, mia cara? Sì, possono, ma sarà qualcosa di rozzo e duro.
Ecco fatto. Come ci si libera delle dipendenze cicliche nell'architettura?
Non ditemi che non possono esistere in un'architettura normale. L'unico modo (stampella) è quello di ridisegnare l'architettura aggiungendo un mucchio di classi base non necessarie, che si trasforma in una vera rottura di palle a causa della mancanza di ereditarietà multipla, che hai rifiutato, come ho capito, per non preoccuparti di implementare le dipendenze a losanga.
Ma avresti potuto semplicemente implementare la dichiarazione...
Dove ho scritto che non possono, caro? Sì, possono, ma sarà una cosa disordinata e pesante.
Con tutto il rispetto, lasciatemi dire che, a giudicare dal forum 5, sono gli esperti che mormorano e brontolano di più. Mentre i comuni dilettanti ululano e creano... Sei un esperto, quindi vivi al tuo livello. Scusa, semmai.
Questo perché tutto è relativo,
Chi non è mai stato al volante di una giapponese con guida a destra non può capire come sia possibile cambiare il cambio con la mano sinistra.
E a un principiante non importa, non sa come spostarlo, a destra o a sinistra.
Questo perché tutto è relativo,
Chi non è mai stato al volante di una giapponese con guida a destra non può capire come sia possibile cambiare il cambio con la mano sinistra.
e un principiante non si preoccupa, non può spostarlo con la mano destra o con la sinistra.
Ecco, hai fatto un casino di tutto. :)
Uno che è abituato a guidare un'auto straniera con l'automatico non può muoversi in una shakha con un cambio fottuto. Ma colui che ha guidato in "classico" darà un vantaggio a qualsiasi professionista in "giapponese", se guiderà in "giapponese". Sto solo facendo filosofia, sono di buon umore... Notate che non ho detto "principianti", ma "dilettanti".
Ecco, hai rovinato tutto. :)
Chiunque sia abituato a guidare un'auto straniera con l'automatico non può muoversi in una shakha con un cambio fottuto. Ma lui, che guida un'auto "classica", darà un vantaggio a qualsiasi professionista in un'auto "giapponese", se guida un'auto "giapponese". Sto solo facendo filosofia, sono di buon umore... Notate che non ho detto "principianti", ma "dilettanti".
C'è già una soluzione al problema delle dichiarazioni in avanti delle dipendenze esterne e cicliche, ma la implementeremo dopo il lancio del terminale a 64 bit (compilatore, terminale, editor e tester). Abbiamo già preparato una build pubblica a 32/64 bit oggi - la rilasceremo questa settimana.
Finché non si inizia a scrivere un compilatore di codice gestito, con un'enfasi diretta sulla sicurezza per il terminale/ambiente di esecuzione (C#/Java non c'entra nulla, perché non è sicuro per l'ambiente), è difficile capire le ragioni di certe azioni degli sviluppatori.
Ecco la soluzione per i costruttori di oggetti - anche. Le ragioni per renderli inutili non sono chiare.
Non prendono parametri. Dovremmo emulare i parametri ora, usando le variabili globali per farlo?
Non c'è un meccanismo per segnalare che un oggetto non è stato creato perché si è verificato un errore irrecuperabile durante la creazione (inizializzazione) di uno dei sottooggetti. Si può aggiungere una funzione di inizializzazione a tutte le classi usate nei sottooggetti, e chiamare le funzioni di inizializzazione dei sottooggetti dalla funzione di classe corrispondente dell'oggetto stesso, che fornirà la possibilità di restituire il codice di errore. Ma, in primo luogo, si dovrebbe chiamare tale funzione esplicitamente subito dopo la creazione dell'oggetto e dopo che il suo costruttore "sotto" è stato eseguito (così come la funzione di deinizializzazione prima di distruggere l'oggetto con il distruttore), e, in secondo luogo, quando si modifica la classe principale, per esempio, quando si aggiunge qualche sottooggetto, si potrebbe facilmente dimenticare di includere, e anche nel posto giusto, per fornire una sequenza adeguata, la chiamata della funzione di inizializzazione del sottooggetto aggiunto dalla funzione di inizializzazione della classe principale (lo stesso vale per la funzione di deinizializzazione). Dopo tutto, praticamente nessuno scrive una cosa intera in una volta da zero. Come risultato si ottiene un codice semi-manifesto e non sicuro.
E il comunicato dichiarato come tale più di un mese fa non includeva una soluzione così importante...
Stai suscitando un sacco di inquietudine mescolando e inventando problemi che non sono nemmeno per te stesso. Se avete così paura di scrivere, allora rinunciate.
Sai cosa ostacola un cattivo ballerino.
Con tutto il rispetto per lei, mi permetta di notare: sono gli esperti che si lamentano e brontolano di più, a giudicare dal 5° forum.
Quindi, c'è molto di cui lamentarsi. Molto presto dopo il rilascio della prima beta pubblica ho iniziato a scrivere un sistema di trading. Quasi immediatamente ho perso i costruttori normali, e poi ho rinunciato del tutto, perché era impossibile ottenere un puntatore senza crearlo esplicitamente con l'operatore new. Anche allora ho suggerito la possibilità di importare classi, come un'aggiunta logica alla luce della crescente complessità dei programmi e della loro struttura (file di intestazione e di libreria o oggetto -- in alcuni solo le dichiarazioni richieste, in altri l'implementazione).
Le classi di importazione e le dichiarazioni in avanti risolvono completamente il problema del posizionamento del codice.
Un costruttore di copie semplifica il problema dei costruttori.
Il problema che mi ha fatto smettere è risolto. Ora c'è un costrutto GetPointer(this). Tutto il resto è (finora) risolvibile all'interno del linguaggio, ma mi sta comunque rovinando la vita.
Sei tu l'esperto, sii appropriato al tuo livello, perché chi è esperto cerca opportunità e chi è ignorante cerca ragioni... Scusa, semmai.
Quindi continuo a scrivere. Parlare qui non interferisce con la scrittura del codice. Non c'è bisogno di scusarsi per questo - ho esagerato.