Sunday, February 4, 2018

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

"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Feb 04 11:29PM

There are grown adults who actually believe that two penguins walked all
the way from Antarctica to the Middle East to get into an ark...
 
Actually they did the only problem was the penguins were gay.
 
--
 
Thank you,
Rick C. Hodgin
Marcel Mueller <news.5.maazl@spamgourmet.org>: Feb 04 07:47PM +0100

On 04.02.18 18.01, David Brown wrote:
 
> It does not need any ABI calls when you have named arguments. The
> compiler has the original declaration, which gives the order required
> for the definition (which must match).
 
You cannot define two functions with the same signature that differ only
in the parameter names. Their mangled symbol names would be the same.
 
 
Marcel
"Öö Tiib" <ootiib@hot.ee>: Feb 04 11:04AM -0800

On Sunday, 4 February 2018 20:47:14 UTC+2, Marcel Mueller wrote:
> > for the definition (which must match).
 
> You cannot define two functions with the same signature that differ only
> in the parameter names. Their mangled symbol names would be the same.
 
Name mangling isn't regulated by any standard. What is or isn't
part of function's signature is. But standards will change with
time.
Richard Damon <Richard@Damon-Family.org>: Feb 04 02:28PM -0500

On 2/4/18 2:04 PM, Öö Tiib wrote:
 
> Name mangling isn't regulated by any standard. What is or isn't
> part of function's signature is. But standards will change with
> time.
 
Name mangling is normally specified as part of the C++ ABI, as that is
required to get cross tool compatibility.
David Brown <david.brown@hesbynett.no>: Feb 04 08:53PM +0100

On 04/02/18 19:47, Marcel Mueller wrote:
>> for the definition (which must match).
 
> You cannot define two functions with the same signature that differ only
> in the parameter names. Their mangled symbol names would be the same.
 
I know - and I would not want to. Named arguments would mean there
would be even fewer cases where you might be tempted to have the same
signature and different semantics - especially if you allowed a way to
say that the function /required/ named arguments (so that you could not
write "substring(1, 4)" but would be required to write either
"substring(.start = 1, .length = 4)" or "substring(.start = 1, .end =
4)". You would need to have such requirements added into the name
mangling - but that would be fine to implement, and not unprecedented
(it's like adding noexcept to the function's type in C++17).
"Öö Tiib" <ootiib@hot.ee>: Feb 04 12:09PM -0800

On Sunday, 4 February 2018 21:28:55 UTC+2, Richard Damon wrote:
> > time.
 
> Name mangling is normally specified as part of the C++ ABI, as that is
> required to get cross tool compatibility.
 
I did not try to say that name mangling does not exist at all but that
it is implementation-specific. In general, C++ ABI is so
implementation-specific that two pieces of compiled C++ can be linked
together only
* when those were compiled with exactly same version of C++ compiler
with same compiling options
* or when every symbol exchanged between those is extern "C".
 
Yes, some platform vendors who want to make their own programming
languages compatible with C++ (like Apple or Oracle) do fair attempts
to define C++ ABI platform-widely but that is more exception than
actual reality and also the results of their attempts are not
reliable in practice.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Feb 04 08:35PM

On Sun, 4 Feb 2018 12:09:03 -0800 (PST)
Öö Tiib <ootiib@hot.ee> wrote:
[snip]
> to define C++ ABI platform-widely but that is more exception than
> actual reality and also the results of their attempts are not
> reliable in practice.
 
The ABI is implementation specific, although clang has adopted the same
conventions as gcc. But I do not think the rest is as bleak as you
suggest.
 
What you say about that may be true of Visual C++ but not of gcc and
clang. They try hard not to break ABI, and the last ABI break, which
was in the standard library and not concerned with the
compiler/mangling conventions themselves, was forced on them by changes
required by C++11. And even then there is a compiler option to use the
old (non-C++11 conforming) ABI (as I recall this is concerned with
string copy on write and O(1) complexity of std::list::size()).
 
Leaving aside the C++11/C++98 option I have mentioned, with gcc and
clang in practice you can reliably link with system provided C++
libraries irrespective of the flags you apply to your project, provided
you do not go out of your way to create incompatibility.
 
Chris
Robert Wessel <robertwessel2@yahoo.com>: Feb 04 02:57PM -0600

On Sun, 4 Feb 2018 14:28:41 -0500, Richard Damon
>> time.
 
>Name mangling is normally specified as part of the C++ ABI, as that is
>required to get cross tool compatibility.
 
 
So the ABI would need an update. Adding a new primitive type to C++
would require the same. FWIW, most of the name mangling scheme appear
to have plenty of currently undefined sequences which would be used
for some define data needing encoding. Such a thing might well be
backwards compatible as well. Yes, your older compiler won't be able
to call the function with the new signature features, but the old
versions will still be fine.
Richard Damon <Richard@Damon-Family.org>: Feb 04 04:38PM -0500

On 2/4/18 3:57 PM, Robert Wessel wrote:
> backwards compatible as well. Yes, your older compiler won't be able
> to call the function with the new signature features, but the old
> versions will still be fine.
 
A non-backwards compatible update. An important distinction.
 
If a new type is added, then a mangling code could be added, and all
previous libraries that of course didn't use that type, would still be
usable.
 
For the standard to now allow overloading based on parameter names, then
the mangling for existing (compiled) code would need to change, so
existing compiled version are effectively unusable. This is a very high
cost hurdle to consider for such a language change.
"Öö Tiib" <ootiib@hot.ee>: Feb 04 01:51PM -0800

On Sunday, 4 February 2018 22:36:14 UTC+2, Chris Vine wrote:
 
> The ABI is implementation specific, although clang has adopted the same
> conventions as gcc. But I do not think the rest is as bleak as you
> suggest.
 
Experiences differ.
 
> clang in practice you can reliably link with system provided C++
> libraries irrespective of the flags you apply to your project, provided
> you do not go out of your way to create incompatibility.
 
I did not mind some awful ideas like trying to mix different boost
versions or something. I also focus in practice. It seems that linking
with GCC 4.9 (2014+) some binaries compiled with GCC 5 (2015+) do fail.
 
I do not doubt there are great guys working on GCC who do good job but
the C++ is not easy beast to tame. So typical approach is not to use
too fresh compilers for real production but let these mature a bit (for
example for two years). So usage of GCC 4.9.4(2016) with GCC 5.5(2017)
in mix feels more plausible than usage of 6 or 7 series (so I don't
know how ABI compatible those are).
Robert Wessel <robertwessel2@yahoo.com>: Feb 04 04:07PM -0600

On Sun, 4 Feb 2018 16:38:55 -0500, Richard Damon
>the mangling for existing (compiled) code would need to change, so
>existing compiled version are effectively unusable. This is a very high
>cost hurdle to consider for such a language change.
 
 
I don't follow. Unless a function had a signature that included named
parameters, its mangled name would not change. Any previously
compiled code would, by definition, be unchanged.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Feb 04 10:15PM

On Sun, 4 Feb 2018 13:51:29 -0800 (PST)
> (for example for two years). So usage of GCC 4.9.4(2016) with GCC
> 5.5(2017) in mix feels more plausible than usage of 6 or 7 series (so
> I don't know how ABI compatible those are).
 
gcc-4.9 and gcc-5.1 are by default incompatible in the standard library
with respect to std::string and std::list, as I mentioned. gcc-5 broke
ABI in its standard library to conform with C++11. You can however use
the old ABI in your project with the _GLIBCXX_USE_CXX11_ABI=0
environmental variable. If you set that correctly, gcc-4 and gcc-5
code is compatible.
 
As I mentioned, I do not think you will find any other
incompatibilities between gcc-3.2 onwards and the current gcc-7.3.
 
If you are interested in the ABI break, there is more here:
https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html
 
Chris
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Feb 04 10:21PM

On Sun, 4 Feb 2018 22:15:25 +0000
> incompatibilities between gcc-3.2 onwards and the current gcc-7.3.
 
> If you are interested in the ABI break, there is more here:
> https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html
 
Perhaps I should add that my working version of gcc in my build system
is compiled with the --with-default-libstdcxx-abi=c++98 option, so to
use the new ABI a project needs explicitly to opt in with the
_GLIBCXX_USE_CXX11_ABI=1 environmental variable[1]. This means any
binaries it provides are by default compatible with everything from
gcc-3.2 onwards.
 
Chris
 
[1] By default, gcc provides both ABIs and will pick the right one for
any particular project depending on how the _GLIBCXX_USE_CXX11_ABI
environmental variable is set.
Richard Damon <Richard@Damon-Family.org>: Feb 04 05:49PM -0500

On 2/4/18 5:07 PM, Robert Wessel wrote:
 
> I don't follow. Unless a function had a signature that included named
> parameters, its mangled name would not change. Any previously
> compiled code would, by definition, be unchanged.
 
Currently, the presence or absence of parameter names in the prototype
doesn't matter, and in most cases in my experience they are there (they
help greatly with documenting the code in the header). This means that
new code compiled with new mangling rules would see that prototype as
specifying named parameters and thus mangle the call, but the previous
compiled library wouldn't have used that mangling (since might not have
existed at the time).
 
If some new syntax was invented to require some change in the prototype
so it wouldn't have been legal previously, then it could be added, but
that wouldn't be the examples shown.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Feb 05 12:12AM +0100

On 2/4/2018 1:44 PM, Marcel Mueller wrote:
 
> No, it is still 2^N as each argument can either exist or not. O(N^2) is
> typical for pair correlations.
> Or are you talking about a combination of overloads an default arguments?
 
I'm talking about the total number of formal argument specifications in
all overloads.
 
E.g.
 
foo()
foo( int )
foo( int, int )
foo( int, int, int )
 
to emulate
 
foo( int = 1, int = 2, int = 3 )
 
So the overloads have 0+1+2+3 = (4*3)/2 = 6 formal argument
specifications, and more generally (N+1)*N/2 = 0.5*(N^2 + N). Or in
short O(N^2). Sorry for skipping the math in the earlier posting!
 
Cheers!,
 
- Alf
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Feb 04 08:08PM

Chris,
 
If you want to be as "reliable" and as "grounded on life directions" as
Rick, not to mention acquiring his stilted way of writing and peculiar
vocabulary, then carry on. But the better way of doing that would be
to take your off topic posting away from this newsgroup and discuss it
further with him by email, where it belongs.
 
On Sun, 4 Feb 2018 09:18:00 -0800 (PST)
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Feb 04 02:51PM -0800

On 2/4/2018 12:08 PM, Chris Vine wrote:
> vocabulary, then carry on. But the better way of doing that would be
> to take your off topic posting away from this newsgroup and discuss it
> further with him by email, where it belongs.
 
He did not want to converse with me anymore via email because I used the
word damn.
 
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Feb 04 11:07PM

On Sun, 4 Feb 2018 14:51:52 -0800
> > belongs.
 
> He did not want to converse with me anymore via email because I used
> the word damn.
 
Oh dear. A lost soul due to his attitude. Yea verily, surely he shall
burn in hell for eternity on account of that? "Damn" isn't even
profanity on this side of the Atlantic.
 
I am a convinced Christian; but if you are faced with some nutjob who
asks you to believe that Adam and Eve really existed historically and
are the authors of original sin in an actual sense for which we are
vicariously condemned to be tortured in hell for eternity, and that the
earth is 6,000 years old in contradiction of the overwhelming scientific
evidence to the contrary, or that man did not evolve by natural
selection contrary to the overwhelming scientific evidence the contrary
(there is no doubt about the fact of evolution, only its means), then
you are well advised to steer very wide of them.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Feb 04 05:49PM

If you are doing what you are doing for reward and punishment then it
isn't really morality.
 
--
 
Thank you,
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Feb 04 12:59PM -0500

On 2/4/2018 12:49 PM, Rick C. Hodgin wrote:
> If you are doing what you are doing...
 
 
I, the real Rick C. Hodgin, did not write this post.
 
Please examine the headers to see that there is someone usurping my
identity (and without my permission). I post from Eternal September
and Google Groups only.
 
--
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Feb 04 12:59PM -0500

On 2/4/2018 12:28 PM, Rick C. Hodgin wrote:
> "No one of illegitimate birth ...
 
I, the real Rick C. Hodgin, did not write this post.
 
Please examine the headers to see that there is someone usurping my
identity (and without my permission). I post from Eternal September
and Google Groups only.
 
--
Rick C. Hodgin
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)