Bug del compilatore con il parametro template = void* - pagina 17
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
C'era per caso un codice piramidale dei sostenitori? Semmai, io sarò il primo. )))))
C'era per caso un codice piramidale dei sostenitori? Semmai, io sarò il primo. )))))
Questo potrebbe essere attribuito al campo dei sostenitori del codice orizzontale.
Questo può essere attribuito al campo dei sostenitori del codice orizzontale.
Sono d'accordo, è stato un povero sforzo. I migliori esempi erano così trascendenti che non sono sopravvissuti al passaggio alla nostra realtà mortale...
C'era per caso un codice piramidale dei sostenitori? Semmai, io sarò il primo. )))))
Questo è un offuscamento.
È un offuscamento.
Sì, sono molto lontano da te. Ho, per così dire, qualcosa per cui lottare ))
In generale, sì, puoi farlo.
Se senza involucro non si cancella, con l'involucro si cancella, tutto è cristallino.
ZS: ma se lo facessi, lo farei il più simile possibile alla libreria standard plus (nomi, comportamento, ecc.), quindi non ho scelta. Perché preoccuparsi di creare un'altra specifica quando tutto è già scritto?
- Creare strutture automatiche all'interno dell'OOP dinamico non ha senso
- Le strutture dinamiche dovrebbero essere divise in quelle create per un processo specifico (come una query su una selezione) o come una selezione da un insieme esistente di elementi (e ci possono essere tipi misti)
- Finora posso vedere una soluzione nel numero contabile dei "propri" riferimenti a un oggetto, non è necessario creare wrapper su di esso (non sono davvero sicuro di come questo risolverebbe il problema), ma dovrei duplicare il meccanismo dei puntatori già esistente in µl, aggiungendo i miei metodi a loro, almeno includendo il contatore di riferimento (è stato discusso nel tuo articolo da hubra a proposito, lo stavo leggendo proprio un paio di giorni fa, quando stavo cercando una soluzione sui puntatori e mi sono reso conto di essere già arrivato alla stessa soluzione da solo).
- Cercherò di realizzare tutto, se viene fuori qualcosa di utile, lo posterò comunque sul forum e/o in kodobase :).
- Creare strutture automatiche all'interno di una OOP dinamica non ha senso
- Le strutture dinamiche dovrebbero essere divise in quelle create per un processo specifico (come una query su una selezione) o come una selezione da un insieme esistente di elementi (e ci possono essere tipi misti)
- Finora posso vedere una soluzione nel numero contabile dei "propri" riferimenti a un oggetto, non è necessario creare wrapper su di esso (non sono davvero sicuro di come questo risolverebbe il problema), ma dovrei duplicare il meccanismo dei puntatori già esistente in µl, aggiungendo i miei metodi a loro, almeno includendo il contatore di riferimento (è stato discusso nel tuo articolo da hubra a proposito, lo stavo leggendo proprio un paio di giorni fa, quando stavo cercando una soluzione sui puntatori e mi sono reso conto di essere già arrivato alla stessa soluzione da solo).
- Cercherò di implementare tutto questo e se ne viene fuori qualcosa di buono, lo posterò comunque sul forum e/o in kodobase :)
Molto interessante. Stanco degli stronzi.
Beh, nessuno vieta di passare un'opzione aggiuntiva quando si crea un array - se cancellare gli elementi quando lo si cancella o no, e renderlo on o off di default (a vostro piacimento). Dopo tutto, non si può mai indovinare se si vogliono cancellare degli oggetti o no)).
Quindi avete scritto un tale array e avete una sorpresa: come disabilitare l'operatore di copia=() e il costruttore di copia (di default è comunque assente in µl) in un array di puntatori che richiedono la cancellazione? Questo renderà chiaro che il parametro tramite il costruttore è spazzatura. Sorgeranno due idee:
1. passare il tipo con la dichiarazione cancellata attraverso i parametri del template e renderlo un membro della classe (e questo è un inutile spreco di risorse).
2. passare un puntatore in un wrapper :) (sì, sì - quel maledetto involucro).
3. si potrebbe usare la specializzazione parziale per uscirne, ma non ce n'è.
In generale la libreria plus è un capolavoro, se pensate di poter scrivere meglio, probabilmente vi sbagliate.
0. Quindi avete scritto un tale array e vi ritrovate con una sorpresa: come disabilitare la copia di operator=() e la copia del costruttore (di default non è comunque in µl) in un array di puntatori che richiedono la cancellazione? Questo renderà chiaro che il parametro tramite il costruttore è spazzatura. Sorgeranno due idee:
1. passare il tipo con la dichiarazione cancellata attraverso i parametri del template e renderlo un membro della classe (e questo è un inutile spreco di risorse).
2. passare un puntatore wrapper :) (sì, sì - quel maledetto involucro).
3. si potrebbe usare la specializzazione parziale per uscirne, ma non c'è.
In generale la libreria plus è un capolavoro, se pensate di scrivere meglio, probabilmente vi sbagliate.
Molto probabilmente lo è, ed è un capolavoro, ma scritto per una gamma di compiti molto più ampia di quella necessaria per costruire la maggior parte dei TC sensati. Non considero varianti come le reti neurali, l'uso di processori grafici e altre danze con tamburelli.
0. Vi ho detto che gli oggetti dinamici già creati vengono trasferiti. Si tratta o di oggetti creati appositamente per la selezione (bisogna cancellarli in seguito), o di riferimenti a oggetti che vengono utilizzati ma non cancellati. L'oggetto lista non è responsabile della creazione, ma solo dell'indirizzamento, dell'accesso e della memorizzazione per tutto il tempo necessario.
1. ...
2. ...
3...
In breve, è necessario considerare compiti specifici e dettagliati, non astratti. Se dovete scrivere delle gui, non è neanche questo che intendo. Un tizio in un thread vicino sembra aver scritto una bella guida usando strutture pure).