Monday, March 11, 2019

Digest for comp.lang.c++@googlegroups.com - 13 updates in 6 topics

Bonita Montero <Bonita.Montero@gmail.com>: Mar 10 07:49PM +0100

Check the code of an AVC-tree or a red-black-tree-implementation in
an easier language like Java and try to rewrite the code in C++ as
a generic implementation with templates.
"Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Mar 11 01:28PM -0700

On 3/9/2019 7:13 PM, Jeremy Murphy wrote:
 
> Thanks, and I'll post a link to the presentation after it happens.
 
> Cheers.
 
> Jeremy
 
Fwiw, the first binary tree I ever experienced was from an old Book
about Basic for my Atari. It used an 1d array to hold a binary tree. I
cannot remember the name of he book, but I do remember it was spiral
bound. Damn. That was fun: I was just a little kid. :^)
"Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Mar 11 01:23PM -0700

On 3/11/2019 1:13 AM, Bonita Montero wrote:
> the counter before incrementing. Sometimes you simply can't predict
> how many threads will lock the mutex, especially with resoursive
> read-locking.
 
Fair enough. 0xFFFF readers may bit a little bit to small? My algorihtm
allows for LONG_MAX readers. So, the chances of breaking my work's rules
are much harder than breaking 0xFFFF...
ram@zedat.fu-berlin.de (Stefan Ram): Mar 11 07:31PM

> t1 ={ &t0, 1, &t2 }, t4 ={ 0, 4, 0 },
>t0 ={ 0, 0, 0 }, t2 ={ 0, 2, 0 };
 
>int main( void ){ print( &t3 ); putchar( '\n' ); return EXIT_SUCCESS; }
 
An attempt to write a similar program in C++
(it uses a somewhat different kind of binary trees):
 
main.cpp
 
#include <boost/variant.hpp>
#include <initializer_list>
#include <iostream>
#include <ostream>
#include <utility> /* ::std::pair */
 
typedef boost::make_recursive_variant
< int,
::std::pair
< boost::recursive_variant_,
boost::recursive_variant_ >>::type
entry;
 
typedef std::pair< entry, entry > tree;
 
struct serializer
{
void operator()( int const i )const { ::std::cout << i; }
 
void operator()( entry const & v )const
{ return ::boost::apply_visitor( *this, v ); }
 
void operator()( tree const & tree) const
{ ::std::cout << "(";
operator()( tree.first );
operator()( tree.second );
::std::cout << ")"; }};
 
int main() { serializer{}( tree { 1, tree { 2, 3 }} ); }
 
transcript
 
(1(23))
 
With regard to the OP's question: I did not learn it,
I am still learning it.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Mar 11 11:01AM -0700

> void`. And it's a literal syntax, where the keyword `void` could just
> as well have been `__gah__` or say `noargs` or whatever, so you can't,
> say, define `using X = void;` and write `int main( X )`,
 
using X = void;
 
int
main( X ){
return 0;
}
 
Compiles fine here.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Mar 11 07:21PM +0100

On 11.03.2019 19:01, Tim Rentsch wrote:
> return 0;
> }
 
> Compiles fine here.
 
Interesting. Was I wrong that it's a literal syntax, or are both g++ and
Visual C++ wrong to accept the code?
 
 
Cheers!,
 
- Alf
Tim Rentsch <tr.17687@z991.linuxsc.com>: Mar 11 10:51AM -0700

> standards just /permitted/ it.
 
> Among other things this lets a function return a value of a
> type that can't be copied or moved.
 
I am still something of a novice with respect to copy elision.
Can you give an example of a function definition and a call
to the function where the return type cannot be moved or
copied but the call still works because of copy elision?
 
> obfuscated, it has to do with "materialization" of rvalues. I
> can't say I entirely understand it. But then, that's because I
> refuse to use time on it. :)
 
Can you say how materialization complicates understanding copy
elision? Looking at the C++ standard, AFAICS copy elision and
temporary materialization don't interact in any significant way.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Mar 11 10:53AM -0700

Paavo Helde <myfirstname@osa.pri.ee> writes:
 
[...]
 
> See
> e.g. http://thbecker.net/articles/rvalue_references/section_01.html
> for more explanations.
 
I found this article to be an excellent tutorial. Thank you
for posting this.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Mar 11 07:14PM +0100

On 11.03.2019 18:51, Tim Rentsch wrote:
> Can you give an example of a function definition and a call
> to the function where the return type cannot be moved or
> copied but the call still works because of copy elision?
 
-----------------------------------------------------------------------
struct Result
{
int m_x;
 
explicit Result( const int x ): m_x( x ) {}
 
Result( const Result& ) = delete;
Result( Result&& ) = delete;
};
 
auto foo() -> Result { return Result( 42 ); }
 
#include <stdlib.h> // EXIT_...
auto main()
-> int
{ return foo().m_x == 42? EXIT_SUCCESS : EXIT_FAILURE; }
-----------------------------------------------------------------------
 
Compiling with MinGW g++ 8.2.0:
 
 
[H:\forums\clc++\041 copy elision]
> g++ main.cpp -std=c++14
main.cpp: In function 'Result foo()':
main.cpp:11:42: error: use of deleted function 'Result::Result(Result&&)'
auto foo() -> Result { return Result( 42 ); }
^
main.cpp:8:5: note: declared here
Result( Result&& ) = delete;
^~~~~~
 
[H:\forums\clc++\041 copy elision]
> g++ main.cpp -std=c++17
 
[H:\forums\clc++\041 copy elision]
> _
 
 
Compiling with Visual C++ 2017:
 
 
[H:\forums\clc++\041 copy elision]
> cl main.cpp /std:c++14
main.cpp
main.cpp(11): error C2280: 'Result::Result(Result &&)': attempting to
reference a deleted function
main.cpp(8): note: see declaration of 'Result::Result'
main.cpp(8): note: 'Result::Result(Result &&)': function was explicitly
deleted
 
[H:\forums\clc++\041 copy elision]
> cl main.cpp /std:c++17
main.cpp
 
[H:\forums\clc++\041 copy elision]
 
> Can you say how materialization complicates understanding copy
> elision? Looking at the C++ standard, AFAICS copy elision and
> temporary materialization don't interact in any significant way.
 
Oh, that's why I wrote that it seems almost intentionally obfuscated.
 
Sorry it's late in the day for me, otherwise I'd probably try to delve
into it.
 
It's VERY far from clear.
 
 
Cheers!,
 
- Alf
Richard Damon <Richard@Damon-Family.org>: Mar 09 03:15PM -0500

On 3/9/19 2:20 PM, Manfred wrote:
> the code that is 64 or 32-bit specific.
> Depending on the case, the performance hit could be acceptable, compared
> to the hassle of cross-compiling without the ability of native testing.
 
I didn't think windows handled 64-to-32 bit thunking, at least not in
general. The big issue in trying to do this is that pointers in any
structure will not be compatible, being different sizes, and most
objects in the 64 bit memory space will be non-accessible to the 32 bit
code.
 
A 64 bit program might be able to take special steps to be able to call
a 32 bit library (doing some special system calls to get buffers in the
32 bir space, and special types/headers that make things the right
size), but is it not going to be transparent.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Mar 09 11:26AM +0100

On 09.03.2019 10:40, fir wrote:
>> and debugging it in 64-bit environment.
 
> tnx for answer, maybe you could yet me some more
 
> this is simple plugin for c++ app, (as i just try to make it work it may be extremally simple like one simple function exported, i may also write it in c (and in fact wrote it in c when tested as i knewed on this mangling and problems)
 
Use COM.
 
[snip]
 
 
Cheers!,
 
- Alf
Paavo Helde <myfirstname@osa.pri.ee>: Mar 09 08:58AM +0200

On 9.03.2019 3:30, fir wrote:
 
> i found some hint i could use -m64 option
> but the created dll dont work when linked to that 64 bit application (it like silently crashes from what i heard, i do not link it only send that dll to someone)
 
> is there an option to make it work? does maybe someone know why it crashes?
 
C++ does not have standardized ABI (binary interface), so for a C++ DLL
to work in another C++ program the both have to be compiled with the
same compiler and with the same relevant compiler options and macro
definitions.
 
Another common reason for the crashes are 64-bit specific bugs in the
code. I can well imagine your code is littered with unsafe casts from
void* pointers to int and back. Also other dormant bugs may get exposed.
 
 
> [sependency walker seem to shows something:
> dependency of my dll on msvcrt.dll and kernel32.dll (eben though i dont use none explicitely in that dll) .. if this -m64 option targets the output on 64bit windows shouldnt it to be dependant on some 64 bit verions of it (i dont know if it poinnts 32 bit or 64 bit ones, are there same named 64 bit versions of that think on 64 bit windows?)
 
The Windows dll-s have the same names in 64-bit than in 32 and reside in
the same folders. Hence, there is a new 64-bit DLL called kernel32.dll
which resides in a folder having 32 in its name, C:\Windows\System32.
For balance, the old 32-bit kernel32.dll resides in a folder having 64
in its name (C:\Windows\SysWOW64). However, this is not something which
you should worry about, normally this is all resolved automatically.
 
 
> how to repair this problem?
 
No way. You cannot port a DLL to 64-bit and deliver it without testing
and debugging it in 64-bit environment.
Christian Gollwitzer <auriocus@gmx.de>: Mar 09 01:53PM +0100

Am 09.03.19 um 10:40 schrieb fir:
 
>> No way. You cannot port a DLL to 64-bit and deliver it without testing
>> and debugging it in 64-bit environment.
 
> tnx for answer, maybe you could yet me some more
 
As Paavo said, you'll need to get hold of a 64-bit system and test for
yourself, catch the crashes in a debugger and find out what is wrong.
 
If it helps, MS provides a number of VM images for testing purposes. The
development VMs contain Windows and the most recent compiler, but they
are currently unavailable (until the next update for Win10):
https://developer.microsoft.com/en-us/windows/downloads/virtual-machines
 
You could also use the testing VMs for internet browsers:
https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/
 
Not sure, if your use case falls under the license, you'll have to check
izt for yourself. Technically, you can debug your program there.
 
A classic 64bit issue is that on Windows 64 bit, both int and long are
32 bit only, so offsets into memory do not find into either of them -
for that you'll replace them by ptrdiff_t, which has the correct size
for both platforms. These problems can hardly be found unless you debug
it in 64 bit.
 
Christian
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)