2015-01-08 12 views
5

Domanda
Questa è una cosa che mi rode da qualche tempo, ma non sono riuscito a trovare una risposta definitiva per esso:Standardizzare 2D/3D Vector/coordinate Class

  • È qualcuno a conoscenza di un proposta di introdurre un vettore 2D e/o 3D standard (una struttura con membri x, y e z) in STL?
  • In caso contrario, c'è un modo realistico per ottenere una tale classe nella prossima versione dello standard - a meno di scrivere una proposta completa e perfettamente scritta io stesso?
  • E, ci sono dei buoni motivi (a parte quelli che non hanno tempo) perché questo non è già stato fatto?

Sono sicuramente disposti a contribuire, ma credo che mi manca l'esperienza per produrre qualcosa di qualità sufficientemente elevata per avere accettato (io non sono un programmatore professionista).

Ragionamento/Background
da decine ora che ho visto di librerie e framework (sia per la grafica, la fisica, la matematica, la navigazione, sensor fusion ...), che implementano tutti fondamentalmente la propria versione di

e/o il suo equivalente 3D - per non parlare di tutte le occasioni, in cui ne ho implementato uno prima che mi prendessi il tempo per fare una versione corretta e riutilizzabile.
Ovviamente, questo non è qualcosa di difficile e non mi preoccupo di implementazioni sub-ottimali, ma ogni volta, voglio combinare due librerie o riutilizzare un codice da un progetto diverso, devo occuparmi di convertire una versione nell'altra (o mediante fusione o, se possibile, sostituzione del testo).

Ora che il comitato si sforza di estendere significativamente la libreria standard per C++ 17 (in particolare con un framework grafico 2D), mi piacerebbe davvero avere un vettore 2D comune cotto in tutte le interfacce fin dall'inizio, quindi posso basta scrivere ad esempio:

drawLine(transformCoordinates(trackedObject1.estimatePos(),params), 
     transformCoordinates(trackedObject2.estimatePos(),params)); 

piuttosto che

MyOwnVec2D t1{trackedObject1.estimatePosX(), trackedObject1.estPosY()}; 
MyOwnVec2D t2{trackedObject2.estimatePosX(), trackedObject2.estPosY()}; 

t1 = transformCoordinates(t1,params); 
t2 = transformCoordinates(t2,params); 

drawLine(t1.x,t1.y,t2.x,t2.y); 

L'esempio potrebbe essere un po 'esagerato, ma penso che dimostra il mio punto.

Sono a conoscenza di std::valarray, che va già nella giusta direzione, in quanto consente operazioni standard come addizione e moltiplicazione, ma porta troppo peso se tutto ciò che serve sono due o tre coordinate. Penso che un valarray, con dimensioni fisse e nessuna allocazione dinamica della memoria (ad esempio basata su std::array), sarebbe una soluzione accettabile, soprattutto perché sarebbe implementato con un'implementazione triviale di iteratore, ma personalmente preferirei una classe con x, y (e z) membri.

Nota: Mi dispiace se questo argomento è già stato discusso (e sarei sorpreso se non ha), ma ogni volta che sto cercando vettori 2d ottengo risultati a parlare di qualcosa di simile std::vector<std::vector<T>> o come implementare una certa trasformazione, ma nulla sul tema della standardizzazione.

+0

* c'è un modo realistico per ottenere una tale classe nella prossima versione dello standard - a meno di scrivere una proposta completa e perfettamente scritta io? * - convincere qualcun altro a farlo. Ecco come si evolve C++. –

+0

@BartekBanachewicz: qualche suggerimento su come fare questo o dove chiedere aiuto per scrivere la proposta (se non stai lavorando in una compagnia SW)? – MikeMB

+1

Vorrei iniziare leggendo le proposte esistenti. –

risposta

4

ci sono dei buoni motivi (a parte quelli che non hanno tempo) perché questo non è già stato fatto?

Non c'è praticamente alcun motivo per.

Formare un tipo che contiene due o tre elementi è assolutamente banale e anche tutte le operazioni possono essere definite banalmente. Inoltre, la libreria standard C++ non è intesa come una suite di strumenti matematici per uso generico: ha senso utilizzare librerie specializzate di terze parti per questo se si è seriamente interessati a tipi e costrutti matematici oltre alle funzioni e agli operatori che è possibile riunire in mezz'ora.

E non standardizziamo le cose che non hanno bisogno di essere standardizzate.

Se C++ dovesse ottenere una sorta di API di grafica 3D standardizzata, posso vedere questo cambiamento ma non fino ad allora. E speriamo che C++ non acquisisca mai alcun tipo di API grafica 3D standardizzata, perché non è quello che serve.

Tuttavia, se si sente fortemente, è possibile avviare una conversazione su std-discussion in cui vivono tutti gli esperti (e alcuni sicuramente non esperti); a volte tali conversazioni portano alla formazione di proposte e non è necessariamente necessario che tu finisca per scriverlo.

+0

Se C++ dovesse ottenere una sorta di API grafica 3D standardizzata, allora sicuramente sarà generalizzata per lavorare con il tipo di coordinate scelto. A C++ piace pagare solo ciò di cui hai bisogno, non le "tasse" in tutti i caselli di pedaggio del confine API. – sehe

+0

@sehe: Forse mi manca completamente il tuo punto, ma come? Un'implementazione utilizza semplici membri di dati, un altro setter e metodi getter. Si potrebbero denominare le coordinate x, y, z, l'altra x1, x2, x3 e la terza potrebbe richiedere l'accesso allo stile dell'array. – MikeMB

+0

@MikeMB Vedere [** Boost Geometry ** Design Rationale] (http://www.boost.org/doc/libs/1_57_0/libs/geometry/doc/html/geometry/design.html), ad es. tutta la ** [Boost Propertymap] (http://www.boost.org/doc/libs/1_57_0/libs/property_map/doc/property_map.html) ** biblioteca .. La generalizzazione degli accessi è uno strumento chiave nella versatile API C++ design – sehe

1

Nel caso in cui qualcun altro abbia un interesse in esso, volevo sottolineare che la versione di luglio 2014 di "A Proposal to Add 2D Graphics Rendering and Display to C++" include una classe/struttura di punti 2D (la mia domanda era basata sulla bozza iniziale di gennaio 2014). Quindi forse ci sarà almeno un semplice standard 2D-Vector in C++ 1z.