Thursday, August 20, 2020

Digest for comp.lang.c++@googlegroups.com - 8 updates in 4 topics

Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Aug 20 11:57PM +0100

Dark theme? All the dagnabbiting colour themes! https://www.youtube.com/watch?v=eIpcqNcoK60&feature=youtu.be
 
(neoGFX demo)
 
/Flibble
 
--
"Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin
 
"You won't burn in hell. But be nice anyway." – Ricky Gervais
 
"I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais
 
"Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say."
wyniijj@gmail.com: Aug 20 12:09PM -0700

Bo Persson於 2020年8月21日星期五 UTC+8上午1時08分25秒寫道：
> not everything involved uses type T. But that would then be in the code
> we haven't seen.
 
> Bo Persson
 
I am implementing a double-sized integer. This is the closest simplified version
All the relevant members I can think of are shown in DxInt, g++ does not
complain others function members. Stll can't replicate the error.
 
test2.cpp may be correct. but i need time to verify this, meanwhile, may you
people provides improvements of such implement, thanks.
 
//-------------------------------------------------
// test2.cpp
#include <iostream>
 
using namespace std;
 
template<typename T> class DxInt;
 
typedef uint32_t T;
typedef uint64_t TT;
template<> class DxInt<T> {
 
T arr[2];
 
public:
DxInt() { *this=0; };
DxInt(const DxInt& s) { *this=s; };
DxInt(TT v) { *this=v; };
 
inline const T& lo() const { return arr[0]; };
inline T& lo() { return arr[0]; };
inline const T& hi() const { return arr[1]; };
inline T& hi() { return arr[1]; };
 
inline DxInt& operator=(TT rhs) {
//*this=rhs; // gdb halts at this line. seems a recusive call
// nothing to do with "cannot bind non-const lvalue
// reference of type" or about "returning reference to
// temporary"
static_cast<TT&>(*this)=rhs;
return *this;
};
 
operator TT& () { return reinterpret_cast<TT&>(*this); };
operator const TT& () const { return reinterpret_cast<const TT&>(*this); };
};
 
int main()
{
DxInt<T> a;
a.lo()=1234;
a.hi()=9;
a=2+a;
--a;
cout << "a.lo()=" << a.lo() << ", a.hi()=" << a.hi() << endl;
 
DxInt<T> b(a);
cout << "b.lo()=" << b.lo() << ", b.hi()=" << b.hi() << endl;
 
const DxInt<T> c(100);
cout << "c.lo()=" << c.lo() << ", c.hi()=" << c.hi() << endl;
 
return 0;
};
 
//-----------------
 
[]$ g++ test2.cpp -O2
[]$ ./a.out
a.lo()=1235, a.hi()=9
b.lo()=1235, b.hi()=9
c.lo()=100, c.hi()=0
James Kuyper <jameskuyper@alumni.caltech.edu>: Aug 20 04:23PM -0400

On 8/20/20 3:09 PM, wyniijj@gmail.com wrote:
...
> I am implementing a double-sized integer. This is the closest simplified version
> All the relevant members I can think of are shown in DxInt, g++ does not
When someone has a problem they don't understand, and posts only those
parts of the program that they think are relevant to the problem,
empirically it's very likely to be the case that the problem is in the
part they left out.
 
Start with the version of the program that fails, and then simplify it
one step at a time, testing after each removal to make sure that it
still fails. If removing a part makes it work, put that part back in.
Then stop and think very carefully about what you just did - you didn't
expect that removing that part would make a difference, but it did. That
can be a very useful clue toward figuring out what the real problem is.
 
When you can't find anything more that can be removed, and the program
still demonstrates the problem you're asking about, that's the time to
post the code here.
 
> complain others function members. Stll can't replicate the error.
 
You have still failed to post the program that actually fails. I can
give you some design advice about this program, but that's about it.
 
> inline T& lo() { return arr[0]; };
> inline const T& hi() const { return arr[1]; };
> inline T& hi() { return arr[1]; };
 
Keep in mind that, depending upon the target architecture, your lo()
function might return the high-order half of the integer. Middle-endian
machines are much rarer that either little-endian or big-endian
machines, but I've heard that there's still some in use - on such
machines, lo() will return something that is neither the hi nor the low
order half of the value.
 
I'd recommend re-naming these functions so that they portably describe
what they're actually doing: for instance, first_half() and
second_half(). If someone makes the mistake of thinking that
first_half() is guaranteed to contain the low-order bits, that will be
their mistake, not yours.
 
> inline DxInt& operator=(TT rhs) {
> //*this=rhs; // gdb halts at this line. seems a recusive call
 
It certainly is! I'm curious - why didn't you anticipate that it to be
recursive?
 
> // reference of type" or about "returning reference to
> // temporary"
> static_cast<TT&>(*this)=rhs;
 
The best way to do this would be to declare a union containing a
uint64_t object and an array of two uint32_t objects. Assign rhs to the
uint64_t object.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Aug 20 09:30PM

On Thu, 2020-08-20, wyniijj@gmail.com wrote:
...
> []$ g++ test.cpp
 
When you're fighting the compiler, it's better to ask it to produce as
detailed warnings as possible:
 
[]$ g++ -std=c++11 -Wall -Wextra -pedantic test.cpp
 
And optimize and support debugging:
 
[]$ g++ -std=c++11 -Wall -Wextra -pedantic -O2 -g test.cpp
 
There are many more warnings you can enable, but these are the ones I
normally use myself.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Bo Persson <bo@bo-persson.se>: Aug 20 09:09PM +0200

On 2020-08-20 at 20:57, RM wrote:
> #10 0x0000000000408382 in obfuscator::obfuscator (this=0x7ffc6babeb70)
>     at src/obfuscator.hpp:79
> #11 0x000000000040786b in main (argc=6, argv=0x7ffc6babf0b8)
 
Apparently the bad call comes from here:
 
#10 0x0000000000408382 in obfuscator::obfuscator (this=0x7ffc6babeb70)
at src/obfuscator.hpp:79
 
So which line is number 79?
 
 
 
Bo Persson
Mike Terry <news.dead.person.stones@darjeeling.plus.com>: Aug 20 10:12PM +0100

On 20/08/2020 20:09, Bo Persson wrote:
 
> Bo Persson
 
I'm wondering what's going on with the strtoupper(). Bad return value
(reference to defunct stack frame object or something) perhaps? Anyway,
OP would do well to learn to use a debugger to step through the failing
constructor, examining variables at the failure point...
 
Mike.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Aug 20 02:26PM -0700

On 8/20/2020 2:12 PM, Mike Terry wrote:
> (reference to defunct stack frame object or something) perhaps?  Anyway,
> OP would do well to learn to use a debugger to step through the failing
> constructor, examining variables at the failure point...
 
Agreed. A nice debugger and the OP's careful eye should help.
Vir Campestris <vir.campestris@invalid.invalid>: Aug 20 10:10PM +0100

On 17/08/2020 18:35, Juha Nieminen wrote:
> 20 years ago. This year.
 
> It is perfectly possible. You just have to watch for that 32 kB
> limit.
 
I deliberately quoted part of his message: his code uses templates.
 
It doesn't mean it _is_ big and complex, but it makes it a whole lot
more likely, and that is what I was concerned about.
 
(FWIW I've written boot sector code for IBM machines. You have 512 bytes
for the code and all the data. And the smallest amount of RAM I've ever
had to work with was zero. That's right, none at all. POST can't assume
the RAM will work, and has to be able to complain when it doesn't!)
 
Andy
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)