Sunday, July 23, 2017

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

Tim Rentsch <txr@alumni.caltech.edu>: Jul 23 10:27AM -0700


> The use in a parameter list, and the implicit type adjustment, are also
> in ANSI C (1989) but it's not clear if C++ got it from ANSI C or ANSI C
> got it from proto-C++. [...]
 
According to this recounting of history
 
http://www.stroustrup.com/hopl2.pdf
 
the flow is from pre-C++ to ANSI C:
 
"The C with Classes syntax and rules, the ones subsequently
adopted for the ANSI C standard, simply appeared fully
formed in the first C with Classes implementation."
 
as mentioned in section 2.4.3, "Static Type Checking".
woodbrian77@gmail.com: Jul 23 01:19PM -0700

On Sunday, July 23, 2017 at 12:28:13 PM UTC-5, Tim Rentsch wrote:
> adopted for the ANSI C standard, simply appeared fully
> formed in the first C with Classes implementation."
 
> as mentioned in section 2.4.3, "Static Type Checking".
 
I think that's basically right, but might argue with the
"fully formed" part. I think Stroustrup is better when he
says things like he had to "hurry up and fix everything"
when C++ started getting popular.
 
Anyway, I hope something similar to this will happen with
some of the features from C++ 2014 and 2017 being back-ported
to C++ 2011. In particular, I hope string_view and
make_unique will be back-ported. I'd also like the new
version of emplace_back. These are library related items
so I think that makes things a little easier to handle.
 
 
 
Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
"Öö Tiib" <ootiib@hot.ee>: Jul 23 02:26PM -0700

> make_unique will be back-ported. I'd also like the new
> version of emplace_back. These are library related items
> so I think that makes things a little easier to handle.
 
Brian, you keep talking about that dream of yours about back-porting
features to C++11 but never tell what that technically is supposed
to mean.
 
Currently there are no programming languages named C++11 and C++14.
There is programming language named C++ specified by its standard
ISO/IEC 14882.
 
According to web-page of publisher of that standard ISO
https://www.iso.org/standard/50372.html that C++11 is revision of
"ISO/IEC 14882" standard "ISO/IEC 14882:2011" that has been already
withdrawn as revised by next revision "ISO/IEC 14882:2014" (often called
as C++14) at page https://www.iso.org/standard/64029.html
That revision is published current revision of C++ standard.
 
So what is that "back-port" and how you want it to happen? Do you want
the withdrawal to be undone and the revisions of C++ to be turned into
family of similar programming languages? What is the point of it? What
is the alleged benefit?
Real Troll <Real.Troll@Trolls.com>: Jul 23 05:50PM -0400

On 23/07/2017 22:26, Öö Tiib wrote:
> What is the alleged benefit?
 
He doesn't need to learn anything new!! He might be nearing end of life
so he might as well not bother to learn anything new or anything new
ways of doing things.
woodbrian77@gmail.com: Jul 23 04:12PM -0700

On Sunday, July 23, 2017 at 4:27:08 PM UTC-5, Öö Tiib wrote:
> the withdrawal to be undone and the revisions of C++ to be turned into
> family of similar programming languages? What is the point of it? What
> is the alleged benefit?
 
Perhaps C++ 2017 is to C++ 2011 as C++ 1998 is to C. I don't
know if the technical specifications would need to change.
I would simply like compiler vendors to do this for their
C++ 2011 compilers.
 
The point is to increase the number of people who can use
my software. Otherwise those on "C++ 2017 island" are just
waiting for more people to join them. Lots of people can't
make it to the island, but they would be glad to get some
C++ 2017 features. Recall also my point that C++ 2011 was
both late and immature when it did finally arrive.
 
 
Brian
Ebenezer Enterprises
http:webEbenezer.net
Tim Rentsch <txr@alumni.caltech.edu>: Jul 23 11:27AM -0700

> (as you've discovered). As you well know, in C there's a big difference
> between something that compiles & works in C or C++, and something that
> is actually defined as legal.
 
The type va_list is not an opaque type. It's not a fixed type,
but it is (required to be) a complete object type. What you mean
is that the definition of va_list is implementation dependent
(and thus the '= NULL' default might or might not work, according
to what the type of va_list is).
 
The problem is, as Manfred points out, although va_list must be
a complete object type, it may be an array type. That means
using a default constructor isn't portable either:
 
// Don't do this!
void SetErrorN(
ErrorCode ec, int mc, const char* emf = NULL,
va_list args = va_list() // NO GOOD!
);
 
Instead, a default-valued va_list parameter can be done portably
like this:
 
extern va_list empty_va_list; // must be defined somewhere
 
void SetErrorN(
ErrorCode ec, int mc, const char* emf = NULL,
va_list args = empty_va_list // works portably
);
 
If va_list is not an array type, the default value is copied; if
va_list is an array type, the parameter value is the address of
the global symbol 'empty_va_list'. This pattern works for both
kinds of implementations.
 
Now though there is another problem. Suppose we want to check
the 'args' parameter to see if it's an empty va_list. The
possible array-ness of the va_list type means 'args' might be a
pointer, which is hard to reconcile (ie, in portable code) with
the case where va_list is not an array type. Fortunately there
is a nice way out of this problem, which is to use a reference
type (the default argument expression should also appear in the
function's declaration, if any):
 
extern va_list empty_va_list; // must be defined somewhere
 
void SetErrorN(
ErrorCode ec, int mc, const char* emf = NULL,
va_list& args = empty_va_list // works portably
){
if( &args == &empty_va_list ){
// code here for call with no 'args' argument given
} else {
// code here for call with 'args' argument given
}
}
 
Now that I think about it this pattern could be useful with other
types too (with a 'const' added if need be for value arguments).
In any case one of the last two techniques should be easy to
retrofit into Jacob's environments.
jacobnavia <jacob@jacob.remcomp.fr>: Jul 23 10:30PM +0200

Le 20/07/2017 à 16:52, Manfred a écrit :
 
>> The args parameter *is* passed by value!
> This is not always the case. x86_64 defines it as an array of length 1,
> which is passed by reference (I learned it the hard way)
 
There are two issues here:
 
1: Try to distinguish between args that have the default value and args
that were passed by the calling function.
2: How the actual variable arguments stuff is passed in the x86-64.
 
To be more clearter about issue 2; I have implemented that in the x86-64
in the compiler system lcc-win.
 
Integer args are passed in the integer regs, floating point is passed in
the xmm registers.
 
So you need TWO pointers to each position within the integer registers
array and to the position in the xmm array.
 
Microsoft decided to use just 4 of each register set, and arguments are
always counted, so you just need one pointer. If you want to read
integer/pointer data, you index the int regs array with 4 positions, if
floating point xmm0 to xmm3
 
Gcc however devised a completely different and much more complicated
layout. You need two independent counters, so you can pass really a LOT
of stuff in registers instead of memory.
 
I am working in an arm64 and there it is even worst, with MUCH more
regs. But essentially it is the same: two regs array and the stack as a
backup.
 
In all cases it is a composite object.
 
Of course if there are more arguments than registers you still pass the
rest on the stack, so you have to keep track of that discontinuity too.
 
I generate all that handling inline in asm. And what was a banal bug
easy to fix with just calling the constructor of the stuff (we are in
c++ after all) started a storm of false suppositions, leading me to
believe that c++ has something completely different.
jacobnavia <jacob@jacob.remcomp.fr>: Jul 23 10:58PM +0200

Le 23/07/2017 à 20:27, Tim Rentsch a écrit :
> types too (with a 'const' added if need be for value arguments).
> In any case one of the last two techniques should be easy to
> retrofit into Jacob's environments.
 
Wouldn't it be better if we kept NULL and overload comparisons of
va_list with NULL?
 
That would be much clearer.
 
NULL as a default value should be OK with nicely designed classes isn't it?
 
I would prefer to read
if (args == NULL)
rather than
if (&args == &empty_list)
 
Where we have to create an artificial object to replace NULL, and figure
out a common name for this object. "empty_va_list" is clear, but other
people could name it "no_args", and other va_list_default, or... you see?
 
NULL is already there for that purpose, just let's keep using that.
 
With operator overloading we can pass the overhead to compile time and
the code will work in any implementation, with 32 bit pointers or with
64 bit register arrays.
 
It shouldn't be implementation defined but language defined. We have a
list of arguments of maybe different types and sizes, and a decoder
argument, where the types are described in the context of the va_args
function.
 
This arguments are numbered by an integer index (first, second, etc). We
start, read the next one, etc, within the va_args function. Each next
operation returns a copy of the value (args are passed by value, i.e. by
copying).
Manfred <noname@invalid.add>: Jul 24 12:12AM +0200

On 07/23/2017 10:30 PM, jacobnavia wrote:
 
> 1: Try to distinguish between args that have the default value and args
> that were passed by the calling function.
> 2: How the actual variable arguments stuff is passed in the x86-64.
 
I am not sure how much I can help, but I am trying to start with a
couple of preliminary considerations here.
- va_list in C++ is no better, no worst than it is in C. It has been
inherited as-is by Bjarne as part of C compatibility. Its usage is also
the same as in C (I think the constructor does not really add much, as
long as you can't have additional operations)
The official way introduced to handle variable arguments in C++ is
variadic templates. This is definitely more robust than va_list, but
unfortunately it is not compatible at all with it (i.e. it requires
substantial code rewriting).
 
- The way I see it, va_list is meant to be used as an opaque type, only
to be accessed via va_start, va_arg, va_end and va_copy (where
available) - I mean, other than that you give up with portability, I
believe.
 
As far as I can understand, the problem you are having right now arises
for not having handled va_list as opaque in the first place, and so
changing achitecture resulted in the current problem.
This is to say that, possibly, one hint would be to try to solve the
portability problem where it arises, i.e. get rid of the = default
void SetErrorN(ErrorCode ec, int mc,
const char* emf = NULL, va_list args /* = NULL */);
 
This breaks the code as it is now, but it makes it possible to identify
where such default is used, and replace it instead with a properly
initialized va_list - via va_start. I don't know how much feasible this
is in your case.
You would still be left with the doubt whether args is empty of not, but
this is in fact how va_list works as per standard, correct me if I am
wrong (it is one of its limitations). In C (as well as in C++) it is the
responsibility of the programmer to ensure that the callee does not
exceed the amount of arguments provided.
If this was not done in the beginning, it could be an additional problem.
 
If this is not possible, the second alternative would probably be using
va_list*, and use address comparison as identity check, or you can use a
NULL va_list* when empty.
cppreference.com says: "It is legal to pass a pointer to a va_list
object to another function and then use that object after the function
returns."
http://en.cppreference.com/w/cpp/utility/variadic/va_list
 
I would not go down the path of issue 2. It looks that you have
considerably more experience than I have, but even if you solve entirely
issue 2, you get to a solution that is not portable, so the problem is
likely to show up again with the next architecture.
 
Hope this helps..
 
 
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jul 24 12:29AM +0200

On 23.07.2017 20:27, Tim Rentsch wrote:
> ErrorCode ec, int mc, const char* emf = NULL,
> va_list args = empty_va_list // works portably
> );
 
void foo( A args = A{} )
{}
 
 
- Alf
Vir Campestris <vir.campestris@invalid.invalid>: Jul 23 09:41PM +0100

On 20/07/2017 22:54, Öö Tiib wrote:
> }
 
> What it outputs to console?
> Hope you start to get the idea why copying streams does not make sense.
 
cout isn't a stringstream, it's a file. A funny file, but still a file.
 
When I write something into a stringstream it is stored in its internal
buffer until I get around to pulling it out. A copy I'd expect to have
its own buffer, containing the same data.
 
You can't do that with a file.
 
So to me it makes perfect sense not to be able to copy cout - or any
other file based stream - but to be able to copy stringstream.
 
Andy
"Öö Tiib" <ootiib@hot.ee>: Jul 23 03:24PM -0700

On Sunday, 23 July 2017 23:42:01 UTC+3, Vir Campestris wrote:
 
> > What it outputs to console?
> > Hope you start to get the idea why copying streams does not make sense.
 
> cout isn't a stringstream, it's a file. A funny file, but still a file.
 
In what sense of "file"?
The std::cout is ostream of unspecified nature and usually it is
directed to standard output of program (that might be sometimes piped into
a file). However I posted code above how cout can easily go into buffer
of stringsteam (and to share it) as well.
 
 
> You can't do that with a file.
 
> So to me it makes perfect sense not to be able to copy cout - or any
> other file based stream - but to be able to copy stringstream.
 
I don't understand how it makes sense to copy a stream but may be in
your problem domain it somehow makes sense. Still std::strinstream
copy constructor is "= delete;" so you can't anyway use it.
 
If you want a stream with copied buffer content then you can make one.
It is not too hard:
 
std::stringstream ss_2(ss_1.str(), std::ios_base::out|std::ios_base::ate);
 
Done.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 22 05:32PM -0700

God invites you to be a part of His eternal Kingdom. He
wants you to be with Him where He is in all eternity in the
paradise of Heaven.
 
https://www.youtube.com/watch?v=wIOI9quJ0Pg
 
He calls out to you. Can you hear Him? Answer Him and receive
eternal life, in Heaven, in peace and love, as God intended before
sin entered in and destroyed everything.
 
He will forgive you today, take away your shame, wipe the slate
clean, renew all things, and begin the process of healing and guiding
you from this day forward.
 
Thank you,
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 22 09:42PM -0700

Who is Jesus? What's He like? The Gospel of John was the last
gospel written, and possibly the last book of the Bible written. It
teaches us the love of God, and how we must be born again to see
the Kingdom of Heaven.
 
See what Jesus was like in this 3hr movie, as it goes through the
whole gospel of John verse by verse. Learn who Jesus is, and why
He came to the Earth:
 
https://www.youtube.com/watch?v=2mgUPt2KI08
 
Thank you,
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 22 11:10PM -0700

Watch a powerful movie on Netflix showing what Jesus went through to
give us freedom from sin, and eternal life. It cost Jesus to buy our
freedom. It is free to receive only because He paid the heavy price.
 
Warning: Rated R for blood, gore, and violence
 
"The Passion of the Christ" by Mel Gibson:
https://www.netflix.com/title/60031422
 
The word "passion" here refers to what Jesus went through in His last
days before going to the cross.
 
Thank you,
Rick C. Hodgin
"Chris M. Thomasson" <invalid@invalid.invalid>: Jul 22 05:12PM -0700

On 7/22/2017 3:17 PM, Rick C. Hodgin wrote:
> one you need to give account of. And when you do, you will also be compelled
> to report how many times I tried to reach you with the gospel message.
 
> You will burn in eternal Hellfire in agony
 
That's mean. Well, perhaps, just perhaps, we will all see you there in
the fire. The reason you might be there is because of all the people you
scared away from the faith. You are pretty hardcore.
 
;^o
 
 
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)