vlib

[ness]

Ich fände es ja nicht schlecht, wenn du das root directory deiner bibliothek mitpacken würdest.

[volkard]

ness schrieb:

Ich fände es ja nicht schlecht, wenn du das root directory deiner bibliothek mitpacken würdest.

sorry. mach ich natürlich immer. hab's nur gerade vergessen, als ich hastig wieder nach rar umgestellt hab.
edit: ist geändert.
aber leiber würde ich wieder tar benutzen. ich weiß nur nicht, wie ich das mit unterverzeichnissen fein mache.
edit2: geht mit tar. vhlib.tar.bz2 ist da.

[Ben04]

Ich hab jetzt nur mal kurtz den Code überflogen und mir ist folgendes aufgefallen:

#ifndef COMPILER_GCC_RDTSC_HPP
#define COMPILER_GCCC_RDTSC_HPP

Ich glaub da ist dir ein Tippfehler unterlaufen.

[volkard]

Ben04 schrieb:

Ich hab jetzt nur mal kurtz den Code überflogen und mir ist folgendes aufgefallen:

#ifndef COMPILER_GCC_RDTSC_HPP
#define COMPILER_GCCC_RDTSC_HPP

Ich glaub da ist dir ein Tippfehler unterlaufen.

thx, ist repariert.

[volkard]

so, ich hab wieder einen tollen plan.
ich mach alle iteratoren meiner container range-checked.
ist ne schlimme arbeit und ich blicke nicht mehr durch, was da alles passiert. *g*

[info]

vhlib 0.03 wird heute released.

[GPC]

@volkard
Was soll denn noch alles in die vhlib reinkommen? Nachdem ein stack drin ist, willst du auch noch andere container wie listen, trees usw. einbauen?

[volkard]

GPC schrieb:

@volkard
Was soll denn noch alles in die vhlib reinkommen? Nachdem ein stack drin ist, willst du auch noch andere container wie listen, trees usw. einbauen?

vector ist da.
array wird gerade umgebaut.
stack ist ja ne liste irgendwie.
queue kommt natürlich auch und ist auch irgendwie ne liste.
sehe eigentlich keinen bedarf für ne andere liste.
und heap kommt. den brauch ich oft.
und irgendwie ne map. wohl als hashtable.

das ist dann eigentlich das, was ich oft brauche. das genannte kommt auf jeden fal rein. für mehr sehe ich noch keinen bedarf.

[GPC]

Ok, da du Stack und Queue gerade ansprichst und irgendwie als listen ansiehst ;), warum dann nicht ne liste als Grundlage für die beiden? Die STL macht's ja ähnlich mit den Adapterklassen. Oder wäre das nicht im Sinne deines Konzeptes, bzw. einfach den Aufwand nicht wert, da du anscheinend ne normale liste nicht gerade oft benutzt?

[volkard]

GPC schrieb:

Ok, da du Stack und Queue gerade ansprichst und irgendwie als listen ansiehst ;), warum dann nicht ne liste als Grundlage für die beiden? Die STL macht's ja ähnlich mit den Adapterklassen. Oder wäre das nicht im Sinne deines Konzeptes, bzw. einfach den Aufwand nicht wert, da du anscheinend ne normale liste nicht gerade oft benutzt?

sie sind "irgendwie" listen heißt, sie sind einfach verkettete listen von Pages, und eine Page ist 4096 bytes groß.
zur zeit nicht gerade fein implementiert als

#ifndef PAGE_HPP
#define PAGE_HPP

#include "RawArray.hpp"

class PageBase{
};

template<typename Header,Size dataSize,Size dataAlignment>
struct RawPage:public PageBase{
	Size const static size=(4096-sizeof(Header))/dataSize;
	RawArray<dataSize,dataAlignment,size> array;
	Header header;
};

#endif

#ifndef STACK_HPP
#define STACK_HPP

#include "Page.hpp"
#include "swap.hpp"

template<Size dataSize,Size dataAlignment>
class RawStack:NoCopy{
private:
	struct Header{
		PageBase* next;
	};
	typedef RawPage<Header,dataSize,dataAlignment> Page;
	Page* top;
	Size max;
public:
	RawStack(){
		top=0;
		max=Page::size-1;
	};
	void* alloc(){
		++max;
		if(max==Page::size){
			Page* page=new Page;
			page->header.next=top;
			top=page;
			max=0;
		}
		return peek();
	}
	void* peek() const{
		return (top->array)[max];
	}
	void pop(){
		if(max==0){
			Page* toDie=top;
			top=static_cast<Page*>(top->header.next);
			delete toDie;
			max=Page::size;
		}
		--max;
	}
	bool isEmpty(){
		return top==0;
	}
	friend void swap(RawStack& a,RawStack& b){
		swap(a.top,b.top);
		swap(a.max,b.max);
	}
};

template<typename T>
class Stack:NoCopy{
private:
	RawStack<sizeof(T),ALIGNOF(T)> data;
public:
	~Stack(){
		while(!isEmpty())
			pop();
	}
	void* alloc(){
		return data.alloc();
	}
	T& peek() const{
		return *static_cast<T*>(data.peek());
	}
	void pop(){
		peek().~T();
		data.pop();
	}
	bool isEmpty(){
		return data.isEmpty();
	}
	friend void swap(Stack& a,Stack& b){
		swap(a.data,b.data);
	}
};

template<typename T>
inline void* operator new(Size,Stack<T>& s){
	return s.alloc();
}

template<typename T>
inline void operator delete(void* p,Stack<T> s){
	s.pop();
}

#endif

und da wird Queue eigenen code brauchen.

ansonsten bin ich ein ganz großer freund davon, code wiederzeuverwenden (z.B. werden beide klassen Page benutzen).

[GPC]

Ok, gecheckt
Solange die Page arbeitet, und nicht uneffizient ist, dann reicht's ja. Willst du die Geschichte eigentlich speziell für Small-Objects optimieren?

ansonsten bin ich ein ganz großer freund davon, code wiederzeuverwenden (z.B. werden beide klassen Page benutzen).

Logo, wozu haben wird denn OOP :), mach das schließlich grad ähnlich, sobald meine liste fertig ist(verfluchter sort-algo ), werd ich ne queue und nen stack drumrumbauen.

[volkard]

GPC schrieb:

Ok, gecheckt
Solange die Page arbeitet, und nicht uneffizient ist, dann reicht's ja. Willst du die Geschichte eigentlich speziell für Small-Objects optimieren?

es muß auch kleinere Pages geben. ich hab da zum beispiel einen algo, der um so schneller ist, je mehr stacks ich benutze. da sollte ich auch 256 bytes große pages unter den stack legen können. also kriegt Page wohl noch nen size_t als template-parameter. und die vielen stacks könnten ne gemeinsame freispeicherliste haben. vielleicht kriegt Stack noch eine allokator als parameter.

und unabhängig davon muß für allgemeine verwendung auch mal ein small-object-allocator gebaut werden.

irgendwann später mal... die range-checked iteratoren sind viel komplizierter geworden, als ich gedacht hab. hab zwischenzeitlich nicht durchgeblickt und den fehler gemacht, das komplizierte zeug nicht sofort zu löschen.

[volkard]

GPC schrieb:

verfluchter sort-algo

du baust nicht zufällig auch nen sort-algo für arrays?

[volkard]

version 0.011 (noch recht unsauber und zum teil sind die unten gesagten sachen doch noch noch nicht drin). http://volkard.de/vhlib.tar.bz2

für Array und Vector gilt:
wenn ANZAHL>0, dann
Array<int,ANZAHL,false> a;//ANZAHL ints auf dem stack (bzw im objekt)
Array<int,ANZAHL,true> a;//ANZAHL ints auf dem freispeicher
Array<int,ANZAHL> a;//ANZAHL ints auf dem freispeicher, falls
//ANZAHL*sizeof(int)>4096
wenn ANZAHL==0, dann
Array<int,0> a(10);//10 ints auf dem heap.
Array<int> a(10);//10 ints auf dem heap.
außerdem hat Array/Vector nur dann einen zuweisungsoperator, wenn die daten
auf dem freispeicher liegen. wegen exceptionsicherheit. nen copy-ctor gibts
immer.

Queue wurde von MrN gebaut.

auch betriebssysteme ohne strerror_r wie FreeBSD compilieren jetzt.

linux wurde umgenannt nach default und statt #ifdef __linux__ steht jetzt
#else. falls mal linux und bsd gespalten werden müßten, kann man das besser
möglichst spät machen.

klasse StringLiteral erstmal wieder fallengelassen. ist zu unpraktisch. kommt
wohl erst wieder, wenn unicode oder utf8 anstehen.

osImpl.hpp benutzt kein using namespace os mehr. sie ist ja immerhin auch
nur ne hpp.

swap ist nur noch für typen gültig, für die es explizit gesagt wurde.

alle iteratoren werden range-checked.

komplettes rewrite von Array.

assert.hpp
assert und ASSERT in ASSERT und STATIC_ASSERT geändert.
CHECK gebaut. ist wie assert, aber wird immer ausgewertet.
also bei CHECK(CloseHandle(file)!=INVALID_HANDLE_VALUE) wird auch
nach #define NDEBUG das CloseHandle(file) aufgerufen, aber dann wird
nicht getestet, ob es funktionierte.

FileReader.hpp
FileReader gebaut.

Vector.hpp
Vector gebaut. Vector ist da, damit man ihn als allocator benutzt und damit
objekte hineinerzeugt. der speicher ist in einem stück. er hat einen schnellen
Iterator. beim wachsen kopiert er um. vector ist kein array-ersatz, womit ich
mich von der üblichen stl-verwendung unterscheide. dafür gibt es hier Array.

swap.hpp
funtion swap in ne eigene datei getan.

FileWriter.hpp
FileWriter gebaut.
wenn nicht sicher ist, daß das schreiben klappt, und wenn so ein schreibfehler
gefangen werden soll, muß man per hand am ende flush() aufrufen, damit
keine exception im dtor fliegen kann.

[dali]

Woher kommt eigentlich der vielsagende Name vhlib?

[Caipi]

dali schrieb:

Woher kommt eigentlich der vielsagende Name vhlib?

Ist wahrscheinlich ein Kürzel für Volkard Henkel Library
Der Name entstand wahrscheinlich aus Mangel an weiterer Fantasie :p

[dali]

Jeap wäre naheliegend

[volkard]

Caipi schrieb:

dali schrieb:

Woher kommt eigentlich der vielsagende Name vhlib?

Ist wahrscheinlich ein Kürzel für Volkard Henkel Library
Der Name entstand wahrscheinlich aus Mangel an weiterer Fantasie :p

stimmt beides.
vielleicht sollte ich sie in "vlib" umnennen? klingt viel fantasievoller, gell?
so. http://volkard.de/vlib.tar.bz2 (iteratoren von vector und array endlich sind alle range-checked.)

[_]

volkard denkt ans heiraten.

[GPC]

volkard schrieb:

GPC schrieb:

verfluchter sort-algo

du baust nicht zufällig auch nen sort-algo für arrays?

Sorry dass ich das erst jetzt lese, hab das irgendwie übersehen.
Momentan bastel ich noch am QuickSort und Mergesort für meine LinkedList.
Ich hätte zwar durchaus Interesse einen für Arrays zu schreiben(bräuchte selber mal einen), allerdings müsste ich mir erstmal deine vhlib genau ansehen, wie sie aufgebaut ist, dein Design, entsprechende Konventionen usw. . Wenn ich dann meine, ich wäre gut genug um einen guten algo zu schreiben, hätte ich schon lust dazu.

//EDIT: Dauert dir aber wohl zu lange, bis ich da fertig wär.