{"id":2857,"date":"2018-04-19T19:00:55","date_gmt":"2018-04-19T17:00:55","guid":{"rendered":"http:\/\/mariusbancila.ro\/blog\/?p=2857"},"modified":"2018-04-20T09:50:25","modified_gmt":"2018-04-20T07:50:25","slug":"five-examples-for-avoiding-the-preprocessor","status":"publish","type":"post","link":"https:\/\/mariusbancila.ro\/blog\/2018\/04\/19\/five-examples-for-avoiding-the-preprocessor\/","title":{"rendered":"Five examples for avoiding the preprocessor"},"content":{"rendered":"

The C++ preprocessor is a text replacement tool used to transform the source code in order to produce a single text file that is then passed to the actual compiler. It has various capabilities, such as including files, conditional compilation, text macro replacement, error emitting, stringizing, or token concatenation. Often developers use the preprocessor when other alternatives are available and are more appropriate. In this article, I will show five examples of when and how you can avoid the use of the preprocessor.
\n<\/p>\n

Table of contents:<\/p>\n

    \n
  1. Object-like macros<\/a><\/li>\n
  2. Function-like macros<\/a><\/li>\n
  3. Exception handling macros<\/a><\/li>\n
  4. Conditional compilation<\/a><\/li>\n
  5. Policy-like macros<\/a><\/li>\n
  6. Bonus: including files<\/a><\/li>\n<\/ol>\n

    <\/a><\/p>\n

    Object-like macros<\/h3>\n

    These are identifiers that are replaced with a fragment of code and are often used to give symbolic names to numerical or string literals. Here is a typical example you must have seen many times.<\/p>\n

    #define BUFFER_SIZE 1024\r\n\r\nint main() \r\n{\r\n   char buffer[BUFFER_SIZE];\r\n}<\/pre>\n
    Instead of being a macro, BUFFER_SIZE<\/tt> could, and should, be defined as a compile-time constant.<\/p>\n
    constexpr size_t BUFFER_SIZE = 1024;<\/pre>\n
    Notice it is declared as constexpr<\/tt> and not just const<\/tt>. The latter indicates a value that does not change, but might only be available at runtime. The former, implies constness, but is guaranteed to be available at compile-time. constexpr<\/tt> values can be used in any place where compile-time constants are expected.<\/p>\n
    Many times object-like macros are used to define related symbolic names, such as in the following example:<\/p>\n
    #define PERMISSION_NONE    0\r\n#define PERMISSION_READ    1\r\n#define PERMISSION_WRITE   2\r\n#define PERMISSION_ADD     4\r\n#define PERMISSION_DELETE  8\r\n\r\nvoid show_permissions(int const p)\r\n{\r\n   if(p & PERMISSION_READ)\r\n      std::cout << \"can read\" << std::endl;\r\n   if (p & PERMISSION_WRITE)\r\n      std::cout << \"can write\" << std::endl;\r\n   if (p & PERMISSION_ADD)\r\n      std::cout << \"can add\" << std::endl;\r\n   if (p & PERMISSION_DELETE)\r\n      std::cout << \"can delete\" << std::endl;\r\n}\r\n\r\nint main() \r\n{\r\n   int flags = PERMISSION_READ | PERMISSION_WRITE;\r\n\r\n   show_permissions(flags);\r\n\r\n   flags |= PERMISSION_DELETE | PERMISSION_ADD;\r\n   flags &= ~PERMISSION_WRITE;\r\n\r\n   show_permissions(flags);\r\n}<\/pre>\n
    Following the previous example, we can simply replace these with constexpr<\/tt> values (in a class or namespace scope):<\/p>\n
    constexpr int PERMISSION_NONE   = 0;\r\nconstexpr int PERMISSION_READ   = 1;\r\nconstexpr int PERMISSION_WRITE  = 2;\r\nconstexpr int PERMISSION_ADD    = 4;\r\nconstexpr int PERMISSION_DELETE = 8;<\/pre>\n
    However, these macros, representing bitflags here, can also be replaced with an enumerator.<\/p>\n
    enum class permissions\r\n{\r\n   none = 0,\r\n   read = 1,\r\n   write = 2,\r\n   add = 4,\r\n   del = 8\r\n};\r\n\r\nvoid show_permissions(int const p)\r\n{\r\n   if(p & static_cast<int>(permissions::read))\r\n      std::cout << \"can read\" << std::endl;\r\n   if (p & static_cast<int>(permissions::write))\r\n      std::cout << \"can write\" << std::endl;\r\n   if (p & static_cast<int>(permissions::add))\r\n      std::cout << \"can add\" << std::endl;\r\n   if (p & static_cast<int>(permissions::del))\r\n      std::cout << \"can delete\" << std::endl;\r\n}\r\n\r\nint main() \r\n{\r\n   int flags = static_cast<int>(permissions::read) | \r\n               static_cast<int>(permissions::write);\r\n\r\n   show_permissions(flags);\r\n\r\n   flags |= static_cast<int>(permissions::del) | \r\n            static_cast<int>(permissions::add);\r\n   flags &= ~static_cast<int>(permissions::write);\r\n\r\n   show_permissions(flags);\r\n}<\/pre>\n
    This code is more verbose than the original one and you might be tempted to avoid writing all these explicit casts. You can actually make it as simple as the original and avoid macros, by overloading various operators for the enumerator type. The following snippet shows the completely rewritten example.<\/p>\n
    enum class permissions\r\n{\r\n   none = 0,\r\n   read = 1,\r\n   write = 2,\r\n   add = 4,\r\n   del = 8\r\n};\r\n\r\ninline int operator |(permissions const lhv, permissions const rhv)\r\n{\r\n   return static_cast<int>(lhv) | static_cast<int>(rhv);\r\n}\r\n\r\ninline int operator &(permissions const lhv, permissions const rhv)\r\n{\r\n   return static_cast<int>(lhv) & static_cast<int>(rhv);\r\n}\r\n\r\ninline int operator |(int const v, permissions const p)\r\n{\r\n   return v | static_cast<int>(p);\r\n}\r\n\r\ninline int operator |(permissions const p, int const v)\r\n{\r\n   return v | static_cast<int>(p);\r\n}\r\n\r\ninline int operator &(int const v, permissions const p)\r\n{\r\n   return v & static_cast<int>(p);\r\n}\r\n\r\ninline int operator &(permissions const p, int const v)\r\n{\r\n   return v & static_cast<int>(p);\r\n}\r\n\r\ninline int operator~(permissions const p)\r\n{\r\n   return ~static_cast<int>(p);\r\n}\r\n\r\ninline bool operator==(int const v, permissions const p)\r\n{\r\n   return v == static_cast<int>(p);\r\n}\r\n\r\ninline bool operator==(permissions const p, int const v)\r\n{\r\n   return v == p;\r\n}\r\n\r\nvoid show_permissions(int const p)\r\n{\r\n   if(p & permissions::read)\r\n      std::cout << \"can read\" << std::endl;\r\n   if (p & permissions::write)\r\n      std::cout << \"can write\" << std::endl;\r\n   if (p & permissions::add)\r\n      std::cout << \"can add\" << std::endl;\r\n   if (p & permissions::del)\r\n      std::cout << \"can delete\" << std::endl;\r\n}\r\n\r\nint main() \r\n{\r\n   int flags = permissions::read | permissions::write;\r\n\r\n   show_permissions(flags);\r\n\r\n   flags |= permissions::del | permissions::add;\r\n   flags &= ~permissions::write;\r\n\r\n   show_permissions(flags);\r\n}<\/pre>\n
    <\/a><\/p>\n
    Function-like macros<\/h3>\n
    These are macros that look like functions. The macro name is followed by none, one, or more arguments in paranthesis. Most of the times these can be replaced with regular functions or function templates. Let us get back to the previous example with the permission bigflag macros and introduce a couple function-like macros for setting and testing bit flag values.<\/p>\n
    #define PERMISSION_NONE    0\r\n#define PERMISSION_READ    1\r\n#define PERMISSION_WRITE   2\r\n#define PERMISSION_ADD     4\r\n#define PERMISSION_DELETE  8\r\n\r\n#define SETBIT(fFlag, lValue, lBits) (fFlag ? (lValue) | (lBits) : (lValue) & (~lBits))\r\n#define TESTBIT(lValue, lBits)       (((lValue) & (lBits)) == (lBits))\r\n\r\nvoid show_permissions(int const p)\r\n{\r\n   if (TESTBIT(p, PERMISSION_READ))\r\n      std::cout << \"can read\" << std::endl;\r\n   if (TESTBIT(p, PERMISSION_WRITE))\r\n      std::cout << \"can write\" << std::endl;\r\n   if (TESTBIT(p, PERMISSION_ADD))\r\n      std::cout << \"can add\" << std::endl;\r\n   if (TESTBIT(p, PERMISSION_DELETE))\r\n      std::cout << \"can delete\" << std::endl;\r\n}\r\n\r\nint main()\r\n{\r\n   int flags = PERMISSION_READ | PERMISSION_WRITE;\r\n\r\n   show_permissions(flags);\r\n\r\n   flags = SETBIT(true, flags, PERMISSION_DELETE);\r\n   flags = SETBIT(true, flags, PERMISSION_ADD);\r\n   flags = SETBIT(false, flags, PERMISSION_WRITE);\r\n\r\n   show_permissions(flags);\r\n}<\/pre>\n
    The SETBIT<\/tt> and TESTBIT<\/tt> macros can be replaced with inline functions (SETBIT<\/tt> being replaced by two functions, one that sets a bit and one that resets a bit). For the following example, I assume the permissions<\/tt> scoped enum and the overloaded operators are defined as above.<\/p>\n
    inline int set_bit(int const v, permissions const p)\r\n{\r\n   return v | p;\r\n}\r\n\r\ninline int reset_bit(int const v, permissions const p)\r\n{\r\n   return v & ~p;\r\n}\r\n\r\ninline bool test_bit(int const v, permissions const p)\r\n{\r\n   return (v & p) == p;\r\n}\r\n\r\nvoid show_permissions(int const p)\r\n{\r\n   if(test_bit(p, permissions::read))\r\n      std::cout << \"can read\" << std::endl;\r\n   if (test_bit(p, permissions::write))\r\n      std::cout << \"can write\" << std::endl;\r\n   if (test_bit(p, permissions::add))\r\n      std::cout << \"can add\" << std::endl;\r\n   if (test_bit(p, permissions::del))\r\n      std::cout << \"can delete\" << std::endl;\r\n}\r\n\r\nint main() \r\n{\r\n   int flags = permissions::read | permissions::write;\r\n\r\n   show_permissions(flags);\r\n\r\n   flags= set_bit(flags, permissions::del);\r\n   flags = set_bit(flags, permissions::add);\r\n   flags = reset_bit(flags, permissions::write);\r\n\r\n   show_permissions(flags);\r\n}<\/pre>\n
    <\/a><\/p>\n
    Exception handling macros<\/h3>\n
    Confronted with repeated situations when they have to catch the same exeptions and handle them the same way, some developers resort to macros for avoiding repetitive code. The following is such an example.<\/p>\n
    #define TRACE_ERR(x) std::cerr << x << std::endl\r\n\r\n#define TRY_CALL     try\r\n#define CATCH_CALL   catch(std::runtime_error const & e) \\\r\n                     {\\\r\n                        TRACE_ERR(std::string(\"runtime error: \") + e.what());\\\r\n                     }\\\r\n                     catch (std::logic_error const & e) \\\r\n                     {\\\r\n                        TRACE_ERR(std::string(\"logic error: \") + e.what());\\\r\n                     }\\\r\n                     catch (std::exception const & e) \\\r\n                     {\\\r\n                        TRACE_ERR(std::string(\"exception: \") + e.what());\\\r\n                     }\\\r\n                     catch (...)\\\r\n                     {\\\r\n                        TRACE_ERR(\"unexpected error\");\\\r\n                     }\r\n\r\nvoid func_that_throws()\r\n{\r\n   throw std::runtime_error(\"an error has occurred!\");\r\n}\r\n\r\nint main()\r\n{\r\n   TRY_CALL\r\n   {\r\n      func_that_throws();\r\n   }\r\n   CATCH_CALL\r\n}<\/pre>\n
    If you execute this program it will print runtime error: an error has occurred!<\/tt>. However, these macros are not debugable, and in practice may even be hard to write. This example can be rewritten to use a regular function as handler for multiple exceptions. The only difference in the main()<\/tt> function is an additional call for this function, error_handler()<\/tt>.<\/p>\n
    inline void trace_error(std::string_view text)\r\n{\r\n   std::cerr << text << std::endl;\r\n}\r\n\r\nvoid error_handler()\r\n{\r\n   using std::string_literals;\r\n\r\n   try\r\n   {\r\n      throw;\r\n   }\r\n   catch (std::runtime_error const & e)\r\n   {\r\n      trace_error(\"runtime error: \"s + e.what());\r\n   }\r\n   catch (std::logic_error const & e)\r\n   {\r\n      trace_error(\"logic error: \"s + e.what());\r\n   }\r\n   catch (std::exception const & e)\r\n   {\r\n      trace_error(\"exception: \"s + e.what());\r\n   }\r\n   catch (...)\r\n   {\r\n      trace_error(\"unexpected error\");\r\n   }\r\n}\r\n   \r\n\r\nvoid func_that_throws()\r\n{\r\n   throw std::runtime_error(\"an error has occurred!\");\r\n}\r\n\r\nint main()\r\n{\r\n   try\r\n   {\r\n      func_that_throws();\r\n   }\r\n   catch(...)\r\n   {\r\n      error_handler();\r\n   }\r\n}<\/pre>\n
    The throw;<\/tt> statement without an expression rethrows the currently handled exception. (It is allowed only when an exception is being handled, otherwise std::terminate()<\/tt> will be called). It can be used to create handlers that can catch and handle multiple exception types without the need to duplicate code or resort to macros.<\/p>\n
    <\/a><\/p>\n
    Conditional compilation<\/h3>\n
    This is a feature of the preprocessor that selects whether to include or not a chunk of code in the final text file that will be passed to the compiler. Preprocessor conditional directives can check arithmetic expressions or whether a name is defined as a macro.<\/p>\n
    In the following example, a message is written to the standard output stream when the program is compiled using a debug configuration and the _DEBUG<\/tt> macro is defined.<\/p>\n
    #define TRACE(x) std::cout << x << std::endl\r\n\r\nint main()\r\n{\r\n#ifdef _DEBUG\r\n   TRACE(\"debug build\");\r\n#endif\r\n}<\/pre>\n
    In C++17 this can be replaced with constexpr if<\/tt> as shown in the following example:<\/p>\n
    #include <string_view>\r\n\r\ninline void trace(std::string_view text)\r\n{\r\n   std::cout << text << std::endl;\r\n}\r\n\r\nint main()\r\n{\r\n   if constexpr(_DEBUG)\r\n      trace(\"debug build\");\r\n}<\/pre>\n
    <\/a><\/p>\n
    Policy-like macros<\/h3>\n
    OK, that’s not a term you see in the literature, but I couldn’t find something better, and that looks the closest to what we have here. Let’s look at the following example and exaplain what we’re doing.<\/p>\n
    The goal is to trace the execution of functions. We want a message to be displayed to the console when the function starts and another one when the function stops. The first message should show the function name and the current time, and the end message must show the function name, the current time and duration of the function execution. The class Tracer<\/tt> defines a conversion constructor, that prints a message to the console, and records a start time point, and a custom destructor, that computes the time since the constructor was called and prints another message to the console. Defining objects of this type at the beginning of a function will have the result that a message is printed after the function execution started and another one just before it ends. However, we only want to do that in some cases, when a particular macro name (called MONITORING<\/tt> in this example) is defined. This can be defined either in code, or passed as an argument to the compiler (like -DMONITORING<\/tt>). This goal can be achieved using macros, as in the following example:<\/p>\n
    #include <iostream>\r\n#include <string>\r\n#include <string_view>\r\n#include <chrono>\r\n#include \"date.h\"\r\n#include <ctime>\r\n#include <thread>\r\n\r\n#define MONITOR()  Tracer tracer__LINE__(__FUNCTION__)\r\n\r\nclass Tracer\r\n{   \r\npublic:\r\n   Tracer(std::string_view function):\r\n      function_name(function),\r\n      start_time(std::chrono::system_clock::now())\r\n   {\r\n      using namespace date;\r\n      using namespace std::chrono;\r\n\r\n      std::cout << \"BEGIN [\" << function_name << \"] at \" << start_time << std::endl;\r\n   }\r\n\r\n   ~Tracer()\r\n   {\r\n      using namespace date;\r\n      using namespace std::chrono;\r\n\r\n      auto end_time = std::chrono::system_clock::now();\r\n      auto diff = duration_cast<milliseconds>(end_time - start_time).count();\r\n\r\n      std::cout << \"END   [\" << function_name << \"] at \" << end_time \r\n                << \" (duration \" << diff << \"ms)\" << std::endl;\r\n   }\r\n\r\nprivate:\r\n   std::string                            function_name;\r\n   std::chrono::system_clock::time_point  start_time;\r\n};\r\n\r\n#ifdef MONITORING\r\n#define MONITOR_FUNCTION()    MONITOR()\r\n#else\r\n#define MONITOR_FUNCTION()\r\n#endif\r\n\r\nvoid foo()\r\n{\r\n   MONITOR_FUNCTION();\r\n\r\n   std::cout << \"executing...\" << std::endl;\r\n\r\n   using namespace std::chrono_literals;\r\n   std::this_thread::sleep_for(1s);\r\n}\r\n\r\nint main()\r\n{\r\n   foo();\r\n}<\/pre>\n
    If you run this program having MONITORING<\/tt> defined, the output looks like the following:<\/p>\n
    BEGIN [foo] at 2018-04-18 19:12:07.7385896\r\nexecuting...\r\nEND   [foo] at 2018-04-18 19:12:08.7475495 (duration 1008ms)<\/pre>\n
    Should MONITORING<\/tt> not be defined, the output is simply<\/p>\n
    executing...\r\n<\/pre>\n
    Using constexpr if<\/tt> is not possible in this situation, because that would introduce an inner scope. In other words, the following example:<\/p>\n
    void foo()\r\n{\r\n   if constexpr(MONITORING)\r\n      Tracer tracer(__FUNCTION__);\r\n\r\n   std::cout << \"executing...\" << std::endl;\r\n\r\n   using namespace std::chrono_literals;\r\n   std::this_thread::sleep_for(1s);\r\n}<\/pre>\n
    would result in the following code being generated<\/p>\n
    void foo()\r\n{\r\n   {\r\n      Tracer tracer(__FUNCTION__);\r\n   }\r\n\r\n   std::cout << \"executing...\" << std::endl;\r\n\r\n   using namespace std::chrono_literals;\r\n   std::this_thread::sleep_for(1s);\r\n}<\/pre>\n
    As a result, the Tracer<\/tt> object would be created and immediatelly destroyed at the beginning of the function.<\/p>\n
    A solution for this problem is to use policy-based design<\/a>. We can define policies, i.e. classes, that perform or do not perform any tracing. The foo()<\/tt> function would become a function template, parameterized with the monitoring policy. Then, we can use std::conditional<\/tt> to select between policies at compile time based on a condition. That condition would be the availability of the MONITORING<\/tt> macro name. This can be passed as a compiler argument, or else it will be defined as 0 in the code. Here is how the example could look in this case:<\/p>\n
    #ifndef MONITORING\r\n#define MONITORING 0\r\n#endif\r\n\r\nclass Tracer\r\n{   \r\npublic:\r\n   Tracer(std::string_view function):\r\n      function_name(function),\r\n      start_time(std::chrono::system_clock::now())\r\n   {\r\n      using namespace date;\r\n      using namespace std::chrono;\r\n\r\n      std::cout << \"BEGIN [\" << function_name << \"] at \" << start_time << std::endl;\r\n   }\r\n\r\n   ~Tracer()\r\n   {\r\n      using namespace date;\r\n      using namespace std::chrono;\r\n\r\n      auto end_time = std::chrono::system_clock::now();\r\n      auto diff = duration_cast<milliseconds>(end_time - start_time).count();\r\n\r\n      std::cout << \"END   [\" << function_name << \"] at \" << end_time \r\n                << \" (duration \" << diff << \"ms)\" << std::endl;\r\n   }\r\n\r\nprivate:\r\n   std::string                            function_name;\r\n   std::chrono::system_clock::time_point  start_time;\r\n};\r\n\r\nstruct standard_monitor\r\n{\r\n   standard_monitor(std::string_view function):t(function)\r\n   {}\r\nprivate:\r\n   Tracer t;\r\n};\r\n\r\nstruct no_monitor\r\n{\r\n   no_monitor(std::string_view function) {}\r\n};\r\n\r\ntemplate <typename MonitorType>\r\nvoid foo()\r\n{\r\n   MonitorType mt(__FUNCTION__);\r\n\r\n   std::cout << \"executing...\" << std::endl;\r\n\r\n   using namespace std::chrono_literals;\r\n   std::this_thread::sleep_for(1s);\r\n}\r\n\r\nusing monitor_type = std::conditional<MONITORING, standard_monitor, no_monitor>::type;\r\n\r\nint main()\r\n{\r\n   foo<monitor_type>();\r\n}<\/pre>\n
    We are still left with two macros: MONITORING<\/tt> to select one policy or another, and __FUNCTION__<\/tt> to get the undecorated name of the enclosing function. There is no way to replace the former for the time being, but for the latter, there is something under review in library fundamentals Technical Specification v2, called std::experimental::source_location<\/a>. This will provide information about the source code, such as the line number and enclosing function name. Using this special built-in class, we would be able to get rid of the __FUNCTION__<\/tt> special macro as following:<\/p>\n
    struct standard_monitor\r\n{\r\n   standard_monitor(std::experimental::source_location loc = std::experimental::source_location::current())\r\n      :t(loc.function_name())\r\n   {}\r\nprivate:\r\n   Tracer t;\r\n};\r\n\r\nstruct no_monitor\r\n{\r\n   no_monitor() {}\r\n};\r\n\r\ntemplate <typename MonitorType>\r\nvoid foo()\r\n{\r\n   MonitorType mt;\r\n\r\n   std::cout << \"executing...\" << std::endl;\r\n\r\n   using namespace std::chrono_literals;\r\n   std::this_thread::sleep_for(1s);\r\n}\r\n\r\nusing monitor_type = std::conditional<MONITORING, standard_monitor, no_monitor>::type;\r\n\r\nint main()\r\n{\r\n   foo<monitor_type>();\r\n}<\/pre>\n
    <\/a><\/p>\n
    Bonus: including files<\/h3>\n
    Including files is definitely the most common preprocessor functionality. Is there an alternative to it? Not yet, but one is in work. It’s called modules and a technical specification is in work. It is likely that a first version will be available in C++20. Basically, the #include<\/tt> directive for headers, will be replaced with import<\/tt> directives for modules. Here is a very simple example:<\/p>\n
    #include <iostream>\r\n\r\nint main()\r\n{\r\n   std::cout << \"hello, world!\" << std::endl;\r\n}<\/pre>\n
    With modules available, this can be changed as follows:<\/p>\n
    import std.core;\r\n\r\nint main()\r\n{\r\n   std::cout << \"hello, world!\" << std::endl;\r\n}\r\n<\/pre>\n","protected":false},"excerpt":{"rendered":"
    The C++ preprocessor is a text replacement tool used to transform the source code in order to produce a single text file that is then passed to the actual compiler. It has various capabilities, such as including files, conditional compilation, text macro replacement, error emitting, stringizing, or token concatenation. Often developers use the preprocessor when other alternatives are available and are more appropriate. In this article, I will show five examples of when and how you can avoid the use of the preprocessor.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_uag_custom_page_level_css":"","advgb_blocks_editor_width":"","advgb_blocks_columns_visual_guide":"","_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"jetpack_post_was_ever_published":false},"categories":[7],"tags":[451,554,553,323],"class_list":["post-2857","post","type-post","status-publish","format-standard","hentry","category-c","tag-c","tag-macros","tag-preprocessor","tag-templates"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t