eure meinung: array-klasse

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

Shade Of Mine

volkard schrieb:

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

dabei hat keine funktion mehr als 6 zeilen

darf man mal deine static array klasse sehen? vielleicht kann ich mir da n paar tricks abschauen wie man das einfacher machen kann?

denn ich bin zu unfaehig das ding zu vereinfachen

lies einfach diese gotw artikel nicht...dann schreibst du auch nicht so freakige klassen

volkard

Shade Of Mine schrieb:

darf man mal deine static array klasse sehen? vielleicht kann ich mir da n paar tricks abschauen wie man das einfacher machen kann?

hab keine. aber ich les mir den code mal durch und meckere ein wenig rum.

aber ich würde dran denken, den rohen speicher in ne klasse zu packen. sagen wir mal, sie hat platz für Size objekte vom typ Type, aber konstuiert und destruiert mal gar nix. macht aber arraygrenzencheck und adressarithmetik.

die objekte sollen andersrum zerstört werden, als sie angelegt wurden.

ich kann nicht nachvollziehen, warum construct nen void* kriegen tut.

ClassCopy kommt mir sehr groß vor. werden wirklich alle diese funktionen gebraucht?

template<typename otherType> Array(otherType const* value, size_type size)

muß weg wegen is nicht. wenn du auf stl abfährst, dann haste die version mit zwei iteratoren.

assert(size>Size);
std::size_t length=std::min(size,Size);

erscheint mir wirr. ich denke, nach assert(size>Size) ist die zweite zeile mindersinnvoll. ich schließe auf programmiererüberlastung weils nicht einfach genug ist.

Copy::construct<value_type>(this->value, value, length);
Copy::construct<value_type>(this->value+(length*sizeof(value_type)), Size-length);

überlastet mich. ich lese immer nur construct. kein wunder, daß ich nicht kapiere, daß die obere zeile ein copyconstruct und die untere ein defaultconstruct macht.

std::size_t length=std::min(end-beg,Size);

warum denke ich an const?

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

oh, du nimmst begin() als parameter für Copy-sachen. warum? um zu postulieren, daß der iterator ein Type* ist? oder warum nicht bei

Copy::construct<value_type>(this->value+(length*sizeof(value_type)), Size-length);

?

wozu assign?

wozu at?

wozu data?

*static_cast<TRG*>(p+(i*sizeof(TRG)))=src;

und

return *(((value_type*)value)+Size-1);

wundert mich so vom stilbruch her.

und mit

return ((value_type*)value);

machte komische klammern wie in c.

reverse_iterator rbegin()
{
    return reverse_iterator(begin());
}

kapier ich net.

wozu empty? ohne push und pop kaum nutzbar.

template<typename T1, std::size_t Size1, class Copy1, typename T2, std::size_t Size2, class Copy2>
    bool operator==(Array<T1, Size1, Copy1> const& a, Array<T2, Size2, Copy2> const& b)
    {
        if(Size1!=Size2) return false;

        return Copy::equal<Size1>(a.begin(), b.begin());
    }

wolltest du da nicht zur compilezeit bei ungleichen größen false berechnen und nur bei gleichheit der größen zur laufzeit ne schleife benutzen? könnt ja sonst nen nutzlosen funktionsaufruf erzeugen.

irgendwie gefällt mir

template<typename T>
       static void construct(void* value, std::size_t size)
        {
            std::size_t i=0;
            try
            {
                char* p=static_cast<char*>(value);
                for(; i<size; ++i)
                {
                    new(p+(i*sizeof(T)))T();
                }
            }
            catch(...)
            {
                destruct<T>(value,i);
                throw;
            }
        }

nicht.

template<typename T>
        static void construct(T* begin,T* end)
        {
            T* pos=begin;
            try
            {
                while(pos!=end)
                {
                   new(pos)T;
                   ++pos;
                }
            }
            catch(...)
            {
                do
                {
                   --pos;
                   pos->~T();
                }while(pos!=begin);
                throw;
            }
        }

oder vielleicht

template<typename T,std::size_t SIZE>
        static void construct(T* data)
        {
            std::size_t i=0;
            try
            {
                while(i!=SIZE)
                {
                   new(data+i)T;
                   ++i;
                }
            }
            catch(...)
            {
                do
                {
                   --i;
                   (data+i)->~T();
                }while(i!=0);
                throw;
            }
        }

Shade Of Mine

@volkard:

danke!
ich habe die array klasse mal diesbezueglich n bisschen ueberarbeitet.

und heute nacht denke ich ueber die RawStorage Klasse nach - mir sind da einige dinge noch nicht ganz klar.

aber danke fuer die verbesserungsvorschlaege.

volkard

Shade Of Mine schrieb:

@volkard:
danke!
ich habe die array klasse mal diesbezueglich n bisschen ueberarbeitet.

na, eigentlich egal. diese punkte sind nicht das, was mir ein ungutes gefühl macht.

Shade Of Mine schrieb:

und heute nacht denke ich ueber die RawStorage Klasse nach - mir sind da einige dinge noch nicht ganz klar.

mach das mal.

hab mal alten code von mir angeguckt. am häufigsten verwende ich wohl sowas hier:

//21.04.00
#ifndef VECTOR_H
#define VECTOR_H
#pragma once

#include <assert.h>
#include "tools/TestAtStartup.h"

/*Einfache Vektor-Klasse mit Überprüfung der Indexgrenzen im Debug-Modus
*/
template<class T,int SIZE>
class Vector
{
private:
   T data[SIZE];
public:
   const T &operator [](int index) const
   {
      assert(0<index && index<SIZE);
      return data[SIZE];
   }
   T &operator [](int index)
   {
      assert(0<index && index<SIZE);
      return data[SIZE];
   }
};
DECLARE_TESTATSTARTUP(Vector);

#endif

<anderes thema>
die DECLARE_TESTATSTARTUP(Vector); sorgt dafür, daß ne in der Vector.cpp definierte Funktion testVector aufgerufen wird. dadrin wird irgendwie die ganze vectorklasse getestet, zum beispiel 1000 vectoren verschiedener größe sortieren und dann auf sortiertheit testen oder sowas. und allein durchs inkludieren der "Vector.h" wird dafür gesorgt, daß am programmstart das passiert. kostet zwar ne sekunde mehr bei programmstart (abschaltbar), aber man kann immer sicher sein, daß nicht wieder ne dumme kleine performanceoptimierung oder ein bugfix in der Vector.h nen fehler eingebaut hat und man sich im ftpserver nen wolf sucht. sag ich nur mal, da in nem anderen thread der begriff "automatisches testen" oder so gefallen ist.
</anderes thema>

und gerne auch mal ganz unwiederverwertbares, hier ein mutierter stack:

//21.06.00
#ifndef STACK_H
#define STACK_H

#include <xutility>//f³r std::swap

template<class T,int COUNT>
class Stack
{
   private:
      T data[COUNT];
      int size;
   public:
      Stack()
      {
         size=0;
      }
      void push(const T &t)
      {
         data[size++]=t;
      }
      void moveToFront(const T &t)
      {
         for(int i=0;i<size;++i)
         {
            if(data[i]==t)
            {
               while(i<size-1)
               {
                                   std::swap(data[i],data[i+1]);
                  ++i;
               }
               return;
            }
         }
      }
      T &peek()
      {
         return data[size-1];
      }
      void pop()
      {
         --size;
      }
      bool isEmpty()
      {
         return size==0;
      }
      void flush()
      {
         size=0;
      }
};

#endif

aber was ich eigentlich suchte, ist auf dem rechner nicht da. ich versuche, es mal so hinzuzappeln.

template<typename T>
class Stack
{
   private:
   GenericStack<sizeof(T)> stack;
   public:
   void push(const T& t)
   {
      stack.push();
      new(stack.top())T(t);
   }
   void pop()
   {
      stack.top()->~T();
      stack.pop();
   }
   T& top()
   {
      return *static_cast<T*>(stack.top());
   }
   bool isEmpty()
   {
      return stack.isEmpty();
   }
};

sowas sollte man vermutlich auch für nen vector machen (sicher bin ich erst, wenns geklappt oder nicht geklappt hat). aber da haste noch ein wenig arbeit vor dir, die ganzen sachen sauber einzuteilen, was wohin gehört.
aber das ist auch nur ein schritt von vielen. die Copy-Klasse ist mir zu groß. evtl sind es eher nur drei funktionen, nämlich constructOne, copyconstructOne und destructOne, die als policy definiert werden muß und Copy kann daraus sich den ganzen anderen kram basteln. oder vielleicht ist die gegenrichtung gut, daß man nen Vector und nen PodVector als zwei ganz getrennte klassen baut. uih, ist da viel spielraum und keiner verrät mir, was die allerbeste lösung ist.

Gerard

volkard schrieb:

reverse_iterator rbegin()
{
    return reverse_iterator(begin());
}

kapier ich net.

HTH

namespace std
{
    template<typename Iter>
    class reverse_iterator
    {
    public:
        typedef typename Iter::value_type value_type;

        reverse_iterator(Iter iter)
            :    iter_(i)
        {
        }

        reverse_iterator & operator++ ()
        {
            --iter_;
            return *this;
        }

        reverse_iterator & operator-- ()
        {
            ++iter_;
            return *this;
        }

        value_type & operator* ()
        {
            return *iter_;
        }

        ...
    };
}// end of namespace std

reverse_iterator rbegin()
{
    reverse_iterator r( begin() );
    return r;
}

Helium

Wenn ich einen eigenen Vergleich brauche muss ich gleich ein komplett neues Kopier-Policy schreiben? Das ist gemein.

Und nochmal für Blöde: Wieso brauche ich ein at()?

Shade Of Mine

Helium schrieb:

Wenn ich einen eigenen Vergleich brauche muss ich gleich ein komplett neues Kopier-Policy schreiben? Das ist gemein.

mhm, stimmt.
copy und vergleiche sollten getrennt werden!
danke!

Und nochmal für Blöde: Wieso brauche ich ein at()?

ich habe absolut keine ahnung warum irgendjemand irgendwann ein at() brauchen sollte.

aber um ehrlich zu sein, habe ich das interface von boost::array groesstenteils uebernommen. und da hab ich mir gedacht: STL hat at(), boost hat at(), warum ich nicht auch

vielleicht will ja irgendwer mal ein at() verwenden?
naja, solange man kein at() verwendet, wird es ja auch nicht instanziiert und hat somit keinen overhead. also sehe ich keinen grund warum ich es rausnehmen sollte.

wenn du aber einen guten grund kennst (ausser: braucht man nicht) dann werde ich es gerne herausnehmen.

operator void

volkard schrieb:

wozu at?

at() ist doch fein, wenn man Sachen auch im Release-Build überprüfen will (zum Beispiel Benutzereingaben, wo man sich nicht darauf verlassen will, dass der Benutzer nicht doch irgendwie eine unerwartete Eingabe reinschmuggelt) und gerade zu faul ist, eine Prüfung manuell zu bauen und anschließend eine Exception zu werfen.

Hm, ändert natürlich nichts groß an der Klasse, aber warum castest du dauernd value, anstatt begin() zu nehmen?

volkard

[quote="Dimah"]

volkard schrieb:

reverse_iterator rbegin()
{
    return reverse_iterator(begin());
}

kapier ich net.
HTH

ich weiß auch nicht, was HTH bedeutet.
warum steht da nicht

reverse_iterator rbegin()
{
    return reverse_iterator(end());
}

?

volkard

operator void schrieb:

at() ist doch fein, wenn man Sachen auch im Release-Build überprüfen will (zum Beispiel Benutzereingaben, wo man sich nicht darauf verlassen will, dass der Benutzer nicht doch irgendwie eine unerwartete Eingabe reinschmuggelt) und gerade zu faul ist, eine Prüfung manuell zu bauen und anschließend eine Exception zu werfen.

der benutzer will ne editbox, nen slider oder sowas, das bereits bei der eingabe ne wertebeschränkung hat. und selbst wenn nicht, dann macht man EINEN test nach der benutzereingabe und nicht mehr als n^2 tests wärend des sortierlaufs.
also weg mit dem at, das brauchen nur fehlermacher.

Shade Of Mine

volkard schrieb:

warum steht da nicht

reverse_iterator rbegin()
{
    return reverse_iterator(end());
}

?

weil ich es viel witziger finde

foo(a.rend(), a.rbegin())
aufzurufen als
richtig rum

ne, ist natuerlich n fehler!
danke!