eure meinung: array-klasse

Shade Of Mine

Hallo Leute.

Ich habe gerade meine static-array Klasse ueberarbeitet. Sie unterstuetzt jetzt mojo

weiters gibt es auch keine sinnlosen Default Ctor aufrufe mehr.

ich wuerde gerne eure meinung dazu hoeren!
der einfachheit halber habe ich noch keine workarounds fuer nicht standard konforme compiler eingebaut.
weiters sind die Copy-Policies noch nicht auf performance getrimmt.

schaut euch die klasse mal an: array.hpp und sagt, was ihr darueber denkt.

seht ihr fehler? ist etwas nicht schoen geloest? fehlt wichtige funktionalitaet? gibts noch tricks die performance zu steigern? hat das ding bugs? etc.

ich ueberlege zur zeit wie man das aneinander haengen von 2 arrays gut implementieren koennte... wenn da jemand eine idee hat...?

oder ist das alles ein bloedsinn?

etechniker

.hpp ? Warum nicht .h ?

rüdiger

etechniker schrieb:

.hpp ? Warum nicht .h ?

weil .h für C ist, genauso wie man seine Code Dateien auch nicht .c nennt.

(btw. /me nimmt für Header .hh und .cc für Code Files)

mojo?

Move of Joint Objects

rüdiger

http://www.cuj.com/documents/s=8246/cujcexp2102alexandr/

operator void

Ein ziemlicher Brocken für eine statische Array-Klasse jedenfalls Was mir beim Drüberfliegen nur aufgefallen ist: "char value[]" sieht nicht sehr portabel aus und dein künstliches Lifetime-Management (construct etc.) scheint Exceptions aus Konstruktoren nicht standzuhalten. Hast du dir std::unitialized_fill mal angesehen?

Shade Of Mine

operator void schrieb:

Ein ziemlicher Brocken für eine statische Array-Klasse jedenfalls

naja, das ding kann ja auch was

boosts array ist auch nicht viel kleiner (nur gibts dort halt kein copy-policy)

Was mir beim Drüberfliegen nur aufgefallen ist: "char value[]" sieht nicht sehr portabel aus

wieso denn nicht?
bitte erklaeren.

und dein künstliches Lifetime-Management (construct etc.) scheint Exceptions aus Konstruktoren nicht standzuhalten.

danke habe ich jetzt verbessert.

Hast du dir std::unitialized_fill mal angesehen?

ja, aber wo sollte ich das verwenden koennen?

volkard

Copy::destructiveInit< (otherSize < Size ? otherSize : Size), value_type >(begin(), other.begin());

ist gar häßlich.

Shade Of Mine

volkard schrieb:

Copy::destructiveInit< (otherSize < Size ? otherSize : Size), value_type >(begin(), other.begin());

ist gar häßlich.

da stimm ich dir zu, doch leider weiss ich nicht, wie man das schoener machen kann.

uU ein makro my_min() definieren, aber das macht die ganze sache auch nicht schoener.

std::min() ist ja ne inline funktion - da verliere ich damit die compile time konstante

ich bin sicher, dass du eine bessere idee hast - ich wuerde mich freuen diese zu erfahren. danke

operator void

Shade Of Mine schrieb:

operator void schrieb:

Was mir beim Drüberfliegen nur aufgefallen ist: "char value[]" sieht nicht sehr portabel aus

wieso denn nicht?
bitte erklaeren.

Wegen allerlei seltsamen Alignmentproblemen. Zumindest habe ich das mal als Begründung gegen solche Techniken auf einer Internetseite gelesen, Erfahrung habe ich da keine.

Shade Of Mine schrieb:

Hast du dir std::unitialized_fill mal angesehen?

ja, aber wo sollte ich das verwenden koennen?

Anstelle des zweiten constructs, hätte ich gedacht.

volkard

#ifndef ANGST_VOR_MAKROS
#define MIN(a,b) Min<a,b>::value
#endif

Shade Of Mine

volkard schrieb:

#ifndef ANGST_VOR_MAKROS
#define MIN(a,b) Min<a,b>::value
#endif

*patsch* entweder bin ich blind und bloed, dass ich auf sowas nie komme, oder du bist n genie.

danke!!

@operator void:
kannst du auch was kongretes zum alignment problem posten?

so wie ich unitialized_fill verstanden habe, wuerde es in meinem Fall
T(T()); aufrufen, oder?
denn ich will nur den default ctor aufrufen, also uebergebe ich unitialized_fill einfach nur T() und unitialized_fill ruft dann jeden ctor mit T() als param auf.

wenn das nicht so ist, bitte aufklaeren.

#define ANGST_VOR_MAKROS

operator void

Shade Of Mine schrieb:

@operator void:
kannst du auch was kongretes zum alignment problem posten?

http://www.gotw.ca/gotw/028.htm

Daher hatte ich meine Bedenken wohl. Mir ist vorhin nur nicht eingefallen, wo ich das aufgeschnappt hatte.

Shade Of Mine schrieb:

so wie ich unitialized_fill verstanden habe, wuerde es in meinem Fall
T(T()); aufrufen, oder?
denn ich will nur den default ctor aufrufen, also uebergebe ich unitialized_fill einfach nur T() und unitialized_fill ruft dann jeden ctor mit T() als param auf.

So wäre es in deiner ersten construct-Funktion. Mit unitialized_fill kannst du aber, so wie ich es wiederum verstanden habe, deine zweite construct-Funktion ersetzen (und sparst damit immerhin die Hälfte des Exception-Ärgers).

volkard

die array-klasse hat ein massives simplizitätsdefizit und bekommt von mir nur die note 3.

Shade Of Mine

operator void schrieb:

Shade Of Mine schrieb:

@operator void:
kannst du auch was kongretes zum alignment problem posten?

http://www.gotw.ca/gotw/028.htm

danke, aber so schlimm sehe ich das nicht.
schliesslich gibt es keine andere moeglichkeit mein vorhaben anders zu implementieren.

in Sutters Beispiel wird char[] ja auch missbraucht.

So wäre es in deiner ersten construct-Funktion. Mit unitialized_fill kannst du aber, so wie ich es wiederum verstanden habe, deine zweite construct-Funktion ersetzen (und sparst damit immerhin die Hälfte des Exception-Ärgers).

hab mir gerade uninitialized_fill angesehen:

es ist so implementiert: (vereinfacht)

template <class ForwardIter, class Type>
void uninitialized_fill(ForwardIter first, ForwardIter last, const Tp& x)
{
  ForwardIter cur = first;
  for(; cur != last; ++cur)
  {
    new (&*cur) Type(x);
  }
}

es wird also nicht der Default Ctor aufgerufen, sondern der copy ctor (fuer x==T())

das macht die sache nicht unbedingt langsamer, aber es ist nicht das was ich will. es soll ja der default ctor aufgerufen werden

operator void

Ich glaube, wir reden aneinander vorbei

Jo, die Version mit dem Defaultkonstruktor musst du dir selbst schreiben, aber ich wollte ja auch nur folgende Funktion aus deiner array.hpp durch uninitialized_fill ersetzen:

template<typename TRG, typename SRC>
static void construct(void* value, SRC src, std::size_t size)
{
    char* p=static_cast<char*>(value);
    for(std::size_t i=0; i<size; ++i)
    {
        new(p+(i*sizeof(TRG)))TRG(*src);
        ++src;
    }
}

Shade Of Mine

@operator void:
aso, jetzt kapier ich.

ne, das geht nicht. denn bei uninitialized_fill kann man nur 1 wert angeben, ich moechte aber ein ganzes array verwenden.

also brauch ich unitialized_copy
danke! dank dir bin ich auf uninitalized_copy gestossen!!

operator void

Ups. Hab deine Funktion irgendwie falsch gelesen *patsch* Naja, jetzt ist ja alles klar