typeid(“”) != typeid(const char*)What is the datatype of string literal in C++?How to convert a std::string to const char* or char*?Meaning of 'const' last in a function declaration of a class?What is the difference between const int*, const int * const, and int const *?Best lookup match between const char * and const char (& p)[T_Size]Wrapping cstrings (const char*) to be able to store them into a STL containerReplacing a 32-bit loop counter with 64-bit introduces crazy performance deviationsOverloading operator= or operator[] using const char* and/or stringWhy is 'pure polymorphism' preferable over using RTTI?Why do user-defined string literals and integer literals have different behavior?In C11, string literals as char[], unsigned char[], char* and unsigned char*

Is it true that "only photographers care about noise"?

Parallelized for loop in Bash

Nth term of Van Eck Sequence

Can Dive Down protect a creature against Pacifism?

Is fission/fusion to iron the most efficient way to convert mass to energy?

Print "N NE E SE S SW W NW"

Does every chapter have to "blow the reader away" so to speak?

What are the advantages of using TLRs to rangefinders?

Can an escape pod land on Earth from orbit and not be immediately detected?

I received a gift from my sister who just got back from

What do I need to do, tax-wise, for a sudden windfall?

How effective would a full set of plate armor be against wild animals found in temperate regions (bears, snakes, wolves)?

What is the theme of analysis?

Boss making me feel guilty for leaving the company at the end of my internship

Do Veracrypt encrypted volumes have any kind of brute force protection?

Why did the Death Eaters wait to reopen the Chamber of Secrets?

Any gotchas in buying second-hand sanitary ware?

Is pointing finger in meeting consider bad?

I sent an angry e-mail to my interviewers about a conflict at my home institution. Could this affect my application?

Should I worry about having my credit pulled multiple times while car shopping?

typeid("") != typeid(const char*)

Why not make one big cpu core?

What do you call the action of "describing events as they happen" like sports anchors do?

Would a bit of grease on overhead door cables or bearings cause the springs to break?



typeid(“”) != typeid(const char*)


What is the datatype of string literal in C++?How to convert a std::string to const char* or char*?Meaning of 'const' last in a function declaration of a class?What is the difference between const int*, const int * const, and int const *?Best lookup match between const char * and const char (& p)[T_Size]Wrapping cstrings (const char*) to be able to store them into a STL containerReplacing a 32-bit loop counter with 64-bit introduces crazy performance deviationsOverloading operator= or operator[] using const char* and/or stringWhy is 'pure polymorphism' preferable over using RTTI?Why do user-defined string literals and integer literals have different behavior?In C11, string literals as char[], unsigned char[], char* and unsigned char*






.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;








8















I'm making a C++ library which relies heavily on RTTI (customizable bridge to another language) and is very confused about string literal type.



This is a simple test I made to show the problem:



std::cout << typeid(const char*).name() << std::endl; // PKc
std::cout << std::any("").type().name() << std::endl; // PKc
std::cout << typeid("").name() << std::endl; // A1_c


For me it looks like the first two print the type for const char*, but the last one is an array.



Why do results for std::any("").type() and typeid("") differ? Is there a way to get the first behavior, i.e. make results for string literals consistent (I use type identification to call different type handlers)?



P.S.: tests are done using Clang version 8.0.0-3 (tags/RELEASE_800/final) on Ubuntu 19.04.










share|improve this question



















  • 8





    "" isn't a const char*, so they don't have matching types. A "" is a const char[], an array of const char.

    – Eljay
    8 hours ago












  • @Eljay Question isn't whether they are or shouldn't be different types. That's a premise of the question. The question is why std::any("").type() is not array (A1_c).

    – eerorika
    8 hours ago






  • 3





    To add to @Eljay's comment: the 2nd line (std::any) is a pointer because the char array decays to a pointer when it's passed to the constructor.

    – Timo
    8 hours ago






  • 1





    @Timo it's passed by reference, so it doesn't decay when passed.

    – Ayxan
    8 hours ago

















8















I'm making a C++ library which relies heavily on RTTI (customizable bridge to another language) and is very confused about string literal type.



This is a simple test I made to show the problem:



std::cout << typeid(const char*).name() << std::endl; // PKc
std::cout << std::any("").type().name() << std::endl; // PKc
std::cout << typeid("").name() << std::endl; // A1_c


For me it looks like the first two print the type for const char*, but the last one is an array.



Why do results for std::any("").type() and typeid("") differ? Is there a way to get the first behavior, i.e. make results for string literals consistent (I use type identification to call different type handlers)?



P.S.: tests are done using Clang version 8.0.0-3 (tags/RELEASE_800/final) on Ubuntu 19.04.










share|improve this question



















  • 8





    "" isn't a const char*, so they don't have matching types. A "" is a const char[], an array of const char.

    – Eljay
    8 hours ago












  • @Eljay Question isn't whether they are or shouldn't be different types. That's a premise of the question. The question is why std::any("").type() is not array (A1_c).

    – eerorika
    8 hours ago






  • 3





    To add to @Eljay's comment: the 2nd line (std::any) is a pointer because the char array decays to a pointer when it's passed to the constructor.

    – Timo
    8 hours ago






  • 1





    @Timo it's passed by reference, so it doesn't decay when passed.

    – Ayxan
    8 hours ago













8












8








8








I'm making a C++ library which relies heavily on RTTI (customizable bridge to another language) and is very confused about string literal type.



This is a simple test I made to show the problem:



std::cout << typeid(const char*).name() << std::endl; // PKc
std::cout << std::any("").type().name() << std::endl; // PKc
std::cout << typeid("").name() << std::endl; // A1_c


For me it looks like the first two print the type for const char*, but the last one is an array.



Why do results for std::any("").type() and typeid("") differ? Is there a way to get the first behavior, i.e. make results for string literals consistent (I use type identification to call different type handlers)?



P.S.: tests are done using Clang version 8.0.0-3 (tags/RELEASE_800/final) on Ubuntu 19.04.










share|improve this question
















I'm making a C++ library which relies heavily on RTTI (customizable bridge to another language) and is very confused about string literal type.



This is a simple test I made to show the problem:



std::cout << typeid(const char*).name() << std::endl; // PKc
std::cout << std::any("").type().name() << std::endl; // PKc
std::cout << typeid("").name() << std::endl; // A1_c


For me it looks like the first two print the type for const char*, but the last one is an array.



Why do results for std::any("").type() and typeid("") differ? Is there a way to get the first behavior, i.e. make results for string literals consistent (I use type identification to call different type handlers)?



P.S.: tests are done using Clang version 8.0.0-3 (tags/RELEASE_800/final) on Ubuntu 19.04.







c++ c++17 rtti string-literals






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 5 hours ago









Boann

38.1k1291123




38.1k1291123










asked 8 hours ago









valval

5151825




5151825







  • 8





    "" isn't a const char*, so they don't have matching types. A "" is a const char[], an array of const char.

    – Eljay
    8 hours ago












  • @Eljay Question isn't whether they are or shouldn't be different types. That's a premise of the question. The question is why std::any("").type() is not array (A1_c).

    – eerorika
    8 hours ago






  • 3





    To add to @Eljay's comment: the 2nd line (std::any) is a pointer because the char array decays to a pointer when it's passed to the constructor.

    – Timo
    8 hours ago






  • 1





    @Timo it's passed by reference, so it doesn't decay when passed.

    – Ayxan
    8 hours ago












  • 8





    "" isn't a const char*, so they don't have matching types. A "" is a const char[], an array of const char.

    – Eljay
    8 hours ago












  • @Eljay Question isn't whether they are or shouldn't be different types. That's a premise of the question. The question is why std::any("").type() is not array (A1_c).

    – eerorika
    8 hours ago






  • 3





    To add to @Eljay's comment: the 2nd line (std::any) is a pointer because the char array decays to a pointer when it's passed to the constructor.

    – Timo
    8 hours ago






  • 1





    @Timo it's passed by reference, so it doesn't decay when passed.

    – Ayxan
    8 hours ago







8




8





"" isn't a const char*, so they don't have matching types. A "" is a const char[], an array of const char.

– Eljay
8 hours ago






"" isn't a const char*, so they don't have matching types. A "" is a const char[], an array of const char.

– Eljay
8 hours ago














@Eljay Question isn't whether they are or shouldn't be different types. That's a premise of the question. The question is why std::any("").type() is not array (A1_c).

– eerorika
8 hours ago





@Eljay Question isn't whether they are or shouldn't be different types. That's a premise of the question. The question is why std::any("").type() is not array (A1_c).

– eerorika
8 hours ago




3




3





To add to @Eljay's comment: the 2nd line (std::any) is a pointer because the char array decays to a pointer when it's passed to the constructor.

– Timo
8 hours ago





To add to @Eljay's comment: the 2nd line (std::any) is a pointer because the char array decays to a pointer when it's passed to the constructor.

– Timo
8 hours ago




1




1





@Timo it's passed by reference, so it doesn't decay when passed.

– Ayxan
8 hours ago





@Timo it's passed by reference, so it doesn't decay when passed.

– Ayxan
8 hours ago












3 Answers
3






active

oldest

votes


















10














As others have mentioned, the type of the string literal "" is const char[1], as explained by, e.g., What is the datatype of string literal in C++?.



The type stored in std::any("") is const char* because you are using the following constructor (http://www.eel.is/c++draft/any.cons#8):



// Effects: Constructs an object of type any that contains an object of 
// type std::decay_t<T> direct-initialized with std::forward<T>(value).
template< class T>
any( T&& value );


In this case, T is const char(&)[1] (the type of the string literal ""), and thus std::decay_t<const char(&)[1]> will give you const char*, which is why the typeid() of std::any("").type() is the type ID of const char*.






share|improve this answer

























  • So what I want is to apply std::decay before typeid?

    – val
    8 hours ago











  • @val I don't really know what you want to do (not clear from your question), but if you create an object of type std::decay_t<T> from your object of type T, this should give you this behavior, similar to std::any behavior.

    – Holt
    8 hours ago


















3















Why do results for std::any("").type() and typeid("") differ?




Accroding to the following reference:




template< class ValueType >
any( ValueType&& value );


4) Constructs an object with initial content an object of type std::decay_t<ValueType>, direct-initialized from std::forward<ValueType>(value).




std::decay_t<const char[1]> is const char*.




Here is a quote from FrankHB1989 on the isocpp.org forum, which I think is relevant in understanding std::any, in context of this question:




[std::any] is even not for "any object". As I have argued before, I have expect the word "any" being short for "any first-class object type" (i.e. cv-unqualified non-array object type), but std::any has additional refinement of CopyConstructible on the value type, so it is actually for "any copyable cv-unqualified non-array object type" instead.




As such




Is there a way to get first behavior, i.e. make results for string literals consistent (I use type identification to call different type handlers)?




There is no way of having std::any of array (you can have std::any of std::array, but string literal is not a std::array), and there is no way of making typeid("") be a pointer. However, you can use std::decay_t<decltype("")> to get the same type as stored in std::any.






share|improve this answer
































    2














    It is a common misconception that a string literal has type const char*.



    It doesn't. It has type const char[<size + 1>] (plus one for the null terminator).



    e.g. "" has type const char[1].



    But we often assign a string literal to a const char*, out of convention (and also because otherwise we trigger special rules that result in copying the string).



    Furthermore, array name decay rules actually make it quite hard to observe the array-ness of a name in C (and, by extension, C++); that std::any works the way it does is an example of that.






    share|improve this answer























      Your Answer






      StackExchange.ifUsing("editor", function ()
      StackExchange.using("externalEditor", function ()
      StackExchange.using("snippets", function ()
      StackExchange.snippets.init();
      );
      );
      , "code-snippets");

      StackExchange.ready(function()
      var channelOptions =
      tags: "".split(" "),
      id: "1"
      ;
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function()
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled)
      StackExchange.using("snippets", function()
      createEditor();
      );

      else
      createEditor();

      );

      function createEditor()
      StackExchange.prepareEditor(
      heartbeatType: 'answer',
      autoActivateHeartbeat: false,
      convertImagesToLinks: true,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: 10,
      bindNavPrevention: true,
      postfix: "",
      imageUploader:
      brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
      contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
      allowUrls: true
      ,
      onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      );



      );













      draft saved

      draft discarded


















      StackExchange.ready(
      function ()
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f56564321%2ftypeid-typeidconst-char%23new-answer', 'question_page');

      );

      Post as a guest















      Required, but never shown

























      3 Answers
      3






      active

      oldest

      votes








      3 Answers
      3






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      10














      As others have mentioned, the type of the string literal "" is const char[1], as explained by, e.g., What is the datatype of string literal in C++?.



      The type stored in std::any("") is const char* because you are using the following constructor (http://www.eel.is/c++draft/any.cons#8):



      // Effects: Constructs an object of type any that contains an object of 
      // type std::decay_t<T> direct-initialized with std::forward<T>(value).
      template< class T>
      any( T&& value );


      In this case, T is const char(&)[1] (the type of the string literal ""), and thus std::decay_t<const char(&)[1]> will give you const char*, which is why the typeid() of std::any("").type() is the type ID of const char*.






      share|improve this answer

























      • So what I want is to apply std::decay before typeid?

        – val
        8 hours ago











      • @val I don't really know what you want to do (not clear from your question), but if you create an object of type std::decay_t<T> from your object of type T, this should give you this behavior, similar to std::any behavior.

        – Holt
        8 hours ago















      10














      As others have mentioned, the type of the string literal "" is const char[1], as explained by, e.g., What is the datatype of string literal in C++?.



      The type stored in std::any("") is const char* because you are using the following constructor (http://www.eel.is/c++draft/any.cons#8):



      // Effects: Constructs an object of type any that contains an object of 
      // type std::decay_t<T> direct-initialized with std::forward<T>(value).
      template< class T>
      any( T&& value );


      In this case, T is const char(&)[1] (the type of the string literal ""), and thus std::decay_t<const char(&)[1]> will give you const char*, which is why the typeid() of std::any("").type() is the type ID of const char*.






      share|improve this answer

























      • So what I want is to apply std::decay before typeid?

        – val
        8 hours ago











      • @val I don't really know what you want to do (not clear from your question), but if you create an object of type std::decay_t<T> from your object of type T, this should give you this behavior, similar to std::any behavior.

        – Holt
        8 hours ago













      10












      10








      10







      As others have mentioned, the type of the string literal "" is const char[1], as explained by, e.g., What is the datatype of string literal in C++?.



      The type stored in std::any("") is const char* because you are using the following constructor (http://www.eel.is/c++draft/any.cons#8):



      // Effects: Constructs an object of type any that contains an object of 
      // type std::decay_t<T> direct-initialized with std::forward<T>(value).
      template< class T>
      any( T&& value );


      In this case, T is const char(&)[1] (the type of the string literal ""), and thus std::decay_t<const char(&)[1]> will give you const char*, which is why the typeid() of std::any("").type() is the type ID of const char*.






      share|improve this answer















      As others have mentioned, the type of the string literal "" is const char[1], as explained by, e.g., What is the datatype of string literal in C++?.



      The type stored in std::any("") is const char* because you are using the following constructor (http://www.eel.is/c++draft/any.cons#8):



      // Effects: Constructs an object of type any that contains an object of 
      // type std::decay_t<T> direct-initialized with std::forward<T>(value).
      template< class T>
      any( T&& value );


      In this case, T is const char(&)[1] (the type of the string literal ""), and thus std::decay_t<const char(&)[1]> will give you const char*, which is why the typeid() of std::any("").type() is the type ID of const char*.







      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited 8 hours ago

























      answered 8 hours ago









      HoltHolt

      26.9k65598




      26.9k65598












      • So what I want is to apply std::decay before typeid?

        – val
        8 hours ago











      • @val I don't really know what you want to do (not clear from your question), but if you create an object of type std::decay_t<T> from your object of type T, this should give you this behavior, similar to std::any behavior.

        – Holt
        8 hours ago

















      • So what I want is to apply std::decay before typeid?

        – val
        8 hours ago











      • @val I don't really know what you want to do (not clear from your question), but if you create an object of type std::decay_t<T> from your object of type T, this should give you this behavior, similar to std::any behavior.

        – Holt
        8 hours ago
















      So what I want is to apply std::decay before typeid?

      – val
      8 hours ago





      So what I want is to apply std::decay before typeid?

      – val
      8 hours ago













      @val I don't really know what you want to do (not clear from your question), but if you create an object of type std::decay_t<T> from your object of type T, this should give you this behavior, similar to std::any behavior.

      – Holt
      8 hours ago





      @val I don't really know what you want to do (not clear from your question), but if you create an object of type std::decay_t<T> from your object of type T, this should give you this behavior, similar to std::any behavior.

      – Holt
      8 hours ago













      3















      Why do results for std::any("").type() and typeid("") differ?




      Accroding to the following reference:




      template< class ValueType >
      any( ValueType&& value );


      4) Constructs an object with initial content an object of type std::decay_t<ValueType>, direct-initialized from std::forward<ValueType>(value).




      std::decay_t<const char[1]> is const char*.




      Here is a quote from FrankHB1989 on the isocpp.org forum, which I think is relevant in understanding std::any, in context of this question:




      [std::any] is even not for "any object". As I have argued before, I have expect the word "any" being short for "any first-class object type" (i.e. cv-unqualified non-array object type), but std::any has additional refinement of CopyConstructible on the value type, so it is actually for "any copyable cv-unqualified non-array object type" instead.




      As such




      Is there a way to get first behavior, i.e. make results for string literals consistent (I use type identification to call different type handlers)?




      There is no way of having std::any of array (you can have std::any of std::array, but string literal is not a std::array), and there is no way of making typeid("") be a pointer. However, you can use std::decay_t<decltype("")> to get the same type as stored in std::any.






      share|improve this answer





























        3















        Why do results for std::any("").type() and typeid("") differ?




        Accroding to the following reference:




        template< class ValueType >
        any( ValueType&& value );


        4) Constructs an object with initial content an object of type std::decay_t<ValueType>, direct-initialized from std::forward<ValueType>(value).




        std::decay_t<const char[1]> is const char*.




        Here is a quote from FrankHB1989 on the isocpp.org forum, which I think is relevant in understanding std::any, in context of this question:




        [std::any] is even not for "any object". As I have argued before, I have expect the word "any" being short for "any first-class object type" (i.e. cv-unqualified non-array object type), but std::any has additional refinement of CopyConstructible on the value type, so it is actually for "any copyable cv-unqualified non-array object type" instead.




        As such




        Is there a way to get first behavior, i.e. make results for string literals consistent (I use type identification to call different type handlers)?




        There is no way of having std::any of array (you can have std::any of std::array, but string literal is not a std::array), and there is no way of making typeid("") be a pointer. However, you can use std::decay_t<decltype("")> to get the same type as stored in std::any.






        share|improve this answer



























          3












          3








          3








          Why do results for std::any("").type() and typeid("") differ?




          Accroding to the following reference:




          template< class ValueType >
          any( ValueType&& value );


          4) Constructs an object with initial content an object of type std::decay_t<ValueType>, direct-initialized from std::forward<ValueType>(value).




          std::decay_t<const char[1]> is const char*.




          Here is a quote from FrankHB1989 on the isocpp.org forum, which I think is relevant in understanding std::any, in context of this question:




          [std::any] is even not for "any object". As I have argued before, I have expect the word "any" being short for "any first-class object type" (i.e. cv-unqualified non-array object type), but std::any has additional refinement of CopyConstructible on the value type, so it is actually for "any copyable cv-unqualified non-array object type" instead.




          As such




          Is there a way to get first behavior, i.e. make results for string literals consistent (I use type identification to call different type handlers)?




          There is no way of having std::any of array (you can have std::any of std::array, but string literal is not a std::array), and there is no way of making typeid("") be a pointer. However, you can use std::decay_t<decltype("")> to get the same type as stored in std::any.






          share|improve this answer
















          Why do results for std::any("").type() and typeid("") differ?




          Accroding to the following reference:




          template< class ValueType >
          any( ValueType&& value );


          4) Constructs an object with initial content an object of type std::decay_t<ValueType>, direct-initialized from std::forward<ValueType>(value).




          std::decay_t<const char[1]> is const char*.




          Here is a quote from FrankHB1989 on the isocpp.org forum, which I think is relevant in understanding std::any, in context of this question:




          [std::any] is even not for "any object". As I have argued before, I have expect the word "any" being short for "any first-class object type" (i.e. cv-unqualified non-array object type), but std::any has additional refinement of CopyConstructible on the value type, so it is actually for "any copyable cv-unqualified non-array object type" instead.




          As such




          Is there a way to get first behavior, i.e. make results for string literals consistent (I use type identification to call different type handlers)?




          There is no way of having std::any of array (you can have std::any of std::array, but string literal is not a std::array), and there is no way of making typeid("") be a pointer. However, you can use std::decay_t<decltype("")> to get the same type as stored in std::any.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited 8 hours ago

























          answered 8 hours ago









          eerorikaeerorika

          94.8k671139




          94.8k671139





















              2














              It is a common misconception that a string literal has type const char*.



              It doesn't. It has type const char[<size + 1>] (plus one for the null terminator).



              e.g. "" has type const char[1].



              But we often assign a string literal to a const char*, out of convention (and also because otherwise we trigger special rules that result in copying the string).



              Furthermore, array name decay rules actually make it quite hard to observe the array-ness of a name in C (and, by extension, C++); that std::any works the way it does is an example of that.






              share|improve this answer



























                2














                It is a common misconception that a string literal has type const char*.



                It doesn't. It has type const char[<size + 1>] (plus one for the null terminator).



                e.g. "" has type const char[1].



                But we often assign a string literal to a const char*, out of convention (and also because otherwise we trigger special rules that result in copying the string).



                Furthermore, array name decay rules actually make it quite hard to observe the array-ness of a name in C (and, by extension, C++); that std::any works the way it does is an example of that.






                share|improve this answer

























                  2












                  2








                  2







                  It is a common misconception that a string literal has type const char*.



                  It doesn't. It has type const char[<size + 1>] (plus one for the null terminator).



                  e.g. "" has type const char[1].



                  But we often assign a string literal to a const char*, out of convention (and also because otherwise we trigger special rules that result in copying the string).



                  Furthermore, array name decay rules actually make it quite hard to observe the array-ness of a name in C (and, by extension, C++); that std::any works the way it does is an example of that.






                  share|improve this answer













                  It is a common misconception that a string literal has type const char*.



                  It doesn't. It has type const char[<size + 1>] (plus one for the null terminator).



                  e.g. "" has type const char[1].



                  But we often assign a string literal to a const char*, out of convention (and also because otherwise we trigger special rules that result in copying the string).



                  Furthermore, array name decay rules actually make it quite hard to observe the array-ness of a name in C (and, by extension, C++); that std::any works the way it does is an example of that.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered 8 hours ago









                  Lightness Races in OrbitLightness Races in Orbit

                  303k56491845




                  303k56491845



























                      draft saved

                      draft discarded
















































                      Thanks for contributing an answer to Stack Overflow!


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid


                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.

                      To learn more, see our tips on writing great answers.




                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function ()
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f56564321%2ftypeid-typeidconst-char%23new-answer', 'question_page');

                      );

                      Post as a guest















                      Required, but never shown





















































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown

































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown