<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>creation on autosys</title>
    <link>https://autosys.informatik.haw-hamburg.de/categories/creation/</link>
    <description>Recent content in creation on autosys</description>
    <generator>Source Themes Academic (https://sourcethemes.com/academic/)</generator>
    <language>en-us</language>
    <copyright>&amp;copy; {year}</copyright>
    <lastBuildDate>Mon, 13 Feb 2017 00:00:00 +0000</lastBuildDate>
    
	    <atom:link href="https://autosys.informatik.haw-hamburg.de/categories/creation/index.xml" rel="self" type="application/rss+xml" />
    
    
    <item>
      <title>Clone Factory</title>
      <link>https://autosys.informatik.haw-hamburg.de/codesamples/clone-factory/</link>
      <pubDate>Mon, 13 Feb 2017 00:00:00 +0000</pubDate>
      
      <guid>https://autosys.informatik.haw-hamburg.de/codesamples/clone-factory/</guid>
      <description>&lt;p&gt;A factory creates objects of a certain type. The factory takes an ID of some sort as an argument and creates the object which has been registered with the factory with the respective ID.&lt;/p&gt;
&lt;p&gt;This code sample shows one way to make  a factory. All objects are stored in an interal (intrusive) list inside the factory together with their ID. To create an object given its ID, the factory searches the list for the ID and calls the copy constructor of the object to create a new object of the same type.&lt;/p&gt;
&lt;p&gt;In the moment the new object comes into live, a so called virtual constructor call is made. The virtual constructor principle simply states, that there shall be a function like create() or construct() or init() which shall be called polymorphically. Real constructors may not be virtual, you see. This is because the object hasn´t been created yet and therefore no v-table exists.&lt;/p&gt;
&lt;p&gt;The virtual constructor call may be used e.g. for a deserialization call, in case your factory creates message objects. In this case the virtual constructor reads a byte stream and fill the freshly created object with data.&lt;/p&gt;
&lt;br /&gt;
&lt;script type=&#34;application/javascript&#34; src=&#34;https://gist.github.com/stephanpareigis/3cec02d5a09a20ddd9891fa87a896894.js&#34;&gt;&lt;/script&gt;

</description>
    </item>
    
    <item>
      <title>Singleton</title>
      <link>https://autosys.informatik.haw-hamburg.de/codesamples/singleton/</link>
      <pubDate>Mon, 13 Feb 2017 00:00:00 +0000</pubDate>
      
      <guid>https://autosys.informatik.haw-hamburg.de/codesamples/singleton/</guid>
      <description>&lt;p&gt;A singleton is a class which controls the number of objects to be created from this class. Most often there shall be just a single object from a certain type. The basic principle to reach this is to limit the access to the constructor, i.e. making it private. There is a static function which allowes a single point of access to the single object.&lt;/p&gt;
&lt;script type=&#34;application/javascript&#34; src=&#34;https://gist.github.com/stephanpareigis/4e06c6f84e73fb4fada2b4e7f77527da.js&#34;&gt;&lt;/script&gt;

&lt;h1 id=&#34;controversial-discussion&#34;&gt;Controversial discussion&lt;/h1&gt;
&lt;p&gt;There is a controversial discussion if a singleton is good design. The main critique is that it is reachable from any scope, thus appearing as a global variable. It is also not trivial to make it thread-safe (pre C++11). Destruction of a singleton is another issue. Also, lazy initialization might not be what you want in a time-critical system. I personally suggest in reactive time-critical systems to allocate your resources at start-up time if possible. This will guarantee by design that there is only a certain number of objects of a certain type. Also the initialization order may be established easliy. The objects shall communicate via appropriate communication channels.&lt;/p&gt;
&lt;h1 id=&#34;issues&#34;&gt;Issues&lt;/h1&gt;
&lt;p&gt;There are a couple of issues to think about when deciding to use a singleton and choosing the right implementation.&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;
&lt;p&gt;&lt;strong&gt;threadsafety&lt;/strong&gt; of a singleton. There is the DCLP (double checked locking pattern) [1] to make the original GOF singleton [2] thread-safe. As recovered several years later, this may fail under certain circumstances [3]. In C++11 there is a thread-safe implementation due to a new memory model. The Meyers Singleton [5] is also thread-safe in C++11.&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;&lt;strong&gt;destruction&lt;/strong&gt;. The original GOF singleton cannot be destructed. At the end of the program it doesn´t free its resources. The Meyers Singletons destructor is called at the programs end. If you need to destroy a singleton during runtime and re-create it later, the phoenix singleton [6] comes in handy.&lt;/p&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;h1 id=&#34;references&#34;&gt;References&lt;/h1&gt;
&lt;p&gt;[1] D.C. Schmidt, T.Harrison; Double-Checked Locking; Pattern Languages of Program Design 3, 1997&lt;br /&gt;
[2] E.Gamma, R.Johnson, R.Helm, J.Vlissides; Design Pattern; Prentice Hall 1994&lt;br /&gt;
[3] S.Meyers, A.Alexandrescu; C++ and the Perils of Double-Checked Locking; 2004&lt;br /&gt;
[4] H.Sutter; herbsutter.com&lt;br /&gt;
[5] S.Meyers; More Effective C++; 1996&lt;br /&gt;
[6] A.Alexandrescu; Modern C++ Design, Addison-Wesley, 2001&lt;br /&gt;&lt;/p&gt;
</description>
    </item>
    
  </channel>
</rss>
