Re: How to use std::cout to output a char as a number?

Discussion in 'C++' started by dan.furlani@earthling.net, Oct 2, 2007.

  1. Guest

    On Apr 30, 7:52 am, Dancefire <> wrote:
    > Hi, everyone
    >
    > It might be a simple question, but I really don't know the answer.
    >
    > charc = '1';cout<< c;
    >
    > The above code will only output a '1' rather than 0x31;


    A quick and dirty solution:

    class MyOs {
    public:
    MyOs(ostream &os) : os_(os) { }

    template <typename T>
    ostream & operator<<(T thing) { os_ << thing; return os_; }

    ostream & operator<<(char ch) // treat as unsigned.
    { os_ << static_cast<unsigned short>(static_cast<unsigned
    char>(ch)); return os_; }
    ostream & operator<<(signed char ch)
    { os_ << static_cast<signed short>(ch); return os_; }
    ostream & operator<<(unsigned char ch)
    { os_ << static_cast<unsigned short>(ch); return os_; }

    private:
    ostream &os_;
    };

    enum Fix_Char { fix_char };
    MyOs operator<<(ostream &os, Fix_Char f) { return MyOs(os); }


    Now you can do this:

    template <typename T>
    void foo(T arg) {
    cout << "test " << fix_char << arg << endl;
    }

    I think that does what Dancefire wants but it sure is ugly. Can
    someone please suggest the correct way to implement this?

    -Dan
     
    , Oct 2, 2007
    #1
    1. Advertising

  2. * :
    > On Apr 30, 7:52 am, Dancefire <> wrote:
    >> Hi, everyone
    >>
    >> It might be a simple question, but I really don't know the answer.
    >>
    >> charc = '1';cout<< c;
    >>
    >> The above code will only output a '1' rather than 0x31;

    >
    > A quick and dirty solution:
    >
    > class MyOs {
    > public:
    > MyOs(ostream &os) : os_(os) { }
    >
    > template <typename T>
    > ostream & operator<<(T thing) { os_ << thing; return os_; }
    >
    > ostream & operator<<(char ch) // treat as unsigned.
    > { os_ << static_cast<unsigned short>(static_cast<unsigned
    > char>(ch)); return os_; }
    > ostream & operator<<(signed char ch)
    > { os_ << static_cast<signed short>(ch); return os_; }
    > ostream & operator<<(unsigned char ch)
    > { os_ << static_cast<unsigned short>(ch); return os_; }
    >
    > private:
    > ostream &os_;
    > };
    >
    > enum Fix_Char { fix_char };
    > MyOs operator<<(ostream &os, Fix_Char f) { return MyOs(os); }
    >
    >
    > Now you can do this:
    >
    > template <typename T>
    > void foo(T arg) {
    > cout << "test " << fix_char << arg << endl;
    > }
    >
    > I think that does what Dancefire wants but it sure is ugly. Can
    > someone please suggest the correct way to implement this?


    Uh,

    char c = '1';
    cout << '0x' << hex << c+0;

    should do the trick.

    "+0" causes a conversion to int.


    Cheers, & hth.,

    - Alf

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
     
    Alf P. Steinbach, Oct 2, 2007
    #2
    1. Advertising

  3. James Kanze Guest

    On Oct 2, 1:47 am, "Alf P. Steinbach" <> wrote:
    > * :


    > > On Apr 30, 7:52 am, Dancefire <> wrote:
    > >> It might be a simple question, but I really don't know the answer.


    > >> charc = '1';cout<< c;


    > >> The above code will only output a '1' rather than 0x31;


    [...]
    > Uh,


    > char c = '1';
    > cout << '0x' << hex << c+0;


    > should do the trick.


    > "+0" causes a conversion to int.


    Shades of Fortran. If you want a conversion to int, why don't
    you say so:

    std::cout << hex << (int)c ;

    (For those not familiar with Fortran, adding 0 to an argument
    was a traditional way of simulating pass by value, which Fortran
    didn't have otherwise.)

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Oct 2, 2007
    #3
  4. * James Kanze:
    > On Oct 2, 1:47 am, "Alf P. Steinbach" <> wrote:
    >> * :

    >
    >>> On Apr 30, 7:52 am, Dancefire <> wrote:
    >>>> It might be a simple question, but I really don't know the answer.

    >
    >>>> charc = '1';cout<< c;

    >
    >>>> The above code will only output a '1' rather than 0x31;

    >
    > [...]
    >> Uh,

    >
    >> char c = '1';
    >> cout << '0x' << hex << c+0;

    >
    >> should do the trick.

    >
    >> "+0" causes a conversion to int.

    >
    > Shades of Fortran. If you want a conversion to int, why don't
    > you say so:


    I did.


    > std::cout << hex << (int)c ;


    Not a good habit. :)


    > (For those not familiar with Fortran, adding 0 to an argument
    > was a traditional way of simulating pass by value, which Fortran
    > didn't have otherwise.)


    I don't understand how anybody can be unfamiliar with Fortran. Common
    blocks, RATFOR... Ah.

    Cheers,

    - Alf

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
     
    Alf P. Steinbach, Oct 2, 2007
    #4
  5. Alan Woodland wrote:
    > James Kanze wrote:
    >>> char c = '1';
    >>> cout << '0x' << hex << c+0;

    >>
    >>> should do the trick.

    >>
    >>> "+0" causes a conversion to int.

    >>
    >> Shades of Fortran. If you want a conversion to int, why don't
    >> you say so:
    >>
    >> std::cout << hex << (int)c ;

    > C-Style casts?
    >
    > surely
    >
    > static_cast<int>(c);
    >
    > or
    >
    > int(c);
    >
    > would better still?


    I wonder why *in this particular case* it would be better. Care
    to elaborate? And let's stick to technical C++ issues instead of
    "perpetuating good habits" kind of argument. Thanks!

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Oct 2, 2007
    #5
  6. anon Guest

    Victor Bazarov wrote:
    > Alan Woodland wrote:
    >> James Kanze wrote:
    >>>> char c = '1';
    >>>> cout << '0x' << hex << c+0;
    >>>> should do the trick.
    >>>> "+0" causes a conversion to int.
    >>> Shades of Fortran. If you want a conversion to int, why don't
    >>> you say so:
    >>>
    >>> std::cout << hex << (int)c ;

    >> C-Style casts?
    >>
    >> surely
    >>
    >> static_cast<int>(c);
    >>
    >> or
    >>
    >> int(c);
    >>
    >> would better still?

    >
    > I wonder why *in this particular case* it would be better. Care


    You made me wonder, so I have to ask:
    Why it wouldn't?

    > to elaborate? And let's stick to technical C++ issues instead of
    > "perpetuating good habits" kind of argument. Thanks!
     
    anon, Oct 2, 2007
    #6
  7. anon wrote:
    > Victor Bazarov wrote:
    >> Alan Woodland wrote:
    >>> James Kanze wrote:
    >>>>> char c = '1';
    >>>>> cout << '0x' << hex << c+0;
    >>>>> should do the trick.
    >>>>> "+0" causes a conversion to int.
    >>>> Shades of Fortran. If you want a conversion to int, why don't
    >>>> you say so:
    >>>>
    >>>> std::cout << hex << (int)c ;
    >>> C-Style casts?
    >>>
    >>> surely
    >>>
    >>> static_cast<int>(c);
    >>>
    >>> or
    >>>
    >>> int(c);
    >>>
    >>> would better still?

    >>
    >> I wonder why *in this particular case* it would be better. Care

    >
    > You made me wonder, so I have to ask:
    > Why it wouldn't?


    There is no difference, AFAICT. When there is no difference, there
    can be no "better" or "worse". Of cousre, I may not know all the
    details, so I am asking why it would, to figure out whether I am
    missing anything.

    C-style casts are syntactically different from the new forms, but
    semantially they are equivalent to the static_cast, the const_cast,
    the reinterpret_cast, or some combination thereof, or (sometimes)
    to some cast that doesn't exist [legally] in C++. In this particular
    case, it's static_cast. Plain and simple. AFAIK, of course.

    >> to elaborate? And let's stick to technical C++ issues instead of
    >> "perpetuating good habits" kind of argument. Thanks!


    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Oct 2, 2007
    #7
  8. James Kanze wrote:
    >> char c = '1';
    >> cout << '0x' << hex << c+0;

    >
    >> should do the trick.

    >
    >> "+0" causes a conversion to int.

    >
    > Shades of Fortran. If you want a conversion to int, why don't
    > you say so:
    >
    > std::cout << hex << (int)c ;

    C-Style casts?

    surely

    static_cast<int>(c);

    or

    int(c);

    would better still?

    Alan
     
    Alan Woodland, Oct 2, 2007
    #8
  9. Pete Becker Guest

    On 2007-10-02 04:52:23 -1000, "Victor Bazarov" <> said:

    > Alan Woodland wrote:
    >> James Kanze wrote:
    >>>> char c = '1';
    >>>> cout << '0x' << hex << c+0;
    >>>
    >>>> should do the trick.
    >>>
    >>>> "+0" causes a conversion to int.
    >>>
    >>> Shades of Fortran. If you want a conversion to int, why don't
    >>> you say so:
    >>>
    >>> std::cout << hex << (int)c ;

    >> C-Style casts?
    >>
    >> surely
    >>
    >> static_cast<int>(c);
    >>
    >> or
    >>
    >> int(c);
    >>
    >> would better still?

    >
    > I wonder why *in this particular case* it would be better. Care
    > to elaborate? And let's stick to technical C++ issues instead of
    > "perpetuating good habits" kind of argument. Thanks!
    >


    Everybody knows that C-style casts are evil. It's not about
    perpetuating good habits, but about avoiding sin. Don't you care about
    the state of your soul? Do you want to burn in hell for all eternity?

    --
    Pete
    Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
    Standard C++ Library Extensions: a Tutorial and Reference
    (www.petebecker.com/tr1book)
     
    Pete Becker, Oct 2, 2007
    #9
  10. Pete Becker wrote:
    > On 2007-10-02 04:52:23 -1000, "Victor Bazarov"
    > <> said:
    >> Alan Woodland wrote:
    >>> James Kanze wrote:
    >>>>> char c = '1';
    >>>>> cout << '0x' << hex << c+0;
    >>>>
    >>>>> should do the trick.
    >>>>
    >>>>> "+0" causes a conversion to int.
    >>>>
    >>>> Shades of Fortran. If you want a conversion to int, why don't
    >>>> you say so:
    >>>>
    >>>> std::cout << hex << (int)c ;
    >>> C-Style casts?
    >>>
    >>> surely
    >>>
    >>> static_cast<int>(c);
    >>>
    >>> or
    >>>
    >>> int(c);
    >>>
    >>> would better still?

    >>
    >> I wonder why *in this particular case* it would be better. Care
    >> to elaborate? And let's stick to technical C++ issues instead of
    >> "perpetuating good habits" kind of argument. Thanks!
    >>

    >
    > Everybody knows that C-style casts are evil. It's not about
    > perpetuating good habits, but about avoiding sin. Don't you care about
    > the state of your soul? Do you want to burn in hell for all eternity?


    LOL

    Thanks, Pete! That was good.

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Oct 2, 2007
    #10
  11. Guest

    On Oct 1, 7:47 pm, "Alf P. Steinbach" <> wrote:
    > Uh,
    > char c = '1';
    > cout << '0x' << hex << c+0;
    > should do the trick.
    > "+0" causes a conversion to int.


    Yes, that sort of approach was suggested in the original thread:
    http://groups.google.com/group/comp.lang.c /browse_thread/thread/b307de1121c0e7d7
    and is only sufficient when you know the value being output is a char-
    type.

    But when you have code like this example:
    > > template <typename T>
    > > void foo(T arg) {
    > > cout << "test " << fix_char << arg << endl;
    > > }


    your approach won't work. The code I posted will, but is ugly.
     
    , Oct 2, 2007
    #11
  12. [snip]
    >>>>>Shades of Fortran. If you want a conversion to int, why don't
    >>>>>you say so:
    >>>>>
    >>>>> std::cout << hex << (int)c ;
    >>>>
    >>>>C-Style casts?
    >>>>
    >>>>surely
    >>>>
    >>>>static_cast<int>(c);
    >>>>
    >>>> or
    >>>>
    >>>>int(c);
    >>>>
    >>>>would better still?
    >>>
    >>>I wonder why *in this particular case* it would be better. Care

    >>
    >>You made me wonder, so I have to ask:
    >>Why it wouldn't?

    > There is no difference, AFAICT. When there is no difference, there
    > can be no "better" or "worse". Of cousre, I may not know all the
    > details, so I am asking why it would, to figure out whether I am
    > missing anything.
    >
    > C-style casts are syntactically different from the new forms, but
    > semantially they are equivalent to the static_cast, the const_cast,
    > the reinterpret_cast, or some combination thereof, or (sometimes)
    > to some cast that doesn't exist [legally] in C++. In this particular
    > case, it's static_cast. Plain and simple. AFAIK, of course.

    Right here, right now this cast is semantically a static_cast, which is
    clearly as intended. My concern with this however is with the
    possibility that not too far down the line this will *silently* become
    some other cast that was most probably not intended. And it doesn't
    really take much of a stretch of the imagination to see this happening
    in the world of templates with a naive developer.

    Alan
     
    Alan John Woodland, Oct 2, 2007
    #12
  13. Alan John Woodland wrote:
    > [snip]
    >>>>>> Shades of Fortran. If you want a conversion to int, why don't
    >>>>>> you say so:
    >>>>>>
    >>>>>> std::cout << hex << (int)c ;
    >>>>>
    >>>>> C-Style casts?
    >>>>>
    >>>>> surely
    >>>>>
    >>>>> static_cast<int>(c);
    >>>>>
    >>>>> or
    >>>>>
    >>>>> int(c);
    >>>>>
    >>>>> would better still?
    >>>>
    >>>> I wonder why *in this particular case* it would be better. Care
    >>>
    >>> You made me wonder, so I have to ask:
    >>> Why it wouldn't?

    >> There is no difference, AFAICT. When there is no difference, there
    >> can be no "better" or "worse". Of cousre, I may not know all the
    >> details, so I am asking why it would, to figure out whether I am
    >> missing anything.
    >>
    >> C-style casts are syntactically different from the new forms, but
    >> semantially they are equivalent to the static_cast, the const_cast,
    >> the reinterpret_cast, or some combination thereof, or (sometimes)
    >> to some cast that doesn't exist [legally] in C++. In this particular
    >> case, it's static_cast. Plain and simple. AFAIK, of course.

    > Right here, right now this cast is semantically a static_cast, which
    > is clearly as intended. My concern with this however is with the
    > possibility that not too far down the line this will *silently* become
    > some other cast that was most probably not intended. And it doesn't
    > really take much of a stretch of the imagination to see this happening
    > in the world of templates with a naive developer.


    Several assumptions at work. With all due respect, "the possibility"
    (meaning NOT guaranteed), "down the line" (meaning NOT in this code),
    "will become" (meaning NOT yet), "probably" (meaning NOT necessarily
    so), "in the world of templates" (meaning NOT in every program), "naive
    developer" (meaning NOT necessarily the OP), all contribute to the
    word "surely"'s being out of place. *As far as I know* there is no
    difference *whatsoever* between what James has written and what you've
    written for the purposes of printing out the integer value of a char.

    See my point? Any time the suggestion is called for by a software
    engineering principle, like "writing reusable code" or "refactoring
    only when needed", or some such, we should indicate so. comp.lang.c++
    is a technical language newsgroup, and while there are idioms and "best
    practices", their merits are not absolute. And not necessarily a priori
    known to all.

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Oct 2, 2007
    #13
  14. [snip]
    >>>>>>> std::cout << hex << (int)c ;
    >>>>>> C-Style casts?
    >>>>>>
    >>>>>> surely
    >>>>>>
    >>>>>> static_cast<int>(c);
    >>>>>>
    >>>>>> or
    >>>>>>
    >>>>>> int(c);
    >>>>>>
    >>>>>> would better still?
    >>>>> I wonder why *in this particular case* it would be better. Care
    >>>> You made me wonder, so I have to ask:
    >>>> Why it wouldn't?
    >>> There is no difference, AFAICT. When there is no difference, there
    >>> can be no "better" or "worse". Of cousre, I may not know all the
    >>> details, so I am asking why it would, to figure out whether I am
    >>> missing anything.
    >>>
    >>> C-style casts are syntactically different from the new forms, but
    >>> semantially they are equivalent to the static_cast, the const_cast,
    >>> the reinterpret_cast, or some combination thereof, or (sometimes)
    >>> to some cast that doesn't exist [legally] in C++. In this particular
    >>> case, it's static_cast. Plain and simple. AFAIK, of course.

    >> Right here, right now this cast is semantically a static_cast, which
    >> is clearly as intended. My concern with this however is with the
    >> possibility that not too far down the line this will *silently* become
    >> some other cast that was most probably not intended. And it doesn't
    >> really take much of a stretch of the imagination to see this happening
    >> in the world of templates with a naive developer.

    >
    > Several assumptions at work. With all due respect, "the possibility"
    > (meaning NOT guaranteed), "down the line" (meaning NOT in this code),
    > "will become" (meaning NOT yet), "probably" (meaning NOT necessarily
    > so), "in the world of templates" (meaning NOT in every program), "naive
    > developer" (meaning NOT necessarily the OP), all contribute to the
    > word "surely"'s being out of place. *As far as I know* there is no
    > difference *whatsoever* between what James has written and what you've
    > written for the purposes of printing out the integer value of a char.


    > See my point? Any time the suggestion is called for by a software
    > engineering principle, like "writing reusable code" or "refactoring
    > only when needed", or some such, we should indicate so. comp.lang.c++

    Agreed, "surely" sounded somewhat stronger than I initially meant for it to.

    > is a technical language newsgroup, and while there are idioms and "best
    > practices", their merits are not absolute. And not necessarily a priori
    > known to all.

    That said, if I'd suggested a solution to another (hypothetical) problem
    in another thread that involved using printf/malloc or some other older
    C-style approach without apparent reason I'm sure it would have
    attracted criticism. This despite the fact the solution could be an
    equally valid answer to the OP. Why would C-style casting syntax in this
    case be any different than other C-style functions/syntax?

    To phrase my central point as a technical language related question
    though: "Why aren't C-style casts marked or viewed as deprecated more? -
    Aren't they only in the language now to provide compatibility with C
    code, not because they add any useful or tangible benefit to modern C++
    developers?"

    Alan
     
    Alan Woodland, Oct 2, 2007
    #14
  15. * :
    > On Oct 1, 7:47 pm, "Alf P. Steinbach" <> wrote:
    >> Uh,
    >> char c = '1';
    >> cout << '0x' << hex << c+0;
    >> should do the trick.
    >> "+0" causes a conversion to int.

    >
    > Yes, that sort of approach was suggested in the original thread:
    > http://groups.google.com/group/comp.lang.c /browse_thread/thread/b307de1121c0e7d7


    You did not refer to that thread in your posting.

    The article did not have a "References:" header.



    > and is only sufficient when you know the value being output is a char-
    > type.


    I.e. the solution offered is sufficient for the question you actually
    quoted.



    > But when you have code like this example:
    >>> template <typename T>
    >>> void foo(T arg) {
    >>> cout << "test " << fix_char << arg << endl;
    >>> }

    >
    > your approach won't work. The code I posted will, but is ugly.


    I'm not going to look up the "original thread".

    If there were relevant extra requirements you should have quoted them.

    For the case of arg of unknown type T above there is no general
    solution, because what's needed to convert a T to a reasonable
    hexadecimal value representation depends on T.

    Your code seems to assume that T is either char, unsigned char or signed
    char.

    Under that assumption, arg+0 works nicely.


    Cheers, & hth.,

    - Alf


    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
     
    Alf P. Steinbach, Oct 3, 2007
    #15
  16. James Kanze Guest

    On Oct 2, 11:39 am, "Alf P. Steinbach" <> wrote:
    > * James Kanze:
    > > On Oct 2, 1:47 am, "Alf P. Steinbach" <> wrote:
    > >> * :


    > >>> On Apr 30, 7:52 am, Dancefire <> wrote:
    > >>>> It might be a simple question, but I really don't know the answer.


    > >>>> charc = '1';cout<< c;


    > >>>> The above code will only output a '1' rather than 0x31;


    > > [...]
    > >> Uh,


    > >> char c = '1';
    > >> cout << '0x' << hex << c+0;


    > >> should do the trick.


    > >> "+0" causes a conversion to int.


    > > Shades of Fortran. If you want a conversion to int, why don't
    > > you say so:


    > I did.


    > > std::cout << hex << (int)c ;


    > Not a good habit. :)


    Agreed. You shouldn't normally use the standard manipulators
    (except perhaps std::setw), but rather application specific
    ones. But as a demonstration of the basic principle:).

    > > (For those not familiar with Fortran, adding 0 to an argument
    > > was a traditional way of simulating pass by value, which Fortran
    > > didn't have otherwise.)


    > I don't understand how anybody can be unfamiliar with Fortran. Common
    > blocks, RATFOR... Ah.


    Not everyone is a real programmer today. The quiche eaters are
    becoming more and more numerous.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Oct 3, 2007
    #16
  17. James Kanze Guest

    On Oct 2, 7:09 pm, Alan John Woodland <> wrote:
    > [snip]
    > > C-style casts are syntactically different from the new forms, but
    > > semantially they are equivalent to the static_cast, the const_cast,
    > > the reinterpret_cast, or some combination thereof, or (sometimes)
    > > to some cast that doesn't exist [legally] in C++. In this particular
    > > case, it's static_cast. Plain and simple. AFAIK, of course.


    > Right here, right now this cast is semantically a static_cast,
    > which is clearly as intended.


    Is it? What is intended is the creation of a new *object*.
    What is commonly called an "explicit constructor call". I'm
    dealing with an object, not a pointer to an object. With a user
    defined type, I would have written "A(c)"; with built in types,
    this doesn't always work, e.g. "unsigned long(c)" is not legal.
    So I put the names of built-in types in parentheses.

    Sometimes:). Sometimes I use static_cast. (I do normally put
    the constructor arguments in parentheses, i.e. (int)( c ),
    rather than just (int)c.)

    > My concern with this however is with the possibility that not
    > too far down the line this will *silently* become some other
    > cast that was most probably not intended.


    I don't think so. I don't think of this so much as a "type
    conversion", as as the creation of a new temporary object.

    > And it doesn't really take much of a stretch of the
    > imagination to see this happening in the world of templates
    > with a naive developer.


    I don't allow naive developers to work on templates:).

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Oct 3, 2007
    #17
  18. James Kanze Guest

    On Oct 2, 11:43 pm, Alan Woodland <> wrote:
    > [snip]


    > > is a technical language newsgroup, and while there are idioms and "best
    > > practices", their merits are not absolute. And not necessarily a priori
    > > known to all.


    > That said, if I'd suggested a solution to another
    > (hypothetical) problem in another thread that involved using
    > printf/malloc or some other older C-style approach without
    > apparent reason I'm sure it would have attracted criticism.


    It would depend on context, I think.

    > This despite the fact the solution could be an equally valid
    > answer to the OP. Why would C-style casting syntax in this
    > case be any different than other C-style functions/syntax?


    > To phrase my central point as a technical language related question
    > though: "Why aren't C-style casts marked or viewed as deprecated more? -
    > Aren't they only in the language now to provide compatibility with C
    > code, not because they add any useful or tangible benefit to modern C++
    > developers?"


    The whole issue is IMHO somewhat confusing. Personally, I find
    it useful to distinguish between "treating an object of type A
    as an object of type B", and "creating a new temporary object of
    type A, using an expression of type B to initialize it". At
    least at a logical level---pointers are also objects, and a
    pointer cast does create a new pointer object, but the purpose
    of the cast is usually to treat the pointed to object as if it
    had a different type. There are several ways to do the first:
    you can look at the same bytes (type punning), or you can move
    around in an inheritance hierarchy. So we want (and have)
    different names for it: reinterpret_cast, dynamic_cast. In the
    second case, however, static_cast suggests a "type conversion"
    (and that's what the standard calls it), but what I'm
    conceptually doing is creating a new object. For a class type,
    I'd write A(c), but for the basic types, this doesn't always
    work (e.g. unsigned long), so I'll put the typename in
    parentheses. So I end up using all three cast notations in the
    same program (although const_cast and static_cast are extremely
    rare).

    It's a question of convention, and I have no trouble adopting
    whatever convention the client uses, for "value" conversions
    (i.e. conceptually creating new objects). I only insist on the
    new style casts for conversions in which the result of the
    conversion "refers" to the same object as the orginal---pointer
    and reference conversions, in sum.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Oct 3, 2007
    #18
  19. Jerry Coffin Guest

    In article <>, says...

    [ ... ]

    > I don't understand how anybody can be unfamiliar with Fortran. Common
    > blocks, RATFOR... Ah.



    Look up "repressed memory". Note its usual association with particularly
    traumatic memories...

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
     
    Jerry Coffin, Oct 3, 2007
    #19
  20. Jerry Coffin Guest

    In article <>, says...

    [ ... ]

    > To phrase my central point as a technical language related question
    > though: "Why aren't C-style casts marked or viewed as deprecated more? -
    > Aren't they only in the language now to provide compatibility with C
    > code, not because they add any useful or tangible benefit to modern C++
    > developers?"


    It's open to question whether you'd want to write a lot of new code
    using it, but C-style casts have at least one capability absent from the
    newer casts.

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
     
    Jerry Coffin, Oct 3, 2007
    #20
    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. Pmb

    std::cout vs cout

    Pmb, Jun 2, 2004, in forum: C++
    Replies:
    2
    Views:
    4,438
    Leor Zolman
    Jun 2, 2004
  2. Dancefire
    Replies:
    19
    Views:
    726
    Gennaro Prota
    May 2, 2007
  3. Stefan Ram

    Re: cout vs std::cout

    Stefan Ram, Sep 28, 2008, in forum: C++
    Replies:
    7
    Views:
    504
  4. saurabh29789

    Sending std::cout to std::cout !!

    saurabh29789, Jun 11, 2009, in forum: C++
    Replies:
    1
    Views:
    305
    Harald Finster
    Jun 11, 2009
  5. saurabh29789

    Sending std::cout to std::cout

    saurabh29789, Jun 11, 2009, in forum: C++
    Replies:
    2
    Views:
    353
    Rolf Magnus
    Jun 12, 2009
Loading...

Share This Page