vlib

[volkard]

hi.
hab wieder ne version der vhlib soweit, daß man sie ohne zu kotzen anschauen kann.

http://www.volkard.de/vhlib.tar.bz2

die änderungen:

Stack.hpp
klasse Stack gebaut.
sehr schnell. braucht nicht umzukopieren wie Vector, hat aber dafür keinen
Iterator.
naja, sie rechnet damit, daß es auch einen memory allocator gubt, der speicherseiten (zum beispiel 4096 bytes) sauschnell liefern kann. muss noch gebaut werden.

Page.hpp
Page gebaut.
für viele zwecke dürfte es praktisch sein, eine ein RawArray zu haben, das
zusammen mit einem header genau in eine maschinenseite paßt. natürlich für
den Stack. und mal sehen, was noch kommt.

auf dem MSVC lauffähig gemacht. ab jetzt baue ich immer gleichzeitig für "Microsoft Visual C++ Toolkit" und "MinGW" unter win und "gcc" unter linux. hoffe, ich halte es durch. gibt es noch bestimmt compiler, die unbedingt mitmachen sollten?

alignof.hpp
_alignof wurde zum makro ALIGNOF. der msvc hat weder _alignof noch
_attribute((aligned)), er frißt aber tricks, die das umgehen. sie auch
compiler/msvc/RawObject.hpp

rdstc
rdtsc() für beide compiler gebaut.

unterverzeichnisse ./compiler, ./compiler/gcc, ./compiler/msvc und
./os, ./os/linux, ./os/windows

bitwise.hpp
ein paar bitwise funktionen gebaut.

compiler/msvc/assert.hpp
assert benutzt nun auf MSVC assume, wie sich das gehört.

arit.hpp
ein paar arithmetische funktionen gebaut. modulo-rechnen und sqrt(u64).

Array.hpp
klasse Array gebaut.
mit automatischer wahl, ob es auf dem heap oder stack liegen soll.
und natürlich indexgrenzenüberprüfung.

NoCopy.hpp
NoCopy zur basisklasse gemacht statt attribut.
wenn im debug-code das speicherlayout so oft anders ist, als im
release-code, bin ich einfach ein wenig unsicher. außerdem
schreibt sich das :NoCopy auch sehr schön.

PrimeGenerator.hpp
PrimeGenerator gebaut.
ein sieb. die neue version wird nicht so arschlahm, wenn man in bereichen
deutlich über 2^32 spielt.

Random.hpp
guter und schneller zufallszahlengenerator.

BitField.hpp
ein bitfield. optimiert für sieb des eratosthenes.

die nutzlosesten warnungen in compiler/msvc/compiler.hpp abgeschaltet.
mein liebling ist
#pragma warning(disable:4675)//koenig lookup used

namespace sys (system) umgenannt in namespace os (operating system), bei sys
war einfach nicht klar, ob's das os, der compiler oder der prozessor ist.

iostream.cpp
die Console flusht jetzt in underflow().

output-verzeichnis des normalen makefiles geändert in ./.out

bin erstmal wieder bei *.rar, weil mein tar.exe nicht einfach zu bedienen
ist mit unterverzeichnissen.

es ist noch nicht geprüft, welche seeds für Random in ordnung sind.

als lizenz denke ich mir sowas wie
[qoute]
nimmste die ganze vhlib oder wenigstens viel davon, dann gilt:
-machte eine credits-anzeige in deinem programm, mußte mich mit der vhlib auch reinschreiben.
-mußt im source-code reinschreiben, daß du sie genommen hast.

nimmste nur kleine teile aus der vhlib raus, raus, brauchste nix zu tun.
[/quote]
gibts sowas als licence schon fertig?

[stichwort]

sockets sind raus

[virtuell Realisticer]

volkard schrieb:

hi.
hab wieder ne version der vhlib soweit, daß man sie ohne zu kotzen anschauen kann.

Das hoert sich toll an, hab schon drauf gewartet

http://www.volkard.de/vhlib.rar

Ok, rar ist zwar etwas bloed, weil ich dann unrar installieren muss, aber es ist nicht der
Weltuntergang.

die änderungen:

Stack.hpp
klasse Stack gebaut.
sehr schnell. braucht nicht umzukopieren wie Vector, hat aber dafür keinen
Iterator.
naja, sie rechnet damit, daß es auch einen memory allocator gubt, der speicherseiten (zum beispiel 4096 bytes) sauschnell liefern kann. muss noch gebaut werden.

Page.hpp
Page gebaut.
für viele zwecke dürfte es praktisch sein, eine ein RawArray zu haben, das
zusammen mit einem header genau in eine maschinenseite paßt. natürlich für
den Stack. und mal sehen, was noch kommt.

auf dem MSVC lauffähig gemacht. ab jetzt baue ich immer gleichzeitig für "Microsoft Visual C++ Toolkit" und "MinGW" unter win und "gcc" unter linux. hoffe, ich halte es durch. gibt es noch bestimmt compiler, die unbedingt mitmachen sollten?

Darf ich noch ein Define fuer BSD machen? Gut, Linux geht hier auch, aber BSD unter BSD ist einfach
praktischer und wer weiss, vielleicht willst irgendwann mal Linuxspezifischen Code im Linuxspezifischen
Dateien bauen, weil du weisst das es einfach unter Linux praktischer ist und so waere dann ein 'BSD'
vielleicht auch praktisch, weil dann Leute hingehen koennen und einfach BSD-spezifischen Code bauen
koennen.

Ist das ok?

alignof.hpp
_alignof wurde zum makro ALIGNOF. der msvc hat weder _alignof noch
_attribute((aligned)), er frißt aber tricks, die das umgehen. sie auch
compiler/msvc/RawObject.hpp

rdstc
rdtsc() für beide compiler gebaut.

unterverzeichnisse ./compiler, ./compiler/gcc, ./compiler/msvc und
./os, ./os/linux, ./os/windows

bitwise.hpp
ein paar bitwise funktionen gebaut.

compiler/msvc/assert.hpp
assert benutzt nun auf MSVC assume, wie sich das gehört.

arit.hpp
ein paar arithmetische funktionen gebaut. modulo-rechnen und sqrt(u64).

Array.hpp
klasse Array gebaut.
mit automatischer wahl, ob es auf dem heap oder stack liegen soll.
und natürlich indexgrenzenüberprüfung.

NoCopy.hpp
NoCopy zur basisklasse gemacht statt attribut.
wenn im debug-code das speicherlayout so oft anders ist, als im
release-code, bin ich einfach ein wenig unsicher. außerdem
schreibt sich das :NoCopy auch sehr schön.

PrimeGenerator.hpp
PrimeGenerator gebaut.
ein sieb. die neue version wird nicht so arschlahm, wenn man in bereichen
deutlich über 2^32 spielt.

Random.hpp
guter und schneller zufallszahlengenerator.

BitField.hpp
ein bitfield. optimiert für sieb des eratosthenes.

die nutzlosesten warnungen in compiler/msvc/compiler.hpp abgeschaltet.
mein liebling ist
#pragma warning(disable:4675)//koenig lookup used

namespace sys (system) umgenannt in namespace os (operating system), bei sys
war einfach nicht klar, ob's das os, der compiler oder der prozessor ist.

iostream.cpp
die Console flusht jetzt in underflow().

output-verzeichnis des normalen makefiles geändert in ./.out

bin erstmal wieder bei *.rar, weil mein tar.exe nicht einfach zu bedienen
ist mit unterverzeichnissen.

es ist noch nicht geprüft, welche seeds für Random in ordnung sind.

als lizenz denke ich mir sowas wie
[qoute]
nimmste die ganze vhlib oder wenigstens viel davon, dann gilt:
-machte eine credits-anzeige in deinem programm, mußte mich mit der vhlib auch reinschreiben.
-mußt im source-code reinschreiben, daß du sie genommen hast.

nimmste nur kleine teile aus der vhlib raus, raus, brauchste nix zu tun.

gibts sowas als licence schon fertig?[/quote]

Ui, gute frage. Morgen werd ich mir mal ein paar Lizensen anschauen. Evtl. ist was dabei, ansonsten kann
man ja vielleicht grad was kleines selbst bauen?

mfg
v R

[volkard]

stichwort schrieb:

sockets sind raus

ja, kurzfristig. bei der ganzen umstellung wiedermal hab ich stück für stück reingemacht, bis das aktuelle programm, der primzahlenzähler klappte.

[virtuell Realisticer]

uebrigens, richtig schoen. Aufm gcc4 zumindest uebersetzt der Code in nur ein paar Sekunden. Ach wie ich das
liebe, wenn die Dateien nur so durch den Compiler gejagt werden

mfg
v R

[volkard]

virtuell Realisticer schrieb:

Darf ich noch ein Define fuer BSD machen? Gut, Linux geht hier auch, aber BSD unter BSD ist einfach praktischer und wer weiss, vielleicht willst irgendwann mal Linuxspezifischen Code im Linuxspezifischen Dateien bauen, weil du weisst das es einfach unter Linux praktischer ist und so waere dann ein 'BSD' vielleicht auch praktisch, weil dann Leute hingehen koennen und einfach BSD-spezifischen Code bauen
koennen.
Ist das ok?

wie erkennt der gcc denn BSD?

wäre dann angebracht zu schreiben

#ifndef OS_HPP
#define OS_HPP

#ifdef _WIN32
#include "os/windows/os.hpp"
#endif

#ifdef __linux__
#include "os/linux/os.hpp"
#endif

#ifdef __bsd__
#include "os/bsd/os.hpp"
#endif

#endif

und man kopiert die linux-sachen nach bsd? oder sind die unterschiede so klein, daß man besser innerhalb von linux ein wenig mit #ifdef rumwirft?

am besten wohl, wir hoffen, machen erstmal

#ifdef __bsd__
#include "os/linux/os.hpp"
#endif

und du schreist, sobald was nicht klappt. und dann entscheiden wir, weil wir sehen, wie schwerwiegend es ist.

Ui, gute frage. Morgen werd ich mir mal ein paar Lizensen anschauen. Evtl. ist was dabei, ansonsten kann man ja vielleicht grad was kleines selbst bauen?

thx.
ich fürchte, sowas gibt's noch nicht. also mich hat es immer gestört, wenn ich nen dreizeiler wo rausklauen wollte, daß ich dessen ganze lizenz bei mir reinhauen mußte. schwachpunkt an meinem ansatz ist natürlich, daß einer alles bis auf eine funktion klaut und sagt, daß seien alles nur kleinigkeiten.

[virtuell Realisticer]

volkard schrieb:

virtuell Realisticer schrieb:

Darf ich noch ein Define fuer BSD machen? Gut, Linux geht hier auch, aber BSD unter BSD ist einfach praktischer und wer weiss, vielleicht willst irgendwann mal Linuxspezifischen Code im Linuxspezifischen Dateien bauen, weil du weisst das es einfach unter Linux praktischer ist und so waere dann ein 'BSD' vielleicht auch praktisch, weil dann Leute hingehen koennen und einfach BSD-spezifischen Code bauen
koennen.
Ist das ok?

wie erkennt der gcc denn BSD?

Das muesste man natuerlich haendisch dann definieren. Gut, das ist natuerlich auch irgendwo bloed.

wäre dann angebracht zu schreiben

#ifndef OS_HPP
#define OS_HPP

#ifdef _WIN32
#include "os/windows/os.hpp"
#endif

#ifdef __linux__
#include "os/linux/os.hpp"
#endif

#ifdef __bsd__
#include "os/bsd/os.hpp"
#endif

#endif

und man kopiert die linux-sachen nach bsd? oder sind die unterschiede so klein, daß man besser innerhalb von linux ein wenig mit #ifdef rumwirft?

am besten wohl, wir hoffen, machen erstmal

#ifdef __bsd__
#include "os/linux/os.hpp"
#endif

und du schreist, sobald was nicht klappt. und dann entscheiden wir, weil wir sehen, wie schwerwiegend es ist.

Jo, das koennen wir ruhig erstmal machen und konzentrieren dann erstmal auf die Lib, statt auf
OS-spezifischen Code. Es wird ja eigentlich erst dann richtig spezifisch, wenn man mal auf z. B.
Kernelsourcen zurueckgreifen muss. Bei solchem Code, der ja manchmal auch noetig ist, weil einfach
bestimmte Dinge leichter zu bewerkstellen sind oder bestimmte Strukturen schon definiert sind, hat man
dann natuerlich unter anderen Systemen verloren und braucht alternativen.

Ok, vielleicht bin ich hier etwas kleinlich und man braucht es erstmal nicht, bis die Lib mal etwas
umfangreicher ist oder so. Weiss auch nicht, irgendwie kam mir da ploetzlich der Gedanke ins Hirn und
ich musste das niederschreiben ;).

Ui, gute frage. Morgen werd ich mir mal ein paar Lizensen anschauen. Evtl. ist was dabei, ansonsten kann man ja vielleicht grad was kleines selbst bauen?

thx.
ich fürchte, sowas gibt's noch nicht. also mich hat es immer gestört, wenn ich nen dreizeiler wo rausklauen wollte, daß ich dessen ganze lizenz bei mir reinhauen mußte. schwachpunkt an meinem ansatz ist natürlich, daß einer alles bis auf eine funktion klaut und sagt, daß seien alles nur kleinigkeiten.

Ok, das kann man ja weiter einschraenken indem man z. B. sagt, wenn man mehr als X Prozent der Lib nutzt
oder so. Weiss ich auch nicht so recht, kenne mich mit Lizensaufsetzen nicht so aus :). Aber irgendwie
wird man das wohl auch beschraenken koennen. Denn was du da als negativen Effekt aufgeschrieben hast, waere
ziemlich aergerlich, schliesslich steckste einen haufen Arbeit rein und da kann man von anderen ruhig
erwarten, dass sie den Autor zumindest erwaehnen. Sie profitieren ja auch davon.

mfg
v R

[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?