Der Umgang mit SyncToy
Da Synctoy ein eher einfach gehaltenes Programm ist gibt es ein kleines Problem mit der Automatisierung, weil es keinerlei Scheduler anbietet. Aber da ist einem schnell geholfen.

Als erstes erstellt man sich in Synctoy ein Profil, welche Ordner man wo synchronisieren möchte und mit welchen Einstellungen. Ich empfehle hier einfach jeder, der es benutzen will ein wenig mit den Möglichkeiten rum zu spielen und sich klar zu machen, wie das ganze funktioniert. Es ist nicht all zu wild und man steigt sehr schnell dahinter.

So. Wenn wir jetzt unser Profil erstellt haben können wir das mit Synctoy starten und ausführen lassen. Allerdings möchte man nicht jeden Tag daran denken das Programm zu starten. Es gibt allerdings ein sehr geniales Tool schon bei Windows mit dabei, welches dazu gedacht ist Programme zu einem bestimmten Interval auszuführen. Der Windows Taskplaner. Nun können wir ganz einfach einen Task anlegen, welcher für uns dann täglich (z.B um 20:00 Uhr) ein Programm startet. Glücklicherweise unterstützt Synctoy Kommandozeilenargumente und lässt sich dadurch recht gut steuern. Allerdings lassen sich solche Aktionen nur sehr beschränkt im Taskplaner eintragen. Aber auch das ist kein Problem, wenn wir einfach ein Batchfile zur Hilfe nehmen. Bei mir sieht das dann so aus:

@echo off echo Mobile Sync: Bitte schliesse die externe HD an. pause echo Synchronisation des Profils 'mobile_sync' startet... "C:ProgrammeSyncToy 2.0SyncToyCmd.exe" -R "mobile_sync" echo Beendet! pause

- Unbekannt -

Und das wird dann ganz einfach als .bat irgendwo gespeichert und vom Taskplaner zur gewünschten Zeit ausgeführt. Wie man sehen kann, kann man mit dem -R Schalten sein Profil angeben, welches gestartet werden soll. Sehr einfach, aber äusserst effizient.

Fazit
Nun. Jetzt komme ich zum Grund, warum ich den Artikel nicht bereits im Sommer veröffentlichen wollte, weil ich ja noch gar keine Zeit hatte das ganze zu testen. Und jetzt läuft das ganze seit über einem Jahr einwandfrei und ich fühle meinde Daten sicher und äusserst synchron. Zeit wende ich auch keine auf, um das ganze so zu halten und daher bin ich sehr zufrieden mit dem System und kann das oder ein ähnliches System jedem empfehlen, der ein wenig mehr auf die Integrität seiner Daten achten möchte.

Wie immer bin ich für Kommentare, Anmerkungen, Vorschläge usw. offen und bin auch gerne bereit noch mehr Einzelheiten zu erklären, falls etwas unklar ist.
Keine Kommentare | Kommentieren

Dieser Artikel hat jetzt länger auf sich warten lassen, als ich wollte, aber schlussendlich ist er doch da.

Und es geht erneut um C++0x. Ich habe ja bereits angetönt, dass es diesmal etwas über die "verstecken" Features geben wird. Allerdings wird auch das hier nicht annährend komplett, da es auch sonst noch recht viel neues gibt. Aber ich gebe einfach mal eine Auswahl, was ich so subjektiv interessant/hilfreich finde. Die folgenden Features sind meist nicht sehr weltbewegend, aber es hat halt viele Dinge dabei, welche implizit von Programmierern tatsächlich vermisst wurden. Dazu kommen Sachen, welche das Typsystem noch erweitern und auch Sachen, etwas, was den Kompilierungsprozess im Zusammenhang mit templates verringern soll.

Ich fange gleich mal mit den Sachen an, welche den Programmieralltag erleichtern sollen.

range for statements
Als erstes gleich etwas, was in vielen Sprachen bereits länger, als z.B "foreach" etabliert ist. Oft ist es ja der Fall, dass man ganz einfach über einen kompletten Container (Liste, Array o.ä ) iterieren und mit jedem Element etwas machen will. Bis jetzt hat das ja in etwa so ausgesehen:

typedef std::list<int> container_type;
containter_type elements;
 
for (container_type::iterator it = elements.begin (), end = elements.end ();
it != end; ++it
{
  // mache etwas mit it
}

Nicht elegant und lesbar für etwas, was als Standardaufgabe angesehen wird. Nun bietet boost eine Bibliothek namens foreach an und man kann das ganze dann in etwa so schreiben:

BOOST_FOREACH (int e, elements )
{
  // mache etwas mit e
}

Sieht ja eigentlich nicht schlecht aus und ich benutze das selst auch sehr gerne. Nur wäre es schön, wenn man solche Standardaufgaben von Haus aus einfach erledigen kann und da nicht gleich boost und das riesen Makro, was es für BOOST_FOREACH verwendet zu benutzen. Daher gibt es mit C++0x auch eine leicht modifizierte Version der for-Schleife:

 
for (int e: elements ) // Variable für jedes Element, : , Container
{
  // mache etwas mit e
}
 

Einfach, kurz, klar. Ein wirklich nettes Features, dass das Iterationsherz höher schlagen lassen sollte.

delegating constructors
Das wohl meist verlangte Feature von Anfängern, die sich fragen: "Warum muss ich in jedem Konstruktor alle Parameter angeben, warum kann ich nicht einfach einen anderen Konstruktor aufrufen?!". In der Tat ist das eine gute Frage, auf die ich keine Antwort weiss, aber man kann das ein wenig umgehen, und eine init Funktion benutzen, welche einfach in jedem Konstruktor aufgerufen wird. Das hat aber den Nachteil, dass das nicht wirklich Initialisierungen sind, sondern lediglich Zuweisungen. Bei den meisten Typen spielt es keine Rolle, aber sobald man Referenzen oder const Ausgezeichnete Member in einer Klasse hat, funktioniert das dann nicht mehr. C++0x bietet die Lösung und lässt genau das zu, was man intuitiv erwarten würde:

 
class foo
{
 int n_;
 
 public:
  foo ( int n ):n_( n ){} 
  foo ():foo{ 2 }{} // Aufruf mit den geschweiften Klammern
};
 

Natürlich ist das nicht nur bei der Initialisierung nützlich, sondern auch, um zu verhindern, dass man für "normalen" Initialisierungscode, wie z.B das berechnen eines Zustandes in eine seperate private Funktion auslager muss, sondern den einmal innerhalb eines Konstruktor implementiert werden kann.

in-class member initializers
Dieses Feature vereinfacht die Initialisierung von Datenmembern, wie auch schon delegating constructors. Es geht darum die Möglichkeit, welche im Moment lediglich mit konstanten, statischen Membern möglich ist. Nämlich das initialisieren von Datenmebern in der Klasse selbst.
Effektiv können wir dann folgendes schreiben:

class foo
{
  int n_ = 2;
};

Sprich es ist nicht nötig einen eigenen Konstruktor schreiben zu müssen, um lediglich Datenmember zu initialisieren. Vor allem, wenn wir mehrere Konstuktoren haben, müssen wir nicht überall jede Member initialisieren, sondern lediglich die, die wir anderst haben wollen. Also:

class foo
{
  foo ( int n ) : n_ ( n ) {} //n_ ist variabel und b_ wird mit 2 initialisiert
  int n_ = 0; // üblicherweise 0
  int b_ = 2; // üblicherweise 2
};

Dieses Feature erhöht die Lesbarkeit von Klassen und vor allem die der Konstuktoren enorm. Ebenfalls verhindert sie Fehler und inkonsitentes verhalten bei mehreren Konstuktoren. Natürlich bringt diese Art der Initialisierung auch einige Probleme, welche unter anderem darauf beruhen, dass man nicht die Notation mit der Zuweisung wählt, sondern den Konstuktor aufruft. z.B:

class foo
{
  int n_ ( x ); // ist x ein Typ oder ein Ausdruck?
  typedef int x; // erst jetzt wissen wir es, es ist aber nun zu spät
};

Wer dazu mehr erfahren möchte, kann das in dem Paper nachlesen.

preventing narrowing
Ein eher kleines Feature ist, dass narrowing, also das beschneiden von Werten mit der {}-Initialisierung ein Fehler wird. Meiner Meinung nach zu recht. Beispiel:

int x = {7.7}; // error narrowing

Keine Kommentare | Kommentieren

raw strings literals
Wer kennt das nicht. Das ewige escapen in strings? - Speziell in Webanwendungen merkt man das, aber auch in Sprachen, welche eher selten für Webanwendungen gebraucht werden kommen Zeichenfolgen vor, welche gekennzeichnet werden müssen, dass sie eben nicht speziell sind. Z.B in Regex Ausdrücken:

string s = "\w\\\w";

Hässlich, oder? In C++0x wird es dann die Möglichkeit geben einen rohen String zu definieren und das Beispiel wird sehr viel lesbarer:

string s = R"[w\w]";

Das R und die eckigen Klammern kennzeichnen einen solchen String. Man kann aber (falls eckige Klammern in dem Ausdruck gebraucht werden) auch etwas anderes als Begrenzung wählen:

string s = R"---[kein Problem: "[]"! ]---";

attributes
Bekannterweise möchte ja jeder Compilerhersteller sein eigenes Süppchen kochen und bietet daher verschiedene nicht-standardisierte Möglichkeiten das im Code festzuhalten, wie beim MSVC __declspec () oder beim GCC __attribute__(()). Mit Attibuten möchte man eine einheitliche Möglichkeit geben das im Code festzuhalten, ohne den eigentlichen Code oder Syntax Regeln durcheinandern zu bringen. Bsp:

struct A
{
 virtual void foo [[final]] (); //nicht überschreibbar
};
struct B : A
{
 void foo (); // error
};
 

Es soll auch eine bessere Unterstützung für OMP geben, was im Moment durch ein Haufen Makro Anweisungen umgesetzt ist.

extern templates
Ein Problem von templates ist ja, dass sie jedesmal, wenn sie instanziert werden kompiliert werden müssen. Das kann sehr viel Zeit brauchen, auch wenn gewisse templates mehrfach gebraucht werden. Darum gibt es mit C++0x die Möglichkeit eine Spezialisierung eines templates als extern zu markieren und die wirkliche kompilierung dessen irgendwo anderst hin zu verlagern:

extern template class MyVector<int>; //keine Instanzierung. Irgendwo definiert.
 
void foo (MyVector<int> v){} // Benutzung möglich

Und irgendwo (in einer anderen Übersetzungseinheit) ist dann das hier:

template class MyVector<int>; // Instanzieren und für alle zugänglich machen

inline namespaces
Und nun noch zum letzten Feature, dass ich vorstellen möchte und auch der Initiale Grund war diesen Artikel zu schreiben. Nämlich inline namespaces. Was mag das wohl sein? Zuerst ein wenig Code und dann warum das Problem nicht mit aktuellen Mitteln gelöst werden kann:

namespace impl
{
 inline namespace impl_2010 { void foo (); }
 namespace impl_2009 { void foo (); }
}

Und im Code kann ich dann entweder die Defaulimplementierung benutzen (also die geinlinete) oder speziell auf die alte verwiesen werden:

using namespace impl;
impl_2009::foo ();
impl_2010::foo ();
foo (); // gleich, wie impl_2010::foo();

Das inline bewirkt also eine Art ausleerung in den aktuellen namespace. Doch wo ist der Unterschied zu der using Deklaration mag sich der beflissene Leser fragen. Doch diese Möglichkeit (und für ein paar andere siehe [7]) funktioniert aus diversen Gründen nicht. Z.B kann ADL (argument dependent looup) teilweise nicht funktionieren. Spezialisierung von templates funktioniert mit using auch nicht immer. Auch etwas, wie namesapce aliases könnten das Problem nicht lösen.
Mit inline namespaces und vielleicht einem Präprozessor Makro kann sehr elegant zwischen den beiden Implementierungen gewechselt werden. Und um Codeduplizierung zu vermeiden (es werden ja nicht immer alle Sachen überarbeitet), können Teile vorheriger Implementierungen einfach mit in den neuen namespace gezogen werden und muss sich nur um die Teile kümmern, welche neu implementiert werden.

So. Das wäre es wieder einmal gewesen. Ich hoffe, dass ich euch neue Sachen zeigen konnte oder zumindest das Interesse an den neuen Features geweckt habe.
Im folgenden gibt es noch ein paar Links zu den Themen, welche mir als Quelle gedient haben und ich bei Interesse auch empfehlen kann.

Ausblick:
Das nächste mal wird entlich der Eintrag über Backups den Weg in meinemn Blog finden. Ich habe den grössten Teil des Eintrages im Sommer geschrieben, wo ich mein Backup System aufgebaut habe, ihn dann aber vorerst vergessen, damit ich jetzt auch wirklich mal meine Erfahrungen damit berichten kann, welche durchaus positiv sind. - Wer seine Backups einfach, schnell und und ohne gross Zuwendung haben möchte, darf gespannt sein.

Referenzen:
boost.org - boost::foreach
Bjarne Stroustrup - C++FAQ
open-std.org - n1986 - delegating constructors
open-std.org - n2628 - non-static data member initializiers
open-std.org - n2418 - attributes
open-std.org - n1448 - extern templates
open-std.org - n1344 - problems with library versioning
open-std.org - n3000 - actual working draft c++Keine Kommentare | Kommentieren

Ich wünsche nun auch noch allen ein gutes, neues Jahr. Und ich nehme gleich die Gelegenheit wahr um einen kleinen Ausblick zu wagen, wie es mit dem Blog im Jahre 2010 weiter geht.

Ich werde zum leiden der einen und zur Freude der anderen wahrscheinlich hauptsächlich über Informatik Sachen reden.

Natürlich gibt es auch noch andere, völlig artfremde Themen, die ich gelegentlich ansprechen werde. Und wenn ich Zeit habe, kommen natürlich auch witzige Sachen nicht zu kurz.

Falls jemand einen Wunsch, oder Idee hätte, über was ich sonst noch so schreiben könnte, einfach her damit.

In dem Sinne gutes 2010! 1 Kommentar | Kommentieren

Es gibt wiedermal etwas neues von der C++ Front. Diesmal möchte ich euch die neue Beta Version von Visual Studio 2010 vorstellen. Speziell möchte ich darauf auf die neuen Features in Bezug auf den neuen Standard von C++ vorstellen, der nicht wie vermutet noch dieses Jahr herauskommt (ausser das Standardisierungskomitee macht uns C++ Programmierer noch ein verspätetes Weihnachtsgeschenk. ) und daher liebevoll in hexadezimaler Version C++0x genannt wird. Ich persönlich rechne mit der Verabschiedung des Standards nächstes Jahr. Ich zweifle allerdings, dass die Compilerhersteller, wie Microsoft es noch das kommende Jahr schaffen werdene alle Features umzusetzen. Nichts desto trotz sind ja schon einige Sachen implementiert und genau diese möchte ich euch neben der IDE selbst vorstellen.
Das ganze ist in 3 Teile geteilt:

1. Oberfläche/Intellisense
   
2. C++0x: auto, decltype, rvalue, lambda
   
3. C++0x: static assert, template aliases, nullptr, Ausblick, Referenz

Oberfläche:
Die Oberfläche hat einen recht grossen Sprung zu seinem Vorgänger gemacht. Das liegt daran, dass die Oberflächte mit DirectX gezeichnet wird und daher auch speziellere, Hardwarebeschleunigte Effekte ermöglicht. Als erstes wird einem wohl der auffälige Blau Touch ins Auge fallen und die Fenster Technik, welche es ermöglicht jedes Fenster aus seinem Platz förmlich rauszureissen und beliebig zu platzieren oder anzudocken. Das alleine war ja auch schon mit Visual Studio 20058 möglich, allerdings ist es jetzt möglich die Fenster völlig unabhängig von der IDE selbst zu platzieren. Man kann also allfällige zusätzliche Monitore perfekt ausnutzen.

Ansonsten wirkt die ganze Oberfläche aufgeräumt, wie immer und sehr intuitiv benutzbar, wenn man bereits die Vorgänger Versionen benutzt hat. (Hier eine kleine Anmerkung für die Leute, die eine Library einbinden wollen: Die VC++ Directories befinden sich neu in den Projekteintellungen bei den Configuration Properties)

Ein Tool für Refactoring habe ich bis jetzt leider auch hier nicht entdecken können und bin was das anbelangt regelrecht enttäuscht. Warum bitteschön wird das nicht anständig implementiert, wo das doch kein Problem darstellen sollte. Der gesamte Code ist sowieso ständig in einer geparsten Version vorhanden (Intellisense) und daher wäre ein ersetzen von Bezeichnern Projektübergreifend doch kein Problem..

Ebenfalls sehr schön anzuschauen ist die Schrift, da sie nicht mehr wie bis anhin Pixelbasiert ist, sondern Vektorbasiert, was eine Stufenlose Skalierung ermöglicht. (Und das wird natürlich auch gleich gezeigt und kann links unten im Code Fenster eingestellt werden).

Intellisense:
Ja, man glaubt es kaum, aber sie haben es entlich geschafft, dass Intellisense auch für C++ anscheinend ohne Probleme funktioniert. Wer öfters mal mit C++ programmiet hat bestimmt auch schon gemerkt, dass die Vervollständigung nicht jedesmal funktioniert und man oft die .ncb von Hand löschen muss, damit überhaupt wieder etwas geht. Das scheint extrem viel Arbeit reingesteckt worden zu sein und jetzt haben wir sehr viele nette Features alleine für den Code Editor. Ein paar Sachen sind mir sofort aufgefallen.

• Die Syntax wird ständig auf Korrektheit kontrolliert und in Word Manier roter unterstrichen, wenn etwas falsch ist.
  
• Neue Klassen, templates usw. werden sofort in den Pool für Intellisense und die Codevervollständigung genommen und selbst die Member sind sofort vorhanden.
  
• Nicht nur Syntaxfehler werden erkannt auch semantische Fehler, wie nicht passende Typen werden erkannt (Beispiel unten).
  

Im folgenden Beispiel werden die semantischen Fehler erkannt, unterstrichen und verständlich als Fehler gemeldet:

struct foo
{
	void bar (){}
	int e;
};
 
void bar ( foo* f )
{
	i; // nicht vorhanden
	f->i; // nicht vorhanden 
	f.e; // falsch dereferenziert
	f->e; // entlich!
}

Für mich persönlich ist das eines der wirklich mächtigsten Features, dass VS neu bietet. Man stelle sich vor, was man da hat. Man hat eine komplette syntaktische und semantische Analyse des Codes ohne eine Sekunde compilen zu müssen. Selbst templates werden bis auf eine gewisse Stufe gecheckt, auch wenn ich da mal noch einen Härtetest machen muss.
Man hat also eigentlich keine Syntax Fehler mehr, welche man erst beim compilen bemerkt, sondern man kriegt die sofort gemeldet.

Nachteile, die ich sehe sind jetzt halt einfach die Performance der kompletten IDE, welche alleine schon zum starten einiges länger braucht, als die 2008er Version, welche doch sehr schnell startet für die Grösse des Programmes. Allerdings denke ich, dass mein Computer nicht mehr wirklich masgebend ist für die heutigen Umgebungen. (*hust* singlecore *hust* )

Ein Punkt, den ich in EiffelStudio wirklich gut fand und den ich in Visual Studio vermisse ist, dass man bei der Codevervollständigung keine Filter einstellen kann. Man hat einfach eine riesen Liste von Bezeichnern, wo von Klassen, Klassentemplates, Funktionen, globale usw. alles mit dabei ist. Da wäre es manchmal schon schön, wenn man einstellen kann, dass z.B nur Klassen angezeigt werden.

Ich bin mir sicher, dass die Beta noch so einiges mehr zu bieten hat, aber ich denke, dass der Code Editor wohl der für den Entwickler wichtigste Punkt von allen ist und der ist wirklich topp geworden. Bin sehr zufrieden. Ich werde also weiterhin ausschau auf interessante Features der IDE halten und ggf. einen weiteren Eintrag hier schreiben. (Mit der Gefahr, dass das bereits in 2008 möglich war und ich es einfach noch nicht gekannt habe..)Keine Kommentare | Kommentieren