Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.std.c++ > #658

Re: proposal : keyword default

Show all headers | View raw

Hi everybody,

I was about to submit the initial proposal but then searched and found out that I'm a bit late:)
Anyway, I am the one who supports such an addition, I wish the discussion would continue, and here are my reasons and thoughts from the previous discussion:

1. The most important one that nobody mentioned.
Default arguments are already added to the language and removing them is impossible, so now we have to deal with them correctly.
One most common issue about default arguments is encapsulation violation. With introducing a default argument we introduce sort of a default context state for a function,
and it's only the function that is aware about this default state and knows how to handle it correctly.
Let's get back to the initial code which illustrates the problem super clear:

void make_thread(
   thread_function* fp,
   void* params = 0,
   void* stack = 0,
   long params = JOINABLE| NEW_LWP,
   thread_t* thr_id = 0)

So, the implementation knows about default arguments and handle them in a special way. Now let's say we need to create a new thread and obtain its ID, we are forced to do it this way:

thread_t thr_id = 0;
make_thread(thread_function, 0, 0, JOINABLE | NEW_LWP, &thr_id);

The problem is exactly this place 'JOINABLE | NEW_LWP' because we need to refer to function declaration, extract its default state and use it. What if this argument is platform specific, e.g.:
void make_thread(
   thread_function* fp,
   void* params = 0,
   void* stack = 0,
#ifdef _WIN32_WINNT
   long params = JOINABLE, // no LWP for Windows
#else
   long params = JOINABLE| NEW_LWP,
#endif
   thread_t* thr_id = 0)

In this case we need to fix our client code everywhere and what for? Just for obtaining thread ID!
Each time we will need to provide a default data that has to be known to implementation only (encapsulation violation) and do it in every place where we need to obtain thread ID (unnecessary dependency). In total we have 2 major issues.

Instead it would be elegant to just use:

thread_t thr_id = 0;
make_thread(thread_function, default, default, default, &thr_id);


2.
>> First, I want to emphasize that introducing default don't
>> force you to change a single line of existing code.
>I agree that it is a pure extension, and that it does not effect existing code.
Totally agree.

3.
>> So it won't hurt, even if it doesn't help.
>I disagree. It will assist people in making the bad design decision of having a tremendous number of arguments to a function.
Totally disagree about disagreement. The same can be said about auto keyword in terms of helping people in making the bad design decision of having a tremendous number of template arguments.
It's a matter or right usage only, even the best designed language still can be misused.


4.
>This is a problem, but consider
>void abc ( int, int = 5);
>void abc ( int, double = 5.0);
>Then
>abc(1, default)
>is same as
>abc(1)
Hm... But 'abc(1); abc(1);' causes the same problem, I would not take this argument into account.

5.
>>  proc( 0, default * default.negate() + (default = Complex(1,0)) );
>> foo(5, (double)default);
> I think the proposal is substantially simpler if we are not allowed to use "default" in expressions.
Totally agree, if it is a default argument substitution - no expressions are allowed.



Please correct me if I'm wrong, provide a strong weighted objection or support me. This is a very useful feature and it would be wrong to let it die.

Thank you.

---
Alex


-- 
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Back to comp.std.c++ | Previous | Next — Next in thread | Find similar

Thread

Re: proposal : keyword default alexander.stoyan@googlemail.com - 2013-10-03 13:25 -0600
  Re: proposal : keyword default Daniel Krügler <daniel.kruegler@googlemail.com> - 2013-10-04 11:19 -0700
  Re: proposal : keyword default "Paul D. DeRocco" <pderocco@ix.netcom.com> - 2013-10-04 11:58 -0700
    Re: proposal : keyword default Bo Persson <bop@gmb.dk> - 2013-10-05 19:19 -0700
      Re: proposal : keyword default Edward Diener <eldiener@tropicsoft.invalid> - 2013-10-07 01:50 -0600
    Re: proposal : keyword default Edward Diener <eldiener@tropicsoft.invalid> - 2013-10-05 19:19 -0700
      Re: proposal : keyword default Francis Glassborow <francis.glassborow@btinternet.com> - 2013-10-07 01:50 -0600
        Re: proposal : keyword default Edward Diener <eldiener@tropicsoft.invalid> - 2013-10-07 15:05 -0600
          Re: proposal : keyword default James Kuyper <jameskuyper@verizon.net> - 2013-10-08 12:36 -0700
          Re: proposal : keyword default Helmut Zeisel <zei2011@liwest.at> - 2013-10-12 03:47 -0600
            Re: proposal : keyword default Edward Diener <eldiener@tropicsoft.invalid> - 2013-10-12 11:36 -0600
              Re: proposal : keyword default ootiib@hot.ee - 2013-10-12 23:10 -0600
              Re: proposal : keyword default John Harris <niam@jghnorth.org.uk.invalid> - 2013-10-13 11:33 -0600
                Re: proposal : keyword default Edward Diener <eldiener@tropicsoft.invalid> - 2013-10-16 10:34 -0600
              Re: proposal : keyword default Helmut Zeisel <zei2011@liwest.at> - 2013-10-14 20:37 -0700
  Re: proposal : keyword default Alexander Terekhov <terekhov@web.de> - 2013-10-18 01:20 -0600

csiph-web