Wednesday, November 30, 2016

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

xerofoify <xerofoify@gmail.com>: Nov 30 08:56AM -0800

//Takes const reference of type T and inserts it into tree, returns iterator to inserted Node
iterator insert(const T& data){
if (root_ == nullptr){
root_ = new Node(data);
root_->leftThread = true;
root_->rightThread = false;
return iterator(root_);
}
Node* p = root_;
while(p) {
if (p->data_ < data){
if (p->leftThread)
break;
p = p->right_;
}
else if (p->data_ > data){
if (p->rightThread)
break;
p = p->left_;
}
}
Node* tmp = new Node();
tmp->data_ = data;
tmp->rightThread = tmp->leftThread = true;
if (p->data_ < data){
tmp->right_ = p->right_;
tmp->left_ = p;
p->right_ = tmp;
p->rightThread = false;
return iterator(p->right_);
}
else{
tmp->right_ = p;
tmp->left_ = p->left_;
p->left_ = tmp;
p->leftThread = false;
return iterator(p->left_);
}

}
I was wondering how to rewrite the insert part to avoid a nullptr deference and insert correctly as currently I can't see a way.
"Öö Tiib" <ootiib@hot.ee>: Nov 30 10:34AM -0800

On Wednesday, 30 November 2016 18:56:33 UTC+2, xerofoify wrote:
 
> I was wondering how to rewrite the insert part to avoid a nullptr
> deference and insert correctly as currently I can't see a way.
 
Who knows. Your threaded three algorithm seems badly broken. For
example lets take from very first lines of insert:
 
if (root_ == nullptr) // so lets say the three is empty and go into if
{
root_ = new Node(data);
// here root_->data_ is data
// root_->left_ and root_->right_ are nullptr
// and the values of leftThread and rightThread are uninitialized
// because Node has such a dreaded constructor.
 
root_->leftThread = true;
// huh? to where that nullptr supposedly threads?
 
root_->rightThread = false;
// but that nullptr does not thread anywhere?
 
return iterator(root_);
}
 
So on. The code does and tells things on every step that seem wrong.
Even that seems unclear if node with smaller data is left or right.
 
My suggestion is to first make clear what thing that threaded binary
tree is. Then write plan how you implement it and what any thing
means in your data.
xerofoify <xerofoify@gmail.com>: Nov 30 01:19PM -0800

On Monday, November 28, 2016 at 4:12:06 PM UTC-5, xerofoify wrote:
> cleanup(root_);
> }
> };
 
Look I have tried that too. My exact question was and I have no idea how to even after drawing it out write this code. Also there are no docs on this online or elsewhere to my knowledge. The more you just tell me my code doesn't work does not help, I am looking for either proper documentation on how to do this or an example that actually works not a this doesn't work and draw it out
answer.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Nov 30 10:45PM +0100

On 28.11.2016 22:11, xerofoify wrote:
> <iostream> using namespace std; //Threaded Binary Tree Class that is
> templated to hold Node pointers with data type T template <class T>
> class ThreadedTree{
 
Well I'd like to help but that's just a wall of code to me. Unless I
spend (too much) time delving into it. Which I'm not going to do.
 
I can think of 2 meanings of "threaded (binary) three":
 
• A binary tree with extra pointers to support iterative traversal, e.g.
for iterators.
 
• A binary tree supporting or implemented with concurrent threads.
 
I did not see extra pointers in your code but I did see a function that
apparently had to do with iterators, but with just a dummy body.
 
Can you explain what you mean by "threaded tree"?
 
 
Cheers!,
 
- Alf
Jerry Stuckle <jstucklex@attglobal.net>: Nov 30 05:52PM -0500

On 11/30/2016 4:19 PM, xerofoify wrote:
> On Monday, November 28, 2016 at 4:12:06 PM UTC-5, xerofoify wrote:
 
> Look I have tried that too. My exact question was and I have no idea how to even after drawing it out write this code. Also there are no docs on this online or elsewhere to my knowledge. The more you just tell me my code doesn't work does not help, I am looking for either proper documentation on how to do this or an example that actually works not a this doesn't work and draw it out
> answer.
 
No online docs? How hard did you look? http://bfy.tw/8wD2
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
Paul <pepstein5@gmail.com>: Nov 30 10:30AM -0800

I'm confused by this:
 
std::queue<int> queues[2];
 
It compiles fine but what does it mean? When I research queues, I don't see
any [] operator mentioned.
 
Many thanks,
 
Paul
Ian Collins <ian-news@hotmail.com>: Dec 01 07:33AM +1300

On 12/ 1/16 07:30 AM, Paul wrote:
> I'm confused by this:
 
> std::queue<int> queues[2];
 
> It compiles fine but what does it mean?
 
An array of 2 queues?
 
--
Ian
Barry Schwarz <schwarzb@dqel.com>: Nov 30 11:24AM -0800

On Wed, 30 Nov 2016 10:30:25 -0800 (PST), Paul <pepstein5@gmail.com>
wrote:
 
 
>std::queue<int> queues[2];
 
>It compiles fine but what does it mean? When I research queues, I don't see
>any [] operator mentioned.
 
queues is an array of 2 std::queue<int>.
 
--
Remove del for email
"Öö Tiib" <ootiib@hot.ee>: Nov 29 03:31PM -0800

On Tuesday, 29 November 2016 22:35:26 UTC+2, mark wrote:
> just use `int`, the natural integer type for the platform". That's bound
> to lead to overflows on a 64-bit platform, since everything else uses
> size_t (and ptrdiff_t will be a larger type as well).
 
My point was only that there are no immediate reasons to use something
else but 'int' for integers in range 0 ... 10000.
Sure, if we need to save or to fix storage then 'int16_t' or even 14 bits
may make better sense. Usage of 'long long' for maximum extending
in future sounds like preliminary pessimization on any case.
 
 
> There is a nice template function thrown in to silence valid compiler
> warnings about this.
 
You yourself use claims like "the language is broken" and even
"steaming pile of poo" about how the various limits are handled
else thread. So the programmer has to take full awareness and
control about limits of *every* integer in his program and possible
undefined behaviors when those are breached. The warnings are
red herring and silly at best.
Geoff <geoff@invalid.invalid>: Nov 29 07:41PM -0800

On Tue, 29 Nov 2016 07:32:41 -0800 (PST), 嘱 Tiib <ootiib@hot.ee>
wrote:
 
>> Windows programs.
 
>Sure, but conforming INT_MAX can't be smaller than size limit 10000 that
>is explicitly given in the code.
 
I got the distinct impression that this was an extract of some 'real
world' code and the value of n was assigned arbitrarily in the snippet
to 10000 and the real code might use something larger. It is an error
to assume that n can _never_ be larger than INT_MAX just from the
presented code.
"Öö Tiib" <ootiib@hot.ee>: Nov 30 06:21AM -0800

On Wednesday, 30 November 2016 05:41:39 UTC+2, Geoff wrote:
> to 10000 and the real code might use something larger. It is an error
> to assume that n can _never_ be larger than INT_MAX just from the
> presented code.
 
It is an error to assume that *anything* else in C++ program than
programmer keeps any limits under control.
 
From presented code I assumed that vector size can _never_ be larger
than 10000 since so it was written. If 10000 was just "arbitrary"
then sure limit is 32767, since the code used 'rand' for indexing and
RAND_MAX is 0x7FFF on popular platforms:
https://msdn.microsoft.com/en-us/library/2dfe3bzd.aspx
Neither number can be bigger than INT_MAX.
 
What software it is where just any container may reach bigger size
than INT_MAX out of blue without programmer knowing it? Yuck. I never
assume that we discuss such software unless specially said.
"Chris M. Thomasson" <invalid@invalid.invalid>: Nov 29 03:51PM -0800

On 11/27/2016 7:02 PM, Christopher J. Pisz wrote:
> I am still playing with making custom memory management and learning
> about it.
[...]
> Can you point me to some memory management techniques that allow for
> allocating different amounts of storage and are not designed to work
> with one type only?
 
Check out the source of Hoard for an example:
 
https://github.com/emeryberger/Hoard
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)