Xathrya Sabertooth |
| Know the Concept: Desktop Environment and Window Manager Posted: 14 Jan 2014 02:37 AM PST In modern operating system, user interfaces tends goes to graphical system. We see window, we see button, we see cursor, etc. In UNIX, the graphical component is managed by independent subsystem. Here we hear two concepts: Desktop Environment and Window Manager. However, still some people confuse about which is which and which is best to use. The former question is fairly simple to answer. However the latter question is a bit more complex due to specific user want. The Layering SystemUNIX use layering system for its graphical desktop. Mostly the system comprised of following (from the base to the top):
So, a Desktop Environment generally includes a suite of application that are tightly integrated so that all applications are aware of one another. It is basically rides on top of a Window Manager and adds many features, including panels, status bars, drag-and-drop capabilities, and a suite of integrated applications and tools. Most user opinions on operating systems are typically based on Desktop Environment. As implied by the name, Window Manager manages windows. Window Manager allows the windows to be opened, closed, resized, and moved. t is also capable of presenting menus and options to the user. It controls the look and feel of the user’s GUI. The Type of Window ManagersWindow managers are often divided into three or more classes, which describe how windows are drawn and updated. Compositing Window ManagersCompositing window managers let all windows be created and drawn separately and then put together and displayed in various 2D and 3D environments. The most advanced compositing window managers allow for a great deal of variety in interface look and feel, and for the presence of advanced 2D and 3D visual effects.Example: Stacking Window ManagersAll window managers that have overlapping windows and are not compositing window managers are stacking window managers, although it is possible that not all use the same methods. Stacking window managers allow windows to overlap by drawing background windows first, which is referred to as painter’s algorithm. Changes sometimes require that all windows be re-stacked or repainted, which usually involves redrawing every window. However, to bring a background window to the front usually only requires that one window be redrawn, since background windows may have bits of other windows painted over them, effectively erasing the areas that are covered. Examples: Tiling Window ManagerTiling window managers paint all windows on-screen by placing them side by side or above and below each other, so that no window ever covers another. Examples: Dynamic Window ManagerDynamic window managers can dynamically switch between tiling or floating window layout. It is a tiling window manager where windows are tiled based on preset layouts between which the user can switch. Layouts typically have a master area and a slave area. The master area usually shows one window, but one can also change the amount of windows in this area. The point of it is to reserve more space for the more important window(s). The slave area shows the other windows. Examples: So Which One Suit Me?Again, it is a tough question. Your choice might be affected by many factors: your need, your taste, your mood, etc. Unless you want to explore deep, you might consider default Desktop Environment and default Window Manager provided. |
| Separating CPP Template Declaration and Implementation Posted: 14 Jan 2014 12:59 AM PST Templates are a feature of the C++ programming language that allow function and classes to operate with generic types. This allows a function or class to work on many different data types without being rewritten for each one. The C++ Standard Library specify a special section for heavy use of template, called Standard Template Library. Defining a template is like defining a blueprint. When we need a specific instance of function or class, the instance can be made from the generic blueprint. However, the common procedure in C++ which put the definition in a C++ header file and the implementation in a C++ source file can’t be applied to template. This is the behavior which is true for all compiler. In this article we will discuss about how to separate declaration and implementation of template object (class / function). The article will be divided into three sections: how template is parsed, compilation issue, and the solution methods. How Template is ParsedUnlike other code, templates are parsed not only once, but twice. This process is explicitly defined in the C++ standard and although some compilers do ignore this, they are, in effect, non-compliant and may behave differently to what this article describes. So what are those two processes? They are, let’s say, Point of Declaration (PoD) and Point of Instantiation (PoI). 1. Point of Declaration (PoD)During the first parse, or Point of Declaration, the compiler checks the syntax of the template and match it with C++ grammar. This way, compiler does not consider the dependent types (the template parameters that form the templates types within the templates). In real world, we can consider this phase as checking the grammar of a paragraph without checking the meaning of the words (the semantics). Grammatically the paragraph can be correct but the the arrangement of words may have no useful meaning. During the grammar checking phase, we don’t are about the meaning of the words. Our intention only toward the correct syntax. Now, consider following template code: template <typename T> void foo (T const & t) { t.bar(); } This is syntactically correct. However, at this point we have no idea what type the dependent type T is so we just assume that in all cases of T it is correct to call member bar() on it. Of course, if type T doesn’t have this member then we have a problem but until we know what type T is we don’t know if there is a problem so this code is ok for now. 2. Point of Instantiation (PoI)At PoD we have declare a template, which we have the blueprint. The instantiation process start at Point of Instantiation. At this point we actually define a concrete type of our template. So consider these 2 concrete instantiations of the template defined above… foo(1); // this will fail the 2nd pass because an int (1 is an int) does not have a member function called bar() foo(b); // Assuming b has a member function called bar this instantiation is fine It is perfectly legal to define a template that won’t be corrected under all circumstances of instantiation. Since code for a template is not generated unless it is instantiated the compiler won’t complain unless we try to instantiate it. At this point, the semantics are now checked against the known dependent type to make sure that the generated code will be correct. To do this, the compiler must be able to see the full definition of template. If the definition of the template is defined in a different place where it is being instantiated the compiler has no way to perform this check. Thus, the template won’t be instantiated and an error message will be delivered. Remember that compiler can only see and process one translation unit (module / source code) at a time. Now, if the template is only used in one translation unit and the template is defined in same translation unit, no problem rises. Now let’s recap what we got so far. If the template definition is in translation unit A and we try to instantiate it in translation unit B the compiler won’t be able to instantiate the template because it can’t see the full definition so it will result in linker errors (undefined symbols). If everything is in one place then it will work. but it is not a good way to write templates. Template Compilation-IssueFrom the first section we know that between template definition should be visible and on the same translation unit with the instantiation. Thus, the following code works: /** BigFile.cpp **/ #ifndef _FOO_HPP_ #define _FOO_HPP_ template<typename T> class Foo { public: Foo() { } void setValue (T obj_i) { } T getValue () { return m_Obj; } private: T m_Obj; }
Langganan:
Posting Komentar (Atom)
|
Tidak ada komentar:
Posting Komentar