Wednesday, October 10, 2018

Digest for comp.lang.c++@googlegroups.com - 11 updates in 5 topics

ram@zedat.fu-berlin.de (Stefan Ram): Oct 10 05:37PM

>How in the world could you know what I started out writing? Unless you
>have me under servelance, you only saw the version I posted after making
>the changes I described later.
 
James did not start out to write "servelance"
(a lancer who is serving someone, origin of
the term "freelancer") but "surveillance"
(from the French "surveiller", "to watch over").
ram@zedat.fu-berlin.de (Stefan Ram): Oct 10 10:22PM

>Is it for certain that the expression T() won't get evaluated in (2)?
 
A default argument is evaluated each time the function is
called with no argument for the corresponding parameter.
 
n4762 9.2.3.6 Default arguments [dcl.fct.default] p9s1
 
A constructor is a function too.
 
p9s1 does not explicitly say that it is not evaluated otherwise,
but I believe that this can be taken to be implied.
Daniel <danielaparker@gmail.com>: Oct 10 03:00PM -0700

Consider the following:
 
class A
{
int n;
public:
A() = delete;
A(int n)
: n(n)
{
}
};
 
template <class T>
class B
{
T t;
public:
B(T t = T())
: t(t)
{
}
};
 
(1) B<A>(); // fails, as expected
 
(2) B<A>(A(1)); // ?
 
Is it for certain that the expression T() won't get evaluated in (2)?
 
Thanks,
Daniel
Tim Rentsch <txr@alumni.caltech.edu>: Oct 10 09:17AM -0700

>> good way of doing things, but it does have retained state.
 
> That's a technically correct observation, but entirely misses
> the point.
 
My comment was on point for the statement it was responding to,
which is quite intentionally the only point it was addressing.
Get the intellectual chip off your shoulder. Your sense of
self-importance is rather larger than is warranted.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Oct 10 07:37PM +0200

On 10.10.2018 18:17, Tim Rentsch wrote:
> which is quite intentionally the only point it was addressing.
> Get the intellectual chip off your shoulder. Your sense of
> self-importance is rather larger than is warranted.
 
How you deduce "sense of self-importance" from a technical observation
is beyond me, I'm sorry.
 
It seems to be a psychological mechanism at play in your mind.
 
Maybe sleep some, go for a walk, talk with people. Listen to music. Read
cartoons, whatever.
 
 
Cheers & hth.,
 
- Alf
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Oct 10 01:05AM +0100

On Tue, 9 Oct 2018 12:32:39 -0700 (PDT)
 
> You said that the definitions didn't explain the differences between
> extended and standard integer types. I started out writing that they
> fully explained the only difference between the two categories.
 
I know that, you are restating yourself. I disagree.
 
 
> Every statement the standard makes about signed integer types, integer
> types, or arithmetic types, is a statement that constrains the
> implementation of extended signed integer types
 
I never said they didn't.
 
- and there's a lot of
> fraction of all the things it says about such types.
> The standard doesn't impose any other constraints on the implementation
> of signed integer types.
 
None of which are relevant to the issue which began this. I dealt with
the (irrelevant) provisions of the standard which you had successively
argued supported your assertions. I am not going to deal with the
irrelevant provisions you haven't previously argued do so. As an
aside, the most essential property of a signed integer type, that
within a given range it must be capable of holding whole numbers on the
number line in an exact form, is to the best of my knowledge not
explicitly stated in the standard. Nor need it be, as it is
sufficiently implicit.
 
> > ... and
> > that it must have an unsigned analogue.
 
> Which is NOT a difference from the standard signed integer types.
 
I never said it was.
 
> standard library functions that treat it as a character type, would be a
> perfectly reasonable extension to C++ - I don't see how the concept of a
> extension could be interpreted as prohibiting such a type.
 
Conversion rank is a side issue: to say that any standard type can
become an extended type because extended types have a different
conversion rank from standard types of the same size is a circularity.
 
This issue has become both full of prolix irrelevance, and pointless.
No implementation is going to do what you say it can do, and I don't
especially care if it didn't. Aside from that I am not going to repeat
my views. They are there for the reading. I do not intend to respond
further unless you misrepresent my views, as I think you have become
close to doing.
Tim Rentsch <txr@alumni.caltech.edu>: Oct 10 04:43AM -0700


> A compiler vendor can offer extended integer types. For a
> compiler vendor it would not be reasonable to offer such types
> as `enum` types. So that was not what I was talking about.
 
I see, you were changing the subject. The discussion had been
about what implementations could do, and you wanted to talk
about what user programs could do.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Oct 10 02:07PM +0200

On 10.10.2018 13:43, Tim Rentsch wrote:
 
> I see, you were changing the subject. The discussion had been
> about what implementations could do, and you wanted to talk
> about what user programs could do.
 
Not sure where you get these ideas. But if you refrain from speculating
about motives, then you can save some time. For yourself and others.
 
I was using of my time to /help/ you. Because you expressed a wish to
have `uint8_t` types "distinct from the standard character types".
 
Then I get in return that I was changing the subject, as if I was not
comfortable with the current subject. That's a not nice behavior. I want
you to improve in that regard.
 
 
Cheers!,
 
- Alf
James Kuyper <jameskuyper@alumni.caltech.edu>: Oct 10 01:29PM -0400

On 10/09/2018 08:05 PM, Chris Vine wrote:
>> extended and standard integer types. I started out writing that they
>> fully explained the only difference between the two categories.
 
> I know that,
 
How in the world could you know what I started out writing? Unless you
have me under servelance, you only saw the version I posted after making
the changes I described later.
 
> ... you are restating yourself. I disagree.
 
No, I was not restating myself. I never published that version of the
statement, and I mentioned that version in this context only to explain
that I realized that that version would have been incorrect.
 
>> types, or arithmetic types, is a statement that constrains the
>> implementation of extended signed integer types
 
> I never said they didn't.
 
No, but your claim that the standard "says very little" about such
matters doesn't hold up when you consider everything it says in that
manner. We're talking about hundreds, possibly thousands of words of
relevant specification.
 
 
> None of which are relevant to the issue which began this. I dealt with
> the (irrelevant) provisions of the standard which you had successively
> argued supported your assertions.
 
The provisions of the standard that you specify as being irrelevant are,
in fact irrelevant to your main point; but you haven't bothered
explaining or defending your main point, preferring argument by
assertion. As a result, very little of what I have said in response has
been addressed to your main point - most of it has involved correcting
misstatements on your part that you made while not addressing the main
point, such as claiming that the standard says little about extended
integer types, or implying that there was something unexplained about
the differences between extended and standard types.
 
> number line in an exact form, is to the best of my knowledge not
> explicitly stated in the standard. Nor need it be, as it is
> sufficiently implicit.
 
It's implied by what the standard says about how integer types may be
represented. The representation described can only represent integers,
and can represent every integer value between the smallest and largest
integer values that are representable by it.
 
>> perfectly reasonable extension to C++ - I don't see how the concept of a
>> extension could be interpreted as prohibiting such a type.
 
> Conversion rank is a side issue: ...
 
Conversion rank is not an issue at all; as I said earlier, I mentioned
it only to make it easier to correctly word my assertion that the
standard does describe the main difference between those type
categories. Conversion rank is the other, much more minor difference,
and irrelevant to my arguments (except insofar as it complicated them by
requiring me to explain "main difference" versus "only difference".
 
> .... to say that any standard type can
> become an extended type because extended types have a different
> conversion rank from standard types of the same size is a circularity.
 
I'm not sure what that phrase means to you, but I am quite sure that
phrase does not describe any assertion that I made. I was not talking
about a standard type becoming an extended type. I was talking about a
standard type and an extended type having the same representation and
mathematical properties, just like the fact that, on many systems, "int"
and "long" have the same representation and mathematical properties,
despite being different an incompatible types. And mentioning conversion
rank was something I added only because the standard requires that the
members of any such pair of types must have different conversion rank -
that fact had no other role to play in my argument that such a pair
would be permitted (the pair would definitely not be permitted if it
violated that requirement).
Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Oct 09 11:02PM -0400

Öö Tiib wrote:
> part of object not its type. Lambdas may capture those.
> So lambda is of unspecified type that is not required to be
> default-constructive.
Well, when there are captures, the default constructor's semantics is, indeed,
unclear.
 
When there is no capture as in OP question, I feel that the opposite is true:
anything but trivial default constructor is unnatural. The original (?) proposal
can be read here:
http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0624r0.pdf and the
motivation is pretty much same as the OP's, namely the consistency with function
object construction.
 
I can see it's included in 8.4.5-12 of n4750 draft.
 
-Pavel
 
"Öö Tiib" <ootiib@hot.ee>: Oct 10 09:27AM -0700

On Wednesday, 10 October 2018 06:03:14 UTC+3, Pavel wrote:
> motivation is pretty much same as the OP's, namely the consistency with function
> object construction.
 
> I can see it's included in 8.4.5-12 of n4750 draft.
 
Thanks for the link. The idea basically lets us to have code in
template argument list like that:
 
std::set<std::string, decltype([](auto x, auto y) {return x > y;})> map;
 
Some will hate to see it but ... matter of taste. Also there will be
a question in stackoverflow over a week asking to explain strange
diagnostics when they try same with lambda that captures something.
And after fix is suggested they will ask same question like OP of
this thread.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)