vlib

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*

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