Overloading string literal

Discussion in 'C++' started by qak, May 12, 2013.

  1. qak

    qak Guest

    Suppose: int Buffer::put(const char *s);
    Where: Put() has to find the length of 's' by strlen().
    I would like to have: Put("Header Tag...") where sizeof("Header Tag...") -
    1 is known at compile-time.
    Macro is acceptable, but must report error if 's' is not string literal:
    sizeof(s) yield size of const char*, which is not length of string.
     
    qak, May 12, 2013
    #1
    1. Advertising

  2. On 12.05.13 16.50, qak wrote:
    > Suppose: int Buffer::put(const char *s);
    > Where: Put() has to find the length of 's' by strlen().
    > I would like to have: Put("Header Tag...") where sizeof("Header Tag...") -
    > 1 is known at compile-time.


    #include <stdio.h>

    template <size_t len>
    void put(const char (&str)[len])
    { printf("%u, ", len);
    fwrite(str, len, 1, stdout);
    putchar('\n');
    }

    int main()
    { put("Test1");
    put("test2\0test");
    return 0;
    }


    Marcel
     
    Marcel Müller, May 12, 2013
    #2
    1. Advertising

  3. qak

    qak Guest

    Marcel Müller <> wrote in news:518faeec$0
    $6574$-online.net:

    > #include <stdio.h>
    >
    > template <size_t len>
    > void put(const char (&str)[len])
    > { printf("%u, ", len);
    > fwrite(str, len, 1, stdout);
    > putchar('\n');
    > }
    >
    > int main()
    > { put("Test1");
    > put("test2\0test");
    > return 0;
    > }
    >


    Many thanks, works perfectly for me

    #include <stdio.h>

    template <size_t len>
    void put(const char (&str)[len])
    {
    printf("%u, ", len);
    fwrite(str, len, 1, stdout);
    putchar('\n');
    }

    int main()
    {
    const char Test[] = "TEST";
    const char *Test2 = "TEST2";
    put(Test);
    put(Test2); // error C2784: 'void put(const char (&)[len])' :
    could not deduce template argument for 'const char (&)[len]' from 'const
    char *'
    put("test2\0test");
    return 0;
    }
     
    qak, May 13, 2013
    #3
  4. On 13.05.2013 17:52, Paavo Helde wrote:
    > qak <> wrote in news:XnsA1BF6A0FDEAA1qkieumtsnet@
    > 94.75.214.39:
    >>
    >> #include <stdio.h>
    >>
    >> template <size_t len>
    >> void put(const char (&str)[len])
    >> {
    >> printf("%u, ", len);

    >
    > %u is wrong here, the type of len is size_t.


    Well, my old compiler does not know about the size type place holder.

    > What's wrong with std::cout? C-style printf() is quite dangerous,
    > especially if you don't know how to use it.


    cout code looks like crap, if there are multiple parameters or explicit
    format specifiers involved. And for this simple example it simply makes
    no difference.

    The API looks to me like someone wanted to demonstrate what could be
    done with operator overloading in C++ in the early 90's.

    >> fwrite(str, len, 1, stdout);

    >
    > This outputs also the zero terminator, not sure if this was the intention.


    True. This was intended, to demonstrate what happens if one takes the
    raw literal. The \0 may not show up on every shell, but at least the len
    tells it's existence.


    Marcel
     
    Marcel Müller, May 13, 2013
    #4
  5. qak

    Öö Tiib Guest

    On Thursday, 16 May 2013 11:05:59 UTC+3, Juha Nieminen wrote:
    > Andy Champ <> wrote:
    > >> How would you use printf in a situation like this?
    > >>
    > >> template<typename T>
    > >> void foo(T value)
    > >> {
    > >> std::printf("???", value);
    > >> }
    > >>

    > >
    > > template <> void foo(size_t value)
    > > {
    > > std::printf("%zd", value);
    > > }

    >
    > And you repeat that for every single type that std::printf supports,
    > now and in the future?


    I think we should have C++ printf. If for nothing else then just to silence that
    boring argument. Something like in Java or like boost::format would eventually
    calm it down. With variadic templates we have all the tools we need for making
    type-safe printf.
     
    Öö Tiib, May 16, 2013
    #5
  6. qak

    James Kanze Guest

    On Thursday, May 16, 2013 11:52:00 AM UTC+1, Öö Tiib wrote:
    > On Thursday, 16 May 2013 11:05:59 UTC+3, Juha Nieminen wrote:


    > I think we should have C++ printf. If for nothing else then
    > just to silence that boring argument. Something like in Java
    > or like boost::format would eventually calm it down. With
    > variadic templates we have all the tools we need for making
    > type-safe printf.


    There's no need for variadic templates; Boost already has
    boost::format (although it makes the disasterous choice of % as
    the formatting operator), and long be fore that, I'd implemented
    a Format class.

    I suspect that the reason it doesn't make it into the standard
    is that there's really no use for them. The native ostream is
    more intuitive and easier to use.

    --
    James
     
    James Kanze, May 16, 2013
    #6
  7. qak

    Öö Tiib Guest

    On Thursday, 16 May 2013 18:06:53 UTC+3, James Kanze wrote:
    > On Thursday, May 16, 2013 11:52:00 AM UTC+1, Öö Tiib wrote:
    > > I think we should have C++ printf. If for nothing else then
    > > just to silence that boring argument. Something like in Java
    > > or like boost::format would eventually calm it down. With
    > > variadic templates we have all the tools we need for making
    > > type-safe printf.

    >
    > There's no need for variadic templates; Boost already has
    > boost::format (although it makes the disasterous choice of % as
    > the formatting operator), and long be fore that, I'd implemented
    > a Format class.


    Yes, what I meant was that with variadic templates it can look more
    natural than boost::format but still have same type-safety and
    support to user-defined types.

    > I suspect that the reason it doesn't make it into the standard
    > is that there's really no use for them. The native ostream is
    > more intuitive and easier to use.


    People make and use alternatives like 'QString("%1 %2").arg(a).arg(b)'
    or 'boost::format("%1% %2%") % a % b' so it must be is attractive and
    elegant for their taste.
     
    Öö Tiib, May 17, 2013
    #7
  8. Öö Tiib wrote:

    > On Thursday, 16 May 2013 18:06:53 UTC+3, James Kanze wrote:
    >> I suspect that the reason it doesn't make it into the standard is
    >> that there's really no use for them. The native ostream is more
    >> intuitive and easier to use.

    >
    > People make and use alternatives like 'QString("%1
    > %2").arg(a).arg(b)' or 'boost::format("%1% %2%") % a % b' so it must
    > be is attractive and elegant for their taste.


    Besides, it's very inconvenient to use std::eek:stream for
    internationalization (the position of embedded runtime values may change
    with the output language). You need something like boost::format to do
    that nicely.

    Gerhard
     
    Gerhard Fiedler, May 21, 2013
    #8
  9. qak

    James Kanze Guest

    On Tuesday, May 21, 2013 10:57:39 AM UTC+1, Gerhard Fiedler wrote:
    > �� Tiib wrote:
    > > On Thursday, 16 May 2013 18:06:53 UTC+3, James Kanze wrote:
    > >> I suspect that the reason it doesn't make it into the standard is
    > >> that there's really no use for them. The native ostream is more
    > >> intuitive and easier to use.


    > > People make and use alternatives like 'QString("%1
    > > %2").arg(a).arg(b)' or 'boost::format("%1% %2%") % a % b' so it must
    > > be is attractive and elegant for their taste.


    > Besides, it's very inconvenient to use std::eek:stream for
    > internationalization (the position of embedded runtime values
    > may change with the output language). You need something like
    > boost::format to do that nicely.


    There's nothing surprising going on here. Things like QString
    or boost::format are just imitating something which sounded like
    a good idea at the time. (The X/Open extensions to printf.) In
    the meantime, those of us who had access to the original and
    could actually try to use it realized that it wasn't such a good
    idea after all. If you're trying to handle multilingual output,
    neither the printf extensions nor any of its imitators help.
    The difference between languages goes way beyond the order in
    which you embed runtime values: you need to modify words
    depending on singular or plural (or dual), or the word order
    depends on the actual words, and any number of other issues. In
    the end, you have to write a separate DLL for each language, or
    you end up compromizing.

    --
    James
     
    James Kanze, May 21, 2013
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Prakash Prabhu

    String literal and String Object

    Prakash Prabhu, Aug 27, 2003, in forum: Java
    Replies:
    3
    Views:
    655
    John C. Bollinger
    Aug 27, 2003
  2. Replies:
    5
    Views:
    756
    Frank Schmitt
    Sep 22, 2003
  3. herrcho
    Replies:
    7
    Views:
    435
    Jack Klein
    Sep 26, 2003
  4. Replies:
    10
    Views:
    787
    Roland Pibinger
    Jan 24, 2007
  5. Anonieko Ramos

    What's wrong with rpc-literal? Why use doc-literal?

    Anonieko Ramos, Sep 27, 2004, in forum: ASP .Net Web Services
    Replies:
    0
    Views:
    392
    Anonieko Ramos
    Sep 27, 2004
Loading...

Share This Page