Evitare gli oggetti wrapper nelle raccolte

4

Mi sto un po 'annoiando di dover avvolgere i tipi primitivi negli oggetti wrapper per archiviarli in strutture di raccolta dati (insiemi, mappe, liste, ecc.) in linguaggi come Java e Objective C. Mi piacerebbe molto avere, ad esempio, una struttura di dati Mappa che funziona allo stesso modo, sia che io stia mappando NSNumbers a Stringhe o interi a doppio o intero a MyBigCustomObject *.

La mia comprensione è che il motivo per cui le strutture dei dati di raccolta in questi linguaggi richiedono il wrapping in un oggetto è che si può sempre presumere che il numero dato sia un puntatore - In realtà posso creare un NSDictionary con [ Dizionario NSDictionaryWithObject: MyCustomObject forKey: 1], ma considera 1 come puntatore invece di un intero, prova ad accedere all'indirizzo di memoria 1 e segfault. Ma non vedo alcun motivo per cui non sia possibile creare una struttura dati di raccolta che tenga traccia del tipo di chiavi e valori che non avrebbero questo problema. Anche una struttura di dati relativamente inflessibile come una mappa di specificità per specifici puntatori agli oggetti sarebbe un caso d'uso decente comune (ne potrei certamente usare uno, sto facendo molto lavoro di recente che implica l'indicizzazione di oggetti da parte di un ID intero). C'è una ragione per cui questo non è un paradigma comune nei linguaggi che hanno una distinzione di tipo Oggetto / primitivo?

    
posta Tneuktippa 23.08.2011 - 19:42
fonte

4 risposte

2

È, ovviamente, possibile. Tuttavia, richiederebbe la duplicazione di tutto il codice (che può essere abbastanza per un'implementazione ottimizzata) per ogni tipo non di riferimento, o un modo per specializzare automaticamente l'implementazione per ciascun tipo.

Suppongo che nessuno abbia ritenuto utile la prima opzione.

Il secondo modo aggiunge una certa complessità al linguaggio e alla sua implementazione. Inoltre, nel caso di Java, ci sono generici (che in teoria potrebbero essere usati per implementare la seconda opzione) ma le prime decisioni di progettazione (alcuni direbbero errori) impediscono la seconda opzione, in quanto i generici vengono compilati in codice non generico che semplicemente usa gli oggetti ovunque e lancia quando necessario.

Si noti che esiste una lingua, C ++, che ha un meccanismo per la seconda opzione (modelli). Tuttavia non tratta oggetti come puntatori (tipi di riferimento).

Modifica: come sottolinea FredOverflow nei commenti, questo esiste. Scala espone la seconda opzione al programmatore con una @specialized annotazione .

    
risposta data 23.08.2011 - 19:54
fonte
1

Questo è fondamentalmente ciò che accade in C ++ - la lingua sa sempre se qualcosa è un puntatore o meno. Molto semplicemente, non vi è alcuna ragione fondamentale per cui ciò sia necessario a tutti - Java e altri linguaggi lo fanno semplicemente perché godono di limitazioni alla libertà del programmatore.

    
risposta data 23.08.2011 - 22:07
fonte
0

But I don't see any reason why you couldn't make a collection data structure that keeps track of the type of keys and values that wouldn't have this problem.

questo è esattamente il problema in quelle lingue. A causa del modo in cui Generics è implementato in Java e Objective-C, questa informazione non è più disponibile in fase di runtime.

È tuttavia possibile implementare una struttura dati il cui costruttore prende istanze di Type nel suo costruttore e utilizza tali informazioni per memorizzare i dati. Sembra un sacco di lavoro, e l'API diventa complicata. Domanda alla comunità: esiste già un'implementazione di tale struttura dati?

    
risposta data 08.05.2018 - 14:43
fonte
-1

in Java, sembra che questo sia un paradigma comune. Si possono trovare molte librerie di terze parti per collezioni come quelle a cui si fa riferimento. Alcuni di questi sono stati discussi in SO: Qual è la libreria di raccolte Java più efficiente ? La ricerca sul Web per raccolte ad alte prestazioni della libreria java mostra ancora di più, ad esempio HPPC

  • Il motivo per cui tali librerie non sono diventate standard API Java (ancora?) è più probabile che queste non abbiano guadagnato popolarità sufficiente a giustificare tale inclusione (ancora?). Un'altra possibile ragione è che sembra non esserci un accordo comune (ancora?) Su come progettare API standard per queste collezioni. Come ha detto Joshua Bloch , le API pubbliche, come i diamanti, sono per sempre. Hai una possibilità di farlo bene, quindi dai il massimo.
risposta data 23.08.2011 - 21:59
fonte

Leggi altre domande sui tag