Bad constructor call?

This is a discussion on Bad constructor call? within the C++ Programming forums, part of the General Programming Boards category; Today, I thought I'd ask a very interesting question. Consider the following code: Code: m_Distribution = std::uniform_int<int>(0, AvailableSymbols.size() - 1); ...

  1. #1
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,022

    Bad constructor call?

    Today, I thought I'd ask a very interesting question. Consider the following code:

    Code:
    m_Distribution = std::uniform_int<int>(0, AvailableSymbols.size() - 1);
    m_Distribution = (decltype(m_Distribution))(0, AvailableSymbols.size() - 1);
    Now, the first row works as expected. It calls the std::uniform_int<int>(0, 4) constructor (in my case). However, I figured the second row should work as well.
    Unfortunately, it doesn't quite work. I'm not 100% sure why, but it calls std::uniform_int<int>(0, 9) (with 9 being a default value for the constructor).
    I'm guessing it's because the compiler interprets (decltype(m_Distribution)) as (std::uniform_int<int>). That is, a C-style cast.

    Still, does anyone know? And might there be a way of calling the constructor without specifying the exact type? I'd be interested in knowing.

    (Btw,
    Code:
    m_Distribution = decltype(m_Distribution)(0, AvailableSymbols.size() - 1);
    doesn't compile.)
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  2. #2
    The larch
    Join Date
    May 2006
    Posts
    3,573
    Code:
    m_Distribution = (decltype(m_Distribution))(0, AvailableSymbols.size() - 1);
    This is casting the result of a comma-expression into a uniform_int.

    Code:
    m_Distribution = decltype(m_Distribution)(0, AvailableSymbols.size() - 1);
    This compiles fine with GCC.

    Code:
    m_Distribution = {0, AvailableSymbols.size() - 1};
    This also compiles fine with GCC.
    I might be wrong.

    Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
    Quoted more than 1000 times (I hope).

  3. #3
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,022
    Quote Originally Posted by anon View Post
    This is casting the result of a comma-expression into a uniform_int.
    Hmmm. I figured as much.

    This compiles fine with GCC.
    So it's valid, simply not supported by Visual C++ yet. I see. Nice to know at least.

    This also compiles fine with GCC.
    Variable initializers like that aren't supported yet, though, unfortunately.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  4. #4
    Registered User
    Join Date
    Jun 2005
    Posts
    6,660
    Quote Originally Posted by Elysia View Post
    I'm guessing it's because the compiler interprets (decltype(m_Distribution)) as (std::uniform_int<int>). That is, a C-style cast.
    To be pedantic, that is an explicit initialisation of a type. The syntax "some_typename(one_or_more_arguments) represents a constructor call of some_typename that accepts the arguments. For a single argument, it would be a type conversion. Adding in brackets , as in "(some_typename)(one_or_more_arguments)" doesn't change the meaning.

    If your compiler requires the brackets then that - at a guess, as your compiler is effectively a black box - reflects a limitation in how the compiler parses the expression, which might mean it is falling back somehow on how it does a C cast/conversion.

    Quote Originally Posted by Elysia View Post
    And might there be a way of calling the constructor without specifying the exact type? I'd be interested in knowing.
    An underpinning of the C++ type system is that the compiler needs to know (or be able to unambiguously infer) the required type before creating an object. I'm not aware of any way of calling a constructor without somehow supplying appropriate type information, and would be surprised if there was a way.
    Right 98% of the time, and don't care about the other 3%.

    If I seem grumpy or unhelpful in reply to you, or tell you you need to demonstrate more effort before you can expect help, it is likely you deserve it. Suck it up, Sunshine, and read this, this, and this before posting again.

  5. #5
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,022
    Quote Originally Posted by grumpy View Post
    An underpinning of the C++ type system is that the compiler needs to know (or be able to unambiguously infer) the required type before creating an object. I'm not aware of any way of calling a constructor without somehow supplying appropriate type information, and would be surprised if there was a way.
    No, what I meant was something like decltype, allowing the compiler to deduce the type of something without me having to say so.
    And apparently it works. Just not in the Visual C++ compiler.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 6
    Last Post: 11-12-2005, 11:57 AM
  2. Bad coding habits
    By Magos in forum A Brief History of Cprogramming.com
    Replies: 14
    Last Post: 09-12-2005, 06:44 PM
  3. Shocking(kind of)
    By Shadow in forum A Brief History of Cprogramming.com
    Replies: 25
    Last Post: 12-10-2002, 08:52 PM
  4. good news and bad news
    By Garfield in forum A Brief History of Cprogramming.com
    Replies: 25
    Last Post: 10-27-2001, 08:31 AM
  5. Bad code or bad compiler?
    By musayume in forum C Programming
    Replies: 3
    Last Post: 10-22-2001, 10:08 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21