staging.inyokaproject.org

Ich grüße euch Ubuntuusers,

Ich hab aufgrund eigener Bedürfnisse eine Software geschrieben, die ich euch gerne vorstellen
möchte.

Es handelt sich hierbei um ein Tool, das es ermöglicht aus einem Template, mit eingebettetem Script-Code bzw.
Kommandos und Variablen und mehreren Dateien mit Inhalte, ein Webseitenprojekt mit mehreren HTMLs zu erstellen.

Funktionsweise Ein Homepage-Projekt, das von dem WebPlodder (so heißt das Programm) bearbeitet werden kann,
muss folgenderweise aussehen:

.
|-- default.template
`-- unterordner
    `-- index.page
|-- index2.page
...

In dem default.template File befindet sich quasi eine Schablone aus html code,
in den mehrere Befehle bzw. Skripte eingebettet werden, die dann später vom
WebPlodder ersetzt werden.

Die *.page Dateien sind einfache YAML Dateien in denen verschiedene "Variablen"
definiert werden.
Der WebPlodder parst nun also nacheinander sämtliche gefundenen *.page Dateien
und erstellt anhand derer und der Template Datei gleichnamige html Dateien.

In diesen html Dateien ist dann der dynamische Inhalt jeweils anhand der Informationen
in der page Datei ersetzt.

Dynamischer Inhalt
Der dynamische Inhalt in der Template Datei setzt sich aus Kommandos, Variablen und
eingebetteten Skripten zusammen.

Eine dynamische Sequenz wird immer durch eine geschweifte Klammer ('{') eingeleitet und
auch durch eine geschlossene geschweifte Klammer wieder beendet ('}').

Wie schon oben genannt gibt es 3 Arten dieses dynamischen Inhalts.
Zunächst einfache Kommandos.
Kommandos
Die Syntax sieht folgendermaßen aus:

{ Kommando-Name : Argument1, Arg2, ... }

Die Argumente können entweder Strings oder wieder dynamischer Inhalt sein.
Im Falle von Strings, müssen sie in doppelte Hochkommata gesetzt werden:

{ Kommando-Name : "Argument" }

Ein eingebautes Kommando, ist zum Beispiel set

{set : "Var", "Value" }

Es wird verwendet um Variablen zu setzen.
Variablen werden im Folgenden erklärt.

Variablen
Variablen sind einfach Symbole im Kontext, die durch ihren Wert ersetzt werden.
Beispiel:

{$ VarName }

Eingebettete Skripte
Der WebPlodder ist in der Lage eingebettete Skripte zu verarbeiten.
Dafür kann praktisch jede mögliche Skriptsprache verwendet werden, für die ein
Interpreter vorhanden ist und dieser Skripte von der Standardeingabe entgegen nehmen kann.

Im folgenden Beispiel wird die bash verwendet:
Um die Bash zu verwenden, muss sie erst im config-file des WebPlodder registriert werden.
Der WebPlodder gibt die Skripte immer über die Standardeingabe, des Interpreters weiter.
Da die bash das ohne zusätzliche Paramteter beherrscht, genügt folgender Eintrag in config-file:

bash: "bash"

Der Pfad des config-file lautet: $HOME/.webplodder/config.yaml

Ein Beispiel für ein eingebettetes Skript wäre nun:

{!bash
echo "hallo"
!}

Wie man deutlich erkennen kann, lautet die Syntax eines engebetteten Skripts folgendermaßen:

{!Configurations_name Skript-Code !}

Der WebPlodder exportiert vor der Ausführung eines Skripts, sämtliche zum dem Zeitpunkt vorhandene
Variablen als Umgebungsvariablen.
Das heißt, das Skript kann über Umgebungvariablen auf den Inhalt der aktuellen page Datei
zugreifen.

Alle diese Umgebungsvariablen bekommen alle das Prefix WP_.
Wenn in einer page Datei nun zum Beispiel folgender Code steht:

title: Beispiel-Titel

Dann würde folgender Skript-Code den Beispiel-Titel ausgeben:

{!bash
echo $WP_title
!}

Page file
Wie bereits oben gesagt, sind page Dateien einfache yaml Dateien, in denen Variablen definiert
werden.
Ein Beispiel wäre:

# Eine Beispiel page Datei
title: Irgendein Titel
content: Der Inhalt
  der Beispiel-Seite
variable1: value1
var2: value2

usw.

Laufzeit Optimierungen
Der WebPlodder besitzt 3 Cache Modi, die je nach Prozessor und
Arbeitsspeichertype optimierend wirken können.

Anhand dieser Modi, wird bestimmt wie viel, Daten in den Arbeitsspeicher
geschrieben werden sollen.

Der erste Modi ist non:
Damit werden keine Daten in den Speicher geschrieben, sondern immer nur auf das
Template-File verwiesen.
Bei langsamen Prozessoren kann dies zu Geschwindigkeitsverlust führen.

Der nächste Modi ist script:
Damit werden alle Skripte in den Arbeitsspeicher geschrieben, was bedeutet, dass
je nach nach Anzahl und Größe der eingebetteten Skripte viel Arbeitsspeicher in Anspruch
genommen werden kann.

Der dritte und höchste Modus ist all:
Damit wird praktisch das gesamte Template-File in den Arbeitspeicher ausgelagert.


Hinweis: Die Geschwindigkeitsgewinne unterscheiden sich, je nach Prozessor und
Arbeitsspeichertyp.

Bei schnellen Prozessoren ist praktisch kein Unterschied zu merken.
Außerdem kommt es immer drauf an, wie viele Dateien prozessiert werden müssen und
wie groß das Template-File ist.


Zum Schluss noch
Der WebPlodder ist zwar voll funktionsfähig aber noch in einem frühen Stadium.
Vor allem beim Code-Design ist das zu merken 😀.
Also bitte lieber Quellcode-Leser, erschrecke nicht, das wird sich noch ändern.

Konstruktive Verbesserungsvorschläge sind aber auf jeden Fall willkommen.


Zu haben ist das Projekt auf Google-Code:
http://code.google.com/p/webplodder/
Viel Spaß!
Gruß Domi

Ach ja, was ich fast vergessen hätte, der plodder hat auch nocht eine Plugin Schnittstelle.

Man kann selber Kommandos schreiben. In C++.

Eine entsprechende Klasse könnte folgendermaßen aussehen:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

#include <pluginobject.hpp>
#include <iostream>

using namespace std;

class TestPlugin : public webplodder::PluginObject {
    void launch(map<string,string>& pagemap, ostream& oStream,
            const std::vector<std::string>& args) throw() {

        oStream << "This is a test i'm writing some vars:\n";
        oStream << "  - title: " <<  pagemap["title"] << "\n";
        oStream << "Now I will introduce a new var: TEST" << "\n";
        pagemap["TEST"] = "TEST_VALUE";
        oStream << "I will print my arguments:\n";

        int i;
        for(i = 0; i < args.size(); ++i) {
            oStream << "  " << args[i] << "\n";
        }
        oStream << args.size();
    }
};

WP_EXPORT_PLUGIN(TestPlugin)

Ich denk der Code ist selbsterklärend. Der oStream ist direkt mit der Stelle, an die die Ausgabe des Kommandos kommt verknüpft.
Der Vector args beinhaltet die Parameter und die PageMap die Variablen, die
zum entsprechenden Zeitpunkt im Einsatz sind.

Das Plugin muss dann als einfache shared library kompiliert werden und folgendermaßen benannt werden:
<Name-des-Kommandos>.so

Dann legt mann es noch in folgendem Verzeichnis ab und fertig:
$HOME/.webplodder/plugins
Bei Fragen, fragen 😀

// EDIT: und ähm, der header pluginobject.hpp liegt den Sourcen bei.
Gruß Domi

make
Linking CXX executable plodder
/usr/bin/ld: cannot find -lboost_regex
collect2: ld returned 1 exit status
make[2]: *** [plodder] Fehler 1
make[1]: *** [CMakeFiles/plodder.dir/all] Fehler 2
make: *** [all] Fehler 2

BodomBeachTerror schrieb:

make
Linking CXX executable plodder
/usr/bin/ld: cannot find -lboost_regex
collect2: ld returned 1 exit status
make[2]: *** [plodder] Fehler 1
make[1]: *** [CMakeFiles/plodder.dir/all] Fehler 2
make: *** [all] Fehler 2

Mensch dieses vermalledeite CMake. Ich hab eigentlich alle Libraries in statischer Version
beigelegt und im CMakeLists file auch angegeben.
Bei mir gings, weil ich sie nebenher auch noch in shared version in /usr/local/lib installiert hatte.

Ich muss mal schaun, was das Problem, dass CMake da die boost libs nicht registriert.
Falls du Lust hast, kannst du dir die boost libs auch mal von Hand compilen und installieren.

Dann gehts auf jeden Fall.
Aber das ist kein Dauerzustand.
Ich kümmer mich drum.

Gruß Domi

Ich hab die boost libs eigentlich auch installiert 😀

BodomBeachTerror schrieb:

Ich hab die boost libs eigentlich auch installiert 😀

Mhm komisch scheins findet er sie nicht. Naja ich hab sowieso was in der CMake doc überlesen 😀 .

link_directory angaben gelten nur für Ziele, die danach angegeben sind.

Naja mit dem jetzigen RC müsst klappen. Hab ihn grad geuppt.

Zieh den und versuchs nochmal.

Übrigens danke für dein Interesse.
Gruß Domi

Genau der selbe Fehler :/

@do_machine: Man liefert keine statischen Bibliotheken mit, schon gar nicht im Repo. Statisch kompilierte Binaries auszuliefern, ist eine Sache, aber man erzwingt kein statisches Linken, liefert statische Bibliotheken nicht mit den Quellen mit, und checkt sie vor allem nie im Repo ein. Außerdem setzt man Build-Optionen wie -Wall nicht im Build-Skript, sondern konfiguriert den CMake-Cache entsprechend. Ich denke, Du solltest wirklich nochmal die CMake-Dokumentation lesen.

BodomBeachTerror schrieb:

Genau der selbe Fehler :/

Jetzt krieg ich aber langsam angst. Paste mal die tree Ausgabe des Ordners
und das CMakeLists.txt file hier rein.

Gruß Domi

Lunar schrieb:

@do_machine: Statische Bibliotheken im Repo?! Das ist nicht Dein Ernst, oder? So schwer ist es doch nicht, Boost-Bibliotheken mit CMake einzubinden ...

Und Flags wie "-Wall" setzt man auch nicht in der CMakeLists.txt. Dafür gibt es den CMake-Cache und die CMake-Konfiguration.

Ich bin mit cmake leider noch nicht so bewandert.
Außerdem sind die boost libs in der benötigten Version noch nicht in den Repos.
Da dachte ich, wärs für den Anwender am einfachsten, wenn ich die einfach dazu leg.

Wie würdest du es machen? Ich lass mich gern belehren.

Gruß Domi

tree webplodder-0.1rc/
webplodder-0.1rc/
|-- CMakeCache.txt
|-- CMakeFiles
|   |-- CMakeCCompiler.cmake
|   |-- cmake.check_cache
|   |-- CMakeCXXCompiler.cmake
|   |-- CMakeDetermineCompilerABI_C.bin
|   |-- CMakeDetermineCompilerABI_CXX.bin
|   |-- CMakeDirectoryInformation.cmake
|   |-- CMakeOutput.log
|   |-- CMakeSystem.cmake
|   |-- CMakeTmp
|   |   `-- CMakeFiles
|   |       `-- cmTryCompileExec.dir
|   |-- CompilerIdC
|   |   |-- a.out
|   |   `-- CMakeCCompilerId.c
|   |-- CompilerIdCXX
|   |   |-- a.out
|   |   `-- CMakeCXXCompilerId.cpp
|   |-- Makefile2
|   |-- Makefile.cmake
|   |-- plodder.dir
|   |   |-- build.make
|   |   |-- cmake_clean.cmake
|   |   |-- CXX.includecache
|   |   |-- DependInfo.cmake
|   |   |-- depend.internal
|   |   |-- depend.make
|   |   |-- flags.make
|   |   |-- link.txt
|   |   |-- progress.make
|   |   `-- src
|   |       |-- citerator.cpp.o
|   |       |-- main.cpp.o
|   |       |-- page.cpp.o
|   |       |-- parser.cpp.o
|   |       |-- plodder.cpp.o
|   |       |-- plugin.cpp.o
|   |       |-- popen2.cpp.o
|   |       |-- process.cpp.o
|   |       |-- processor.cpp.o
|   |       |-- syntaxerror.cpp.o
|   |       `-- templatefile.cpp.o
|   |-- Progress
|   |   |-- 1
|   |   |-- 10
|   |   |-- 11
|   |   |-- 2
|   |   |-- 3
|   |   |-- 4
|   |   |-- 5
|   |   |-- 6
|   |   |-- 7
|   |   |-- 8
|   |   |-- 9
|   |   `-- count.txt
|   |-- progress.marks
|   `-- TargetDirectories.txt
|-- cmake_install.cmake
|-- CMakeLists.txt
|-- include
|   `-- yaml-cpp
|       |-- conversion.h
|       |-- emitter.h
|       |-- emittermanip.h
|       |-- exceptions.h
|       |-- iterator.h
|       |-- mark.h
|       |-- node.h
|       |-- nodeimpl.h
|       |-- nodereadimpl.h
|       |-- nodeutil.h
|       |-- noncopyable.h
|       |-- null.h
|       |-- ostream.h
|       |-- parser.h
|       |-- stlemitter.h
|       |-- stlnode.h
|       |-- traits.h
|       `-- yaml.h
|-- lib
|   |-- libboost_filesystem.a
|   |-- libboost_program_options.a
|   |-- libboost_regex.a
|   |-- libboost_system.a
|   `-- libyaml-cpp.a
|-- Makefile
`-- src
    |-- citerator.cpp
    |-- citerator.hpp
    |-- main.cpp
    |-- page.cpp
    |-- page.hpp
    |-- parser.cpp
    |-- parser.cpp~
    |-- parser.hpp
    |-- plodder.cpp
    |-- plodder.hpp
    |-- plugin.cpp
    |-- plugin.hpp
    |-- pluginobject.hpp
    |-- popen2.cpp
    |-- popen2.hpp
    |-- process.cpp
    |-- process.hpp
    |-- processor.cpp
    |-- processor.hpp
    |-- runtimeerror.hpp
    |-- syntaxerror.cpp
    |-- syntaxerror.hpp
    |-- templatefile.cpp
    `-- templatefile.hpp

13 directories, 99 files

cat CMakeLists.txt 
cmake_minimum_required(VERSION 2.6)

add_definitions(-DDEBUG)
aux_source_directory(src SRC)
add_executable(plodder ${SRC})
set_target_properties(plodder PROPERTIES
                      COMPILE_FLAGS "-Wall")
link_directories(lib)
include_directories(include)
target_link_libraries(plodder boost_regex
                              boost_program_options
                              boost_filesystem
                              boost_system
                              yaml-cpp
                              dl)

BodomBeachTerror schrieb:

tree webplodder-0.1rc/
webplodder-0.1rc/
|-- CMakeCache.txt
|-- CMakeFiles
|   |-- CMakeCCompiler.cmake
|   |-- cmake.check_cache
|   |-- CMakeCXXCompiler.cmake
|   |-- CMakeDetermineCompilerABI_C.bin
|   |-- CMakeDetermineCompilerABI_CXX.bin
|   |-- CMakeDirectoryInformation.cmake
|   |-- CMakeOutput.log
|   |-- CMakeSystem.cmake
|   |-- CMakeTmp
|   |   `-- CMakeFiles
|   |       `-- cmTryCompileExec.dir
|   |-- CompilerIdC
|   |   |-- a.out
|   |   `-- CMakeCCompilerId.c
|   |-- CompilerIdCXX
|   |   |-- a.out
|   |   `-- CMakeCXXCompilerId.cpp
|   |-- Makefile2
|   |-- Makefile.cmake
|   |-- plodder.dir
|   |   |-- build.make
|   |   |-- cmake_clean.cmake
|   |   |-- CXX.includecache
|   |   |-- DependInfo.cmake
|   |   |-- depend.internal
|   |   |-- depend.make
|   |   |-- flags.make
|   |   |-- link.txt
|   |   |-- progress.make
|   |   `-- src
|   |       |-- citerator.cpp.o
|   |       |-- main.cpp.o
|   |       |-- page.cpp.o
|   |       |-- parser.cpp.o
|   |       |-- plodder.cpp.o
|   |       |-- plugin.cpp.o
|   |       |-- popen2.cpp.o
|   |       |-- process.cpp.o
|   |       |-- processor.cpp.o
|   |       |-- syntaxerror.cpp.o
|   |       `-- templatefile.cpp.o
|   |-- Progress
|   |   |-- 1
|   |   |-- 10
|   |   |-- 11
|   |   |-- 2
|   |   |-- 3
|   |   |-- 4
|   |   |-- 5
|   |   |-- 6
|   |   |-- 7
|   |   |-- 8
|   |   |-- 9
|   |   `-- count.txt
|   |-- progress.marks
|   `-- TargetDirectories.txt
|-- cmake_install.cmake
|-- CMakeLists.txt
|-- include
|   `-- yaml-cpp
|       |-- conversion.h
|       |-- emitter.h
|       |-- emittermanip.h
|       |-- exceptions.h
|       |-- iterator.h
|       |-- mark.h
|       |-- node.h
|       |-- nodeimpl.h
|       |-- nodereadimpl.h
|       |-- nodeutil.h
|       |-- noncopyable.h
|       |-- null.h
|       |-- ostream.h
|       |-- parser.h
|       |-- stlemitter.h
|       |-- stlnode.h
|       |-- traits.h
|       `-- yaml.h
|-- lib
|   |-- libboost_filesystem.a
|   |-- libboost_program_options.a
|   |-- libboost_regex.a
|   |-- libboost_system.a
|   `-- libyaml-cpp.a
|-- Makefile
`-- src
    |-- citerator.cpp
    |-- citerator.hpp
    |-- main.cpp
    |-- page.cpp
    |-- page.hpp
    |-- parser.cpp
    |-- parser.cpp~
    |-- parser.hpp
    |-- plodder.cpp
    |-- plodder.hpp
    |-- plugin.cpp
    |-- plugin.hpp
    |-- pluginobject.hpp
    |-- popen2.cpp
    |-- popen2.hpp
    |-- process.cpp
    |-- process.hpp
    |-- processor.cpp
    |-- processor.hpp
    |-- runtimeerror.hpp
    |-- syntaxerror.cpp
    |-- syntaxerror.hpp
    |-- templatefile.cpp
    `-- templatefile.hpp

13 directories, 99 files

cat CMakeLists.txt 
cmake_minimum_required(VERSION 2.6)

add_definitions(-DDEBUG)
aux_source_directory(src SRC)
add_executable(plodder ${SRC})
set_target_properties(plodder PROPERTIES
                      COMPILE_FLAGS "-Wall")
link_directories(lib)
include_directories(include)
target_link_libraries(plodder boost_regex
                              boost_program_options
                              boost_filesystem
                              boost_system
                              yaml-cpp
                              dl)

Jap da hast wohl nochmal ne falsche Version erwischt.
nimm am besten die files aus dem repo.
Aber wie gesagt scheint so als müsst ich mein Build System noch mal aufrollen.

Bin gespannt auf Lunars Antwort.

Gruß Domi

make
Scanning dependencies of target plodder
[  9%] Building CXX object CMakeFiles/plodder.dir/src/templatefile.cpp.o
[ 18%] Building CXX object CMakeFiles/plodder.dir/src/page.cpp.o
[ 27%] Building CXX object CMakeFiles/plodder.dir/src/popen2.cpp.o
[ 36%] Building CXX object CMakeFiles/plodder.dir/src/processor.cpp.o
[ 45%] Building CXX object CMakeFiles/plodder.dir/src/main.cpp.o
[ 54%] Building CXX object CMakeFiles/plodder.dir/src/plodder.cpp.o
[ 63%] Building CXX object CMakeFiles/plodder.dir/src/parser.cpp.o
[ 72%] Building CXX object CMakeFiles/plodder.dir/src/plugin.cpp.o
[ 81%] Building CXX object CMakeFiles/plodder.dir/src/syntaxerror.cpp.o
[ 90%] Building CXX object CMakeFiles/plodder.dir/src/citerator.cpp.o
[100%] Building CXX object CMakeFiles/plodder.dir/src/process.cpp.o
Linking CXX executable plodder
CMakeFiles/plodder.dir/src/main.cpp.o: In function `main':
main.cpp:(.text+0xf7): undefined reference to `boost::program_options::options_description::options_description(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned int)'
collect2: ld returned 1 exit status
make[2]: *** [plodder] Fehler 1
make[1]: *** [CMakeFiles/plodder.dir/all] Fehler 2
make: *** [all] Fehler 2

Also ich benutz Lucid, ist die boost Version trotzdem zu alt? Und wenn ja, wie sag ich ihm er soll die mitgelieferten benutzen? 😀

@domachine: Wenn Du Dich belehren lassen möchtest, dann lies die Dokumentation. Das führt dann in etwa zu so einem Quelltext:

1
2
3
4

find_package(Boost 1.40 REQUIRED COMPONENTS filesystem regex program_options …)
include_directories(${Boost_INCLUDE_DIRS})
…
target_link_libraries(plodder ${Boost_LIBRARIES})

Auch die Dokumentation zu aux_source_directory solltest Du nochmals lesen, denn dort wird explizit davon abgeraten, sie auf diese Art zu verwenden. Schreibe eine explizite Liste der Quelldateien, und schiebe die zugehörige CMakeLists.txt am besten noch in das Quellverzeichnis.

Ich lege Dir wirklich nahe, die Doku zu CMake nochmal zu lesen, und CMake-Skripte anderer Anwendungen (z.B. aus KDE) anzusehen. Dann bringt CMake Dir auch keine Probleme mehr, sondern hilft Dir.

Mir sind übrigens noch ein paar andere Probleme aufgefallen:

• throw-Klauseln in Deklarationen sollten nicht verwendet werden (siehe z.B. A Pragmatic Look at Exception Specifications).

• Dein Quelltext ist teils wohl nicht "exception-safe", weil Du Zeiger meist direkt verwendest. Da Dein Quelltext eh bereits von Boost abhängt, spricht nichts gegen die Verwendung von Smart Pointern (e.g. shared_ptr). Dadurch sparst Du Dir auch viele deletes.

• Ganz allgemein täte dem Quelltext Kommentare und Dokumentation (z.B. durch Doxygen) gut.

• Wieso gibt es popen2 zweimal?

• Wenn Du C++ nutzt, dann nutze auch C++-Typen. Es gibt keinen Grund, warum die Process-Schnittstelle C-Strings verlangt. Und auch keinen, warum sie C-Strings intern speichert, mit std::string wäre da einiges einfacher, und es wäre kein memcpy nötig.

• Für Iterator-Schleifen kannst Du boost foreach verwenden. Das ist lesbarer und komfortabler.

Lunar schrieb:

@domachine: Wenn Du Dich belehren lassen möchtest, dann lies die Dokumentation. Das führt dann in etwa zu so einem Quelltext:

1 2 3 4

find_package(Boost 1.40 REQUIRED COMPONENTS filesystem regex program_options …) include_directories(${Boost_INCLUDE_DIRS}) … target_link_libraries(plodder ${Boost_LIBRARIES})

Auch die Dokumentation zu aux_source_directory solltest Du nochmals lesen, denn dort wird explizit davon abgeraten, sie auf diese Art zu verwenden. Schreibe eine explizite Liste der Quelldateien, und schiebe die zugehörige CMakeLists.txt am besten noch in das Quellverzeichnis.

Ich lege Dir wirklich nahe, die Doku zu CMake nochmal zu lesen, und CMake-Skripte anderer Anwendungen (z.B. aus KDE) anzusehen. Dann bringt CMake Dir auch keine Probleme mehr, sondern hilft Dir.

Mir sind übrigens noch ein paar andere Probleme aufgefallen:

• throw-Klauseln in Deklarationen sollten nicht verwendet werden (siehe z.B. A Pragmatic Look at Exception Specifications).

• Dein Quelltext ist teils wohl nicht "exception-safe", weil Du Zeiger meist direkt verwendest. Da Dein Quelltext eh bereits von Boost abhängt, spricht nichts gegen die Verwendung von Smart Pointern (e.g. shared_ptr). Dadurch sparst Du Dir auch viele deletes.

• Ganz allgemein täte dem Quelltext Kommentare und Dokumentation (z.B. durch Doxygen) gut.

• Wieso gibt es popen2 zweimal?

• Wenn Du C++ nutzt, dann nutze auch C++-Typen. Es gibt keinen Grund, warum die Process-Schnittstelle C-Strings verlangt. Und auch keinen, warum sie C-Strings intern speichert, mit std::string wäre da einiges einfacher, und es wäre kein memcpy nötig.

• Für Iterator-Schleifen kannst Du boost foreach verwenden. Das ist lesbarer und komfortabler.

Puuh, ok ich muss erst schlucken. WOW!!
Aber Danke.

Ich mach mich sofort dran.
Das mit dem Quelltext hat ich ja schon angekündigt 😀.

Ich gelobe Besserung.

Ubrigens: Wenn wir grad dabei sind, hast du ne bessere Idee für das Prozesshandling?
Bin da nicht wirklich mit zufrieden. Hab aber nur die boost process gefunden.
Die scheint mir aber nicht ganz koscher.

Bis später.
Gruß Domi