Welchen Standardcontainer nutzt ihr, wenn es einfach um "rohen" Speicher geht, der in einem Schritt angefordert wird? vector?
Oder nutzt ihr hier noch new?

Und verlasst ihr euch auf solche Optimierungen oder übergebt ihr den vector als Referenz?

std::vector<char> foo() // äquivalent zu void foo(std::vector<char>& v), v.resize() ?
{
  std::vector<char> v(1234567);
  // ...
  return v;
}

edit: Ach jetzt verstehe ich was du meinst (oder eben nicht, siehe oben). Ich dachte schon, du wolltest Refernzen auf lokale Objekte zurückgeben.

1. Was hast du vor?

Ich habe eine Funktion die relativ große Dateien ausliest (0.5 - 25 MB) und suche jetzt nach dem besten Interface dafür.

SeppJ schrieb:

2. Welchen Vorteil sollte new[] gegenüber vector haben? Das hat nur Nachteile.

Ok, gut. Deshalb fragte ich, könnte ja sein, dass vector da irgendetwas verlangsamt oder so. Das ist aber schneinbar trivial?[/quote]

SeppJ schrieb:

1. Was hast du vor?

Ich habe eine Funktion die relativ große Dateien ausliest (0.5 - 25 MB) und suche jetzt nach dem besten Interface dafür.

Und dies hat genau WAS mit rohem Speicher zu tun? Irgendeine Interpretation der Daten muss es doch geben, sonst bräuchtest du sie doch gar nicht einlesen.

Und dies hat genau WAS mit rohem Speicher zu tun? Irgendeine Interpretation der Daten muss es doch geben, sonst bräuchtest du sie doch gar nicht einlesen.

Ich lese ein Bild ein. Also ein kleiner Teil der Daten wird eh einzeln ausgelesen, der Header halt. Danach kommen die Farbwerte, die muss ich einfach irgendwie in den Speicher stopfen, das war's.

Danach kommen die Farbwerte, die muss ich einfach irgendwie in den Speicher stopfen, das war's.

Nö, die wirst du nicht einfach nur in den Speicher stopfen wollen, sondern später sicherlich noch weiterverarbeiten. Sonst bräuchtest du sie garnicht erst einlesen.
Wie werden sie also weiterverarbeitet? Davon hängt ab, wie sie abgelegt werden sollten.

Container schrieb:

Danach kommen die Farbwerte, die muss ich einfach irgendwie in den Speicher stopfen, das war's.

Nö, die wirst du nicht einfach nur in den Speicher stopfen wollen, sondern später sicherlich noch weiterverarbeiten. Sonst bräuchtest du sie garnicht erst einlesen.
Wie werden sie also weiterverarbeitet? Davon hängt ab, wie sie abgelegt werden sollten.

Die werden in den Video-Ram geschrieben und dann wieder gelöscht. Und im Video-Ram wird da auch nicht viel mehr mit gemacht, als einfach an bestimmten Stellen auf den Bildschirm kopiert.

Im optimalen Fall macht der Compiler keine Kopie, schau mal nach RVO (Return Value Optimazation).

Wenn du sicher gehen willst, das keine Kopie entsteht, machst du das so, das du den Aufrufer einen Vector übergeben lässt:

void foo(std::vector<char> &data)
{
  // data füllen
}

Oder du kannst auch einen Pointer bzw. besser Smartpointer zurück geben:

std::tr1::shared_ptr<std::vector<char>> foo() 
{
  std::vector<char> data(1234567);
  // data füllen
  return std::tr1::shared_ptr<std::vector<char>> data_p(v);
}

Dann braucht sich der Aufrufer gar keine Gedanken machen.

Du hast jeweils in Z. 1 und 5 die angle brackets falsch gesetzt (das sind Eingabe-streams).

std::tr1::shared_ptr<std::vector<char>> foo() 
{
  std::vector<char> data(1234567);
  // data füllen
  return std::tr1::shared_ptr<std::vector<char>> data_p(v);
}

Du hast jeweils in Z. 1 und 5 die angle brackets falsch gesetzt (das sind Eingabe-streams).

Mein Compiler schluckt die problemlos

Übrigens sind das keine Eingabe-Streams, es ist einfach der >> Operator.

Und übrigens, mein Compiler schluckt es nicht.
Besser ist also, gleich die sicherere Variante zu nehmen, auch wenn es bei manchen Compilern wegoptimiert wird.

Error:
D:\Eigene Dateien\C++ PROGRAMMS\Temp.cxx|8|error: '>>' should be '> >' within a nested template argument list|

D.h., dein Compiler unterstützt dieses Feature einfach nur noch nicht (oder es muss explizit aktiviert werden)

template<class Sink>
auto bildformatxyz_load(char const* filename, Sink sink)
-> decltype(sink(0,0))
{
  // header lesen...
  const long width  = ...;
  const long height = ...;
  auto const navigator = sink(width,height);
  auto const stepx = navigator.make_offset(1,0);
  for (long y=0; y<height; ++y) {
    // Zeile irgendwie einlesen -> puffer
    auto locator = navigator.make_locator(0,y);
    for (long x=0; x<width; ++x) {
      *locator = puffer[x];
      locator += stepx;
    }
  }
  return navigator;
}

Konzept "Navigator" (ähnlich wie ein Iterator-Paar):
- hat Referenzsemantik
- weiß, wie groß ein Raster ist
- weiß, wie man es navigiert
- kann "Lokators" und "Offsets" erzeugen.

Konzept "Locator" (ähnlich wie ein Iterator):
- zeigt auf ein Element eines Rasters
- Zugriff per Dereferenzierung
- unterstützt + und - im Zusammenhang mit Offsets

Konzept "Offset" (ähnlich wie difference_type):
- relative Raster-Koordinate

Einfaches Beispiel für ein lineares Speicherlayout

template<class T>
class linear_navigator
{
public:
  typedef typename std::remove_const<T>::type value_type;
  typedef T* locator_type;
  typedef std::diff_t offset_type;

  linear_navigator();

  linear_navigator(T* base, long width, long height
    std::diff_t stepx, std::diff_t stepy);

  offset_type make_offset(long x, long y) const {
    return stepx_*x + stepy_*y;
  }

  locator_type make_locator(long x, long y) const {
    return base_ + make_offset(x,y);
  }

  long width() const {return width_;}
  long height() const {return height_;}

private:
  T* base_;
  long width_, height_;
  std::diff_t stepx_, stepy_;
};

Und der Aufruf könnte so aussehen:

std::vector<int> graylevels;
auto navi = bildformatxyz_load(filename,[&](long w, long h)->linear_navigator<int>{
  const long numelems = w*h;
  graylevels.resize(numelems);
  return {&graylevels.front(),w,h,1,w};
});
cout << navi.width() << endl;
cout << navi.height() << endl;

wobei man den vektor für ein Raster selbst kapseln kann und dann so etwas schreiben kann:

raster<int> graylevels;
bildformatxyz_load(filename,into(graylevels));
cout << graylevels.width() << endl;
cout << graylevels.height() << endl;

Vielleicht findet das ja noch jemand anders praktisch so.

D.h., dein Compiler unterstützt dieses Feature einfach nur noch nicht (oder es muss explizit aktiviert werden)

Kennst du (oder irgendwer sonst) ein Flag o. so, mit dem dass beim GNU GCC ginge... ?

pumuckl schrieb:

Container schrieb:

Danach kommen die Farbwerte, die muss ich einfach irgendwie in den Speicher stopfen, das war's.

Nö, die wirst du nicht einfach nur in den Speicher stopfen wollen, sondern später sicherlich noch weiterverarbeiten. Sonst bräuchtest du sie garnicht erst einlesen.
Wie werden sie also weiterverarbeitet? Davon hängt ab, wie sie abgelegt werden sollten.

Die werden in den Video-Ram geschrieben und dann wieder gelöscht. Und im Video-Ram wird da auch nicht viel mehr mit gemacht, als einfach an bestimmten Stellen auf den Bildschirm kopiert.

Falls du das mehrmals pro Sekunde machst, solltest du nicht immer neuen Speicher anfordern, sondern den gleichen verwenden.

c++0x schrieb:

D.h., dein Compiler unterstützt dieses Feature einfach nur noch nicht (oder es muss explizit aktiviert werden)

Kennst du (oder irgendwer sonst) ein Flag o. so, mit dem dass beim GNU GCC ginge... ?

Versuch mal -std=c++0x

Hallo!

Welchen Standardcontainer nutzt ihr, wenn es einfach um "rohen" Speicher geht, der in einem Schritt angefordert wird? vector?

Ja, vector<char> bzw. manchmal vector<unsigned char>.

Und verlasst ihr euch auf solche Optimierungen oder übergebt ihr den vector als Referenz?

Wenn die Funktion in performance-kritischen Abschnitten zum Einsatz kommt, dann übergebe ich Referenzen.
Die Kopie für's return kann zwar meist wegoptimiert werden, aber was immer bleibt ist dass der vector in der Funktion 1x neu angelegt wird.

Wenn man dagegen eine Referenz auf einen bestehenden vector übergibt, dann kann der aufrufende Programmteil diesen "recyclen". Das kann einiges sparen.

@krümelkacker
Gibt es wirklich Fälle wo "stepx_" != 1 wird?

Sicher. Anderes Speicherlayout (mit stepy_==1), Rotation um 90°, Unterabtastung, ...

raster<int> r = ...;
auto nav2 = rotate90(r.all());
auto nav3 = subsampleby2(r.all());