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:

Tuesday, November 29, 2016

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

mark <mark@invalid.invalid>: Nov 29 01:24PM +0100

On 2016-11-29 06:53, Alf P. Steinbach wrote:
> support compilation with g++.
 
> Cheers & hth.,
 
> - Alf
 
Your code comes with security issues built in. Containers with more than
INT_MAX elements aren't unheard of these days. In fact, I can allocate a
vector<char> with more than INT_MAX elements with both 32-bit Linux and
Windows programs.
 
Your size_t -> ptrdiff_t conversion can overflow and you end up with a
negative size value (you can get integer overflows and/or buffer
overflows in downstream code on 8/16/32-bit platforms).
 
Your int loop index can overflow if the container size is too large.
 
For people compiling with warnings:
 
clang -Wall -Wconversion -c test.cpp
test.cpp:23:11: warning: implicit conversion changes signedness: 'int'
to 'size_type' (aka 'unsigned long long')
[-Wsign-conversion]
v[i] = i;
~ ^
test.cpp:29:30: warning: implicit conversion changes signedness:
'unsigned long long' to 'const int' [-Wsign-conversion]
int const j = rand() % v.size();
~ ~~~~~~~^~~~~~~~~~
test.cpp:29:23: warning: implicit conversion changes signedness: 'int'
to 'unsigned long long' [-Wsign-conversion]
int const j = rand() % v.size();
^~~~~~ ~
test.cpp:30:17: warning: implicit conversion changes signedness: 'int'
to 'size_type' (aka 'unsigned long long')
[-Wsign-conversion]
swap( v[i], v[j] );
~ ^
test.cpp:30:23: warning: implicit conversion changes signedness: 'const
int' to 'size_type' (aka 'unsigned long long')
[-Wsign-conversion]
swap( v[i], v[j] );
~ ^
test.cpp:12:12: warning: implicit conversion changes signedness:
'size_type' (aka 'unsigned long long') to 'Size'
(aka 'long long') [-Wsign-conversion]
{ return c.size(); }
~~~~~~ ~~^~~~~~
test.cpp:21:25: note: in instantiation of function template specialization
'n_items_of<std::vector<int, std::allocator<int> > >' requested here
for( int i = 1; i < n_items_of( v ); ++i )
^
6 warnings generated.
"Öö Tiib" <ootiib@hot.ee>: Nov 29 07:32AM -0800

On Tuesday, 29 November 2016 14:25:06 UTC+2, mark wrote:
> INT_MAX elements aren't unheard of these days. In fact, I can allocate a
> vector<char> with more than INT_MAX elements with both 32-bit Linux and
> Windows programs.
 
Sure, but conforming INT_MAX can't be smaller than size limit 10000 that
is explicitly given in the code.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Nov 29 06:45PM +0100

On 29.11.2016 13:24, mark wrote:
 
>> Cheers & hth.,
 
>> - Alf
 
> Your code comes with security issues built in.
 
False.
 
 
> Containers with more than INT_MAX elements aren't unheard of these days.
 
True.
 
 
> In fact, I can allocate a
> vector<char> with more than INT_MAX elements with both 32-bit Linux and
> Windows programs.
 
True.
 
 
> Your size_t -> ptrdiff_t conversion can overflow
 
It can overflow on a 16-bit system.
 
That means that the /language/ does not support what one tries to
achieve on such 16-bit system, since `ptrdiff_t` is the type used for
pointer differences -- hence the name.
 
I am sure that you don't understand this, since you continue to say...
 
 
> and you end up with a
> negative size value (you can get integer overflows and/or buffer
> overflows in downstream code on 8/16/32-bit platforms).
 
False.
 
 
> Your int loop index can overflow if the container size is too large.
 
False, it's not too large.
 
Don't choose types for some extraordinary situation that's very
different than the ones you need to handle.
 
For example, don't drive a tractor to work just because you can imagine
that if you were doing something very different, like farm work, you'd
need that tractor.
 
I think you'll agree that someone driving a tractor to work, for that
reason, is behaving like an idiot.
 
 
> to 'size_type' (aka 'unsigned long long')
> [-Wsign-conversion]
> v[i] = i;
 
I didn't know that g++ supported that silly-warning.
 
If you enable it then you truly deserve the meaningless avalanche of
warnings.
 
 
Cheers & hth.,
 
- Alf
mark <mark@invalid.invalid>: Nov 29 09:29PM +0100

On 2016-11-29 18:45, Alf P. Steinbach wrote:
> achieve on such 16-bit system, since `ptrdiff_t` is the type used for
> pointer differences -- hence the name.
 
> I am sure that you don't understand this, since you continue to say...
 
It's not my fault that C++ is one big steaming pile of poo with regards
to integers. Let's try a 32-bit platform (I'm too lazy to get out a
16-bit one), Linux i686, GCC 4.9.2:
 
-------------------------------------------------------------------
#include <vector>
#include <limits>
#include <iostream>
#include <stdint.h>
 
using namespace std;
 
using Size = ptrdiff_t;
 
template< class Container >
auto n_items_of( Container const& c )
-> Size
{ return c.size(); }
 
int main() {
std::vector<char> v;
v.resize(size_t(std::numeric_limits<int>::max()) + 10);
std::cout << "size(): " << v.size() << std::endl;
std::cout << "n_items_of (s): " << (int64_t) n_items_of(v) <<
std::endl;
std::cout << "n_items_of (u): " << (uint64_t) n_items_of(v) <<
std::endl;
}
---------------------------------------------------------------------
size(): 2147483657
n_items_of (s): -2147483639
n_items_of (u): 18446744071562067977
 
I have seen exactly this kind of bug in production code (e.g. with
people using 64-bit ints for large file access).
 
>> negative size value (you can get integer overflows and/or buffer
>> overflows in downstream code on 8/16/32-bit platforms).
 
> False.
 
See above.
 
>> Your int loop index can overflow if the container size is too large.
 
> False, it's not too large.
 
It is not too large with your hard-coded size. It can easily be too
large if vectors are passed around. 64-bit platform to avoid the size_t
-> ptrdiff_t overflow:
 
--------------------------------------------------------------------
#include <vector>
#include <limits>
#include <iostream>
 
using namespace std;
 
using Size = ptrdiff_t;
 
template< class Container >
auto n_items_of( Container const& c )
-> Size
{ return c.size(); }
 
int main() {
std::vector<char> v;
v.resize(size_t(std::numeric_limits<int>::max()) + 10);
for(int i = 0; i < n_items_of(v); i++) ;
}
 
--------------------------------------------------------------------
g++ -Wall -O2 -std=c++14 test_huge_vector_undef_behavior.cpp
test_huge_vector_undef_behavior.cpp: In function 'int main()':
test_huge_vector_undef_behavior.cpp:17:5: warning: iteration 2147483647u
invokes undefined behavior [-Waggressive-loop-optimizations]
for(int i = 0; i < n_items_of(v); i++) ;
^
test_huge_vector_undef_behavior.cpp:17:5: note: containing loop
 
In this case, GCC "optimizes" this into an endless loop. It would easy
to transform this code to corrupt the entire memory after v.
 
> Don't choose types for some extraordinary situation that's very
> different than the ones you need to handle.
 
So how do you deal with the potential overflows above? Do you check the
container size each time you insert something that it's not larger than
INT_MAX?
 
> need that tractor.
 
> I think you'll agree that someone driving a tractor to work, for that
> reason, is behaving like an idiot.
 
Advice like yours directly contributes to the endless flow of security
vulnerabilities in C and C++ programs.
 
 
> I didn't know that g++ supported that silly-warning.
 
> If you enable it then you truly deserve the meaningless avalanche of
> warnings.
 
As it turns out those warnings are entirely justified. Doing anything
with mixed sizes or signedness is one giant minefield.
mark <mark@invalid.invalid>: Nov 29 09:35PM +0100

On 2016-11-29 16:32, Öö Tiib wrote:
>> Windows programs.
 
> Sure, but conforming INT_MAX can't be smaller than size limit 10000 that
> is explicitly given in the code.
 
What's your point? I was responding to the generic advice "In general,
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).
 
There is a nice template function thrown in to silence valid compiler
warnings about this.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Nov 29 09:55PM +0100

On 29.11.2016 21:29, mark wrote:
> size(): 2147483657
> n_items_of (s): -2147483639
> n_items_of (u): 18446744071562067977
 
As mentioned, the /language/ doesn't support this. `ptrdiff_t` is the
type of a pointer difference expression, any pointer difference
expression. And it overflows for this case, which means that you need to
treat that exceptionally large array very specially: you need to avoid
handing it to code with any possible pointer differences.
 
In other words, you're out of bounds of the language.
 
It is the single example where overflow occurs, and it's not relevant since
 
* It's not supported by the language.
 
* It does not occur in practice.
 
* It's not even supported by Windows (although Windows can be configured
to support it).
 
Re the last point, a 32-bit Windows application, without special
configuration of Windows, only has 2GB memory available to it.
 
Since you're apparently unaware of this, thinking that the above example
would not only be generally safe if it used size_t, but thinking that
allocating over half of available address space to a byte array, in
32-bit code, has occurred at least once in the annals of software
development, you prove that you're absolutely clueless.
 
As I suspected.
 
 
> I have seen exactly this kind of bug in production code (e.g. with
> people using 64-bit ints for large file access).
 
No doubt you have. It's so common allocating > 2G byte arrays in 32-bit
code.
 
Laughing out loud. :)
 
 
Cheers!, & hth.,
 
- Alf
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Nov 29 09:21PM

On 29/11/2016 20:35, 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).
 
One should not use 'int' at all in a C++ program (except as return type
of main()) at it is unsafe and non-portable. One should used the sized
integer typedefs such as int32_t instead.
 
/Flibble
legalize+jeeves@mail.xmission.com (Richard): Nov 29 10:02PM

[Please do not mail me a copy of your followup]
 
mark <mark@invalid.invalid> spake the secret code
 
>It's not my fault that C++ is one big steaming pile of poo with regards
>to integers.
 
Pray tell, what languages are addressing this in a superior fashion?
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
mark <mark@invalid.invalid>: Nov 29 11:13PM +0100

On 2016-11-29 21:55, Alf P. Steinbach wrote:
 
> As mentioned, the /language/ doesn't support this. `ptrdiff_t` is the
> type of a pointer difference expression, any pointer difference
> expression.
 
The language is broken. ptrdiff_t doesn't need to support arbitrary
pointer differences, 5.7 [expr.add]:
<<<
When two pointers to elements of the same array object are subtracted,
the result is the difference of the subscripts of the two array
elements. The type of the result is an implementation-defined signed
integral type; this type shall be the same type that is defined as
std::ptrdiff_t in the <cstddef> header (18.2). As with any other
arithmetic overflow, if the result does not fit in the space provided,
the behavior is undefined.
 
Your n_items_of() has undefined behavior.
 
From what I can tell, the only restriction on ptrdiff_t is that it is
signed. But apparently, per C and C++ standards, it could theoretically
be int8_t and it could be a smaller type than size_t.
 
> And it overflows for this case, which means that you need to
> treat that exceptionally large array very specially: you need to avoid
> handing it to code with any possible pointer differences.
 
How do you know in advance how large the array is?
 
> In other words, you're out of bounds of the language.
 
???
 
> It is the single example where overflow occurs, and it's not relevant
since
 
> * It's not supported by the language.
 
The language supports an array size that's larger than ptrdiff_t. Why
don't you point where standard disallows it, instead of throwing around
insults?
 
> * It does not occur in practice.
 
It does occur in practice.
 
> to support it).
 
> Re the last point, a 32-bit Windows application, without special
> configuration of Windows, only has 2GB memory available to it.
 
32-bit programs running on x64 Windows get 4GB of address space without
any special configuration. They just need to be compiled with the
"largeaddressaware" flag.
 
>> people using 64-bit ints for large file access).
 
> No doubt you have. It's so common allocating > 2G byte arrays in 32-bit
> code.
 
Did I say it's common? It was a security bug. A large vector was
allocated shortly after program start, the size being calculated based
on untrusted input. Eventually, there was a comparison between the size
and an int variable leading to memory corruption.
 
The same kind of thing can happen on platforms where int == int16_t,
size_t == uint16_t, ptrdiff_t == int.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Nov 29 11:55PM +0100

On 29.11.2016 23:13, mark wrote:
>> type of a pointer difference expression, any pointer difference
>> expression.
 
> The language is broken.
 
Wrong about this.
 
> ptrdiff_t doesn't need to support arbitrary pointer differences,
 
Right.
 
 
> std::ptrdiff_t in the <cstddef> header (18.2). As with any other
> arithmetic overflow, if the result does not fit in the space provided,
> the behavior is undefined.
 
Good.
 
 
> Your n_items_of() has undefined behavior.
 
Wrong.
 
 
> From what I can tell, the only restriction on ptrdiff_t is that it is
> signed. But apparently, per C and C++ standards, it could theoretically
> be int8_t and it could be a smaller type than size_t.
 
No, it's required, by the C standard, to be at least 17 bits. And that's
not a typo, I didn't mean to write 16.
 
 
>> treat that exceptionally large array very specially: you need to avoid
>> handing it to code with any possible pointer differences.
 
> How do you know in advance how large the array is?
 
You don't, in general.
 
Just like you don't know exactly the required stack size.
 
And there are other problems with such (relative to 32-bit coding) large
arrays, including that an OS built on the idea that
we-at-Microsoft-make-software-that-know-better-than-you-what-you-need
such as Windows, can just start trashing, swapping to and back from
disk, with no way to configure off that behavior.
 
 
>> In other words, you're out of bounds of the language.
 
> ???
 
The core language doesn't support that array size in general, due to the
fact that the type of a pointer difference is `ptrdiff_t`.
 
The standard library does not support it, since it also defaults its
difference types, e.g. for `std::distance`, to `ptrdiff_t`.
 
 
 
>> * It's not supported by the language.
 
> The language supports an array size that's larger than ptrdiff_t. Why
> don't you point where standard disallows it,
 
You just did, above.
 
It's not disallowed. It's just /partly/ supported. Which means it's not
generally or fully supported.
 
You have to be very careful what you do with it, lest things go haywire.
 
 
> instead of throwing around insults?
 
Oh, sorry about that.
 
We'll see where this goes.
 
 
>> * It does not occur in practice.
 
> It does occur in practice.
 
Fire those devs.
 
 
 
> 32-bit programs running on x64 Windows get 4GB of address space without
> any special configuration. They just need to be compiled with the
> "largeaddressaware" flag.
 
Well, there's more to it than that, including bugs in the Windows API
(i.e., be careful with axe, Eugene), but the main sub-point is that this
example, the single one of its kind, does not occur naturally.
 
That's probably why the language design, the limits of pointer
arithmetic, simply assumes that it doesn't occur.
 
 
[snip]
> allocated shortly after program start, the size being calculated based
> on untrusted input. Eventually, there was a comparison between the size
> and an int variable leading to memory corruption.
 
A bug in someone's program means that the function I presented was
unsafe, for they could in theory have used that function in their buggy
code, yes?
 
No. It doesn't work that way.
 
A function isn't unsafe because it's possible for someone's buggy code
to give it arguments outside its preconditions.
 
 
> The same kind of thing can happen on platforms where int == int16_t,
> size_t == uint16_t, ptrdiff_t == int.
 
No, `ptrdiff_t` is not allowed to be 16 bits or less.
 
In a conforming implementation.
 
Because the C standard requires its limits to be equal or greater in
magnitude to −65535 (lower limit) and +65535 (upper limit).
 
 
Cheers & hth.,
 
- Alf
asetofsymbols@gmail.com: Nov 29 11:55AM -0800

Allocator? What does it mean? If it is malloc() free() implementation there is K&R2 that says in its pages, where to start, I remember from that custom malloc is possible implement C++ memory operators new() delete() too
"Öö Tiib" <ootiib@hot.ee>: Nov 29 12:13PM -0800

> there is K&R2 that says in its pages, where to start, I remember from
> that custom malloc is possible implement C++ memory operators
> new() delete() too
 
No, it is C++ class interface concept of Allocator.
Standard library provides standard Allocator template
that is named 'std::allocator'. All standard templates that expect
allocator argument have it as default. So for example 'std::vector'
takes two arguments:
 
template< class T
, class Allocator = std::allocator<T> >
class vector;
"Christopher J. Pisz" <cpisz@austin.rr.com>: Nov 29 02:54PM -0600

On 11/29/2016 2:13 PM, Öö Tiib wrote:
 
> template< class T
> , class Allocator = std::allocator<T> >
> class vector;
 
No, the word 'allocator' did not appear in the original post at all.
So it means nothing, because it isn't there to begin with.
ruben safir <ruben@mrbrklyn.com>: Nov 29 04:39AM -0500

Why is it that when I change the origianl vector the object changes but not the reverse.
 
 
#include <iostream>
#include <vector>
 
namespace vect{
 
/*
* =====================================================================================
* Class: Lvalue
* Description: testing vector access as an lvalue
* =====================================================================================
*/
 
template < class T >
class Lvalue
{
public:
 
// ==================== LIFECYCLE =======================================
Lvalue (){}; /* constructor */
Lvalue (std::vector<T> in): _ofthings{in}{}; /* constructor */
Lvalue ( const Lvalue &other ); /* copy constructor */
~Lvalue (){}; /* destructor */
 
/* ==================== ACCESSORS ======================================= */
std::vector<T>& ofthings(){
return _ofthings;
};
 
void ofthings(std::vector<T> const vec){
_ofthings = vec;
};
/* ==================== MUTATORS ======================================= */
 
/* ==================== OPERATORS ======================================= */
 
const Lvalue& operator = ( const Lvalue &other ); // assignment operator
T& operator [] (int index)
{
return (ofthings()[index]);
};
friend std::ostream &operator << (std::ostream &os, const Lvalue in)
{
for(int i = 0; i < in._ofthings.size(); i++ ){
std::cout << i << "\t";
}
return os;
};
 
/* ==================== DATA MEMBERS ======================================= */
protected:
std::vector<T> _ofthings;
 
private:
 
}; /* ----- end of template class Lvalue ----- */
 
};
 
 
int main ( int argc, char *argv[] )
{
 
std::cout << "TEST INPUT TO VECTOR" << std::endl;
std::vector<int> test(100, 0);
for(int i = 0; i<10; i++ ){
test[i] = i;
std::cout << i << "::" <<test[i] << "\t";
}
std::cout << std::endl;
std::cout << "TEST INPUT TO OBJECT" << std::endl;
vect::Lvalue<int> test2 {test};
for(int j = 0, i=10; j < 10; i--, j++){
test[j] = i;
std::cout << "What is J" << j << std::endl;
std::cout << "i: " << i << " j: " << j << " test[j]: " << test[j] << std::endl;
std::cout << "i: " << i << " j: " << j << " test2[j]: " << test[j] << std::endl;
}
std::cout << std::endl;
std::cout << "TEST INPUT TO OBJECT bidirectional" << std::endl;
for(int i = 0, j=10; i < 10; i++, j++){
test2[i] = j;
std::cout << "What is i ==>" << i << std::endl;
std::cout << "i: " << i << " j: " << j << " test2[i]: " << test2[i] << std::endl;
std::cout << "i: " << i << " j: " << j << " test[i]: " << test[i] << std::endl;
}
std::cout << std::endl;
std::cout << std::endl;
for(int j = 0, i=10; j < 10; i--, j++){
test[j] = i;
std::cout << "What is J" << j << std::endl;
std::cout << "i: " << i << " j: " << j << " test[j]: " << test[j] << std::endl;
std::cout << "i: " << i << " j: " << j << " test2[j]: " << test[j] << std::endl;
}
std::cout << "__DONE__" << std::endl;
 
 
 
return EXIT_SUCCESS;
} /* ---------- end of function main ---------- */
 
TEST INPUT TO VECTOR
0::0 1::1 2::2 3::3 4::4 5::5 6::6 7::7 8::8 9::9
TEST INPUT TO OBJECT
What is J0
i: 10 j: 0 test[j]: 10
i: 10 j: 0 test2[j]: 10
What is J1
i: 9 j: 1 test[j]: 9
i: 9 j: 1 test2[j]: 9
What is J2
i: 8 j: 2 test[j]: 8
i: 8 j: 2 test2[j]: 8
What is J3
i: 7 j: 3 test[j]: 7
i: 7 j: 3 test2[j]: 7
What is J4
i: 6 j: 4 test[j]: 6
i: 6 j: 4 test2[j]: 6
What is J5
i: 5 j: 5 test[j]: 5
i: 5 j: 5 test2[j]: 5
What is J6
i: 4 j: 6 test[j]: 4
i: 4 j: 6 test2[j]: 4
What is J7
i: 3 j: 7 test[j]: 3
i: 3 j: 7 test2[j]: 3
What is J8
i: 2 j: 8 test[j]: 2
i: 2 j: 8 test2[j]: 2
What is J9
i: 1 j: 9 test[j]: 1
i: 1 j: 9 test2[j]: 1
 
TEST INPUT TO OBJECT bidirectional
What is i ==>0
i: 0 j: 10 test2[i]: 10
i: 0 j: 10 test[i]: 10
What is i ==>1
i: 1 j: 11 test2[i]: 11
i: 1 j: 11 test[i]: 9
What is i ==>2
i: 2 j: 12 test2[i]: 12
i: 2 j: 12 test[i]: 8
What is i ==>3
i: 3 j: 13 test2[i]: 13
i: 3 j: 13 test[i]: 7
What is i ==>4
i: 4 j: 14 test2[i]: 14
i: 4 j: 14 test[i]: 6
What is i ==>5
i: 5 j: 15 test2[i]: 15
i: 5 j: 15 test[i]: 5
What is i ==>6
i: 6 j: 16 test2[i]: 16
i: 6 j: 16 test[i]: 4
What is i ==>7
i: 7 j: 17 test2[i]: 17
i: 7 j: 17 test[i]: 3
What is i ==>8
i: 8 j: 18 test2[i]: 18
i: 8 j: 18 test[i]: 2
What is i ==>9
i: 9 j: 19 test2[i]: 19
i: 9 j: 19 test[i]: 1
 
 
What is J0
i: 10 j: 0 test[j]: 10
i: 10 j: 0 test2[j]: 10
What is J1
i: 9 j: 1 test[j]: 9
i: 9 j: 1 test2[j]: 9
What is J2
i: 8 j: 2 test[j]: 8
i: 8 j: 2 test2[j]: 8
What is J3
i: 7 j: 3 test[j]: 7
i: 7 j: 3 test2[j]: 7
What is J4
i: 6 j: 4 test[j]: 6
i: 6 j: 4 test2[j]: 6
What is J5
i: 5 j: 5 test[j]: 5
i: 5 j: 5 test2[j]: 5
What is J6
i: 4 j: 6 test[j]: 4
i: 4 j: 6 test2[j]: 4
What is J7
i: 3 j: 7 test[j]: 3
i: 3 j: 7 test2[j]: 3
What is J8
i: 2 j: 8 test[j]: 2
i: 2 j: 8 test2[j]: 2
What is J9
i: 1 j: 9 test[j]: 1
i: 1 j: 9 test2[j]: 1
__DONE__
Ben Bacarisse <ben.usenet@bsb.me.uk>: Nov 29 10:45AM


> Why is it that when I change the origianl vector the object changes
> but not the reverse.
 
Neither is happening. You've missed a "2" from the two ouput operations.
 
<snip>
--
Ben.
ruben safir <ruben@mrbrklyn.com>: Nov 29 09:29AM -0500

On 11/29/2016 05:45 AM, Ben Bacarisse wrote:
> Neither is happening. You've missed a "2" from the two ouput operations.
 
 
correct, thanks for looking
David Brown <david.brown@hesbynett.no>: Nov 29 09:59AM +0100

> are doing (making the compiler a server) is a good idea?
> Sorry to honk my own horn again, but I suggested this with
> GCC before Clang existed.
 
You can blow your nose as much as you want, but it was hardly /your/
idea. The idea of making a compilation server has existed for decades -
certainly for the twenty+ years that I have been programming C. And it
is precisely to avoid people taking all the hard work of gcc and putting
it into a closed-source commercial product that gcc have long insisted
on a traditional compilation model, rather than considering a
server-style system. The clang/llvm folks differ in their philosophy
for licenses, and see the use of clang as a server (especially in IDEs)
as a major use case. gcc /is/ moving towards better support for
server-style compilation (in particular, for use with gdb), just as they
introduced a plugin architecture a few years ago despite fears that it
would be easier to mix gcc with closed-source software.
"Öö Tiib" <ootiib@hot.ee>: Nov 29 06:19AM -0800

On Monday, 28 November 2016 23:44:58 UTC+2, Vir Campestris wrote:
> > compilation. Whatever they have done is closed source and in beta test.
 
> Is that even legal? Surely Clang's licence requires you to publish
> derived works? (asd no, I haven't checked)
 
It is legal to make closed source derivative work from clang code base.
My opinion is that if there are such things then clang has more usages
and so becomes better and it is good.
Paavo Helde <myfirstname@osa.pri.ee>: Nov 29 10:29AM +0200

On 29.11.2016 0:50, xerofoify wrote:
>> }
 
>> Moreover, if here p->data_==data, this thing goes into infinite loop.
 
> I am still confused Paavo. Can you show me through code as it seems like I am not understanding it for some reason.
 
I am not sure what you are confused about. Pointers? Basic execution
flow? From afar, it looks like you are using some kind of Monte Carlo
programming style - writing down a random sequence of tokens, hoping
that this somehow works and does whatever is needed. This is bound to be
a very tedious method and certainly does not work in C++ where a program
might appear to work correctly and still exhibit Undefined Behavior.
Maybe you should first try a simpler program involving pointers?
 
Anyway, if stepping through debugger does not help you, write down the
state on the paper (values for the memory slots occupied by p, data,
etc) and step through the code on paper.
 
> iterator begin(){
> Node* curr = root_;
> if (curr->right_ == nullptr && curr->left_ == nullptr) {
 
For example, here you dereferenced 'curr'.
 
 
> return nullptr;
> }
> if (curr != nullptr) {
 
And only here you check if it can be dereferenced. See a problem here?
Either the check is in the wrong place or it is not needed.
 
 
> return iterator(curr);
> }
> Look I have tried this for at least a few things now and ran through a debugger many times guys. Something is not clicking in my understanding so asking me to run through it with a debugger does not help.
 
This version also has no mention of leftThread or rightThread, which
were apparently needed in the previous version. I have no idea what this
function should do, so I do not know if they are needed or not, but it
sure looks suspicious.
 
hth
Paavo
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Nov 29 09:18AM +0100

On 29.11.2016 08:49, ruben safir wrote:
 
>> Cheers!,
 
>> _ Alf
 
> Alf, your off your rocker, truly.
 
As far as I can tell Rubin Safir and Popping Mad are the same person.
 
- Alf
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:

Digest for comp.programming.threads@googlegroups.com - 6 updates in 4 topics

Ramine <ramine@1.1>: Nov 28 09:39PM -0500

Hello,
 
Read this:
 
The Functional Revolution in C++
 
https://bartoszmilewski.com/2014/06/09/the-functional-revolution-in-c/
 
I don't agree with Bartosz Milewski, because Bartosz has a binary view
on this subject, because i think it is not just black and white,
because Bartosz Milewski seems to imply that Haskel is the solution
and functional programming because of purity of functions of Haskel is
the solution for composability, but as i said we have to agree that
what consists of a sufficient solution also, Bartosz Milewski is right
that the functional language Haskel because its purity of functions
avoids side effects and allows composability, but we have to agree
on what is a sufficient solution , because i have implied in my previous
post that a sufficient solution is also this:
 
because the presence today of transactional memory that avoids
deadlock and livelock and race conditions is able to provide
us with a tool that solves problems of parallelism
, and it allows composability, and this is mandatory and i think
it is like sufficient for complex systems, so i don't think that purity
of functions of Haskel or functional programming is mandatory, so
i think that Object oriented programming will be still
our prefered tool in the future.
 
The strictness and purity of functions of Haskel is good for
composability and safe-critical systems.
 
But Object oriented programming with transactional memory and
with other tools for safe-critical systems is i think a sufficient tool
that is good for composability and safe-critical systems.
 
So i don't think that functional programming is mandatory,
so i think that object oriented programming is great and will be still
here in the future.
 
 
Thank you,
Amine Moulay Ramdane.
bleachbot <bleachbot@httrack.com>: Nov 29 02:44AM +0100

bleachbot <bleachbot@httrack.com>: Nov 29 03:04AM +0100

bleachbot <bleachbot@httrack.com>: Nov 29 03:39AM +0100

Ramine <ramine@1.1>: Nov 28 09:05PM -0500

Hello....
 
The strictness and purity of functions of Haskel is good for
composability and safe-critical systems.
 
But Object oriented programming with transactional memory and
with other tools for safe-critical systems is i think a sufficient tool
that is good for composability and safe-critical systems.
 
So i don't think that functional programming is mandatory,
so i think that object oriented programming is great and will be still
here in the future.
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: Nov 28 08:45PM -0500

Hello.......
 
About functional programming and object oriented programming...
 
I am coming from a long road of software development..
 
But when i read on internet about functional programming such us
Haskel, they seems to imply that since purity of functions
in Haskel avoids side effects and allows composability in
the presence of parallelism, so functional programming is not avoidable,
but i think that there reasoning is not correct,
because the presence today of transactional memory that avoids
deadlock and livelock and race conditions is able to provide
us with a tool that solves problems of parallelism
, and it allows composability, and this is mandatory and i think
it is like sufficient for complex systems, so i don't think that purity
of functions of Haskel or functional programming is mandatory, so
i think that Object oriented programming will be still
our prefered tool in the future.
 
 
Thank you,
Amine Moulay Ramdane.
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.programming.threads+unsubscribe@googlegroups.com.
Posted by at No comments:

Monday, November 28, 2016

Digest for comp.lang.c++@googlegroups.com - 25 updates in 10 topics

Popping mad <rainbow@colition.gov>: Nov 29 05:43AM

I was making this mock code up to isolate a problem and it suprised me with this new compiler error that I really don't understand in the context of my program
 
#include <iostream>
#include <vector>
 
namespace vect{
 
/*
* =====================================================================================
* Class: Lvalue
* Description: testing vector access as an lvalue
* =====================================================================================
*/
 
template < class T >
class Lvalue
{
public:
 
// ==================== LIFECYCLE =======================================
Lvalue (){}; /* constructor */
Lvalue (std::vector<T> in): _ofthings{in}{}; /* constructor */
Lvalue ( const Lvalue &other ); /* copy constructor */
~Lvalue (){}; /* destructor */
 
/* ==================== ACCESSORS ======================================= */
T& ofthings(){
return _ofthings;
};
 
void ofthings(std::vector<T> const vec){
_ofthings = vec;
};
/* ==================== MUTATORS ======================================= */
 
/* ==================== OPERATORS ======================================= */
 
const Lvalue& operator = ( const Lvalue &other ); // assignment operator
const T& operator [] (int index)
{
return ofthings()[index];
};
friend std::ostream &operator << (std::ostream &os, const Lvalue)
{
for(int i = 0; i < _ofthings.size(); i++ ){
std::cout << i << "\t";
}
return os;
};
 
/* ==================== DATA MEMBERS ======================================= */
protected:
std::vector<T> _ofthings;
 
private:
 
}; /* ----- end of template class Lvalue ----- */
 
};
 
 
int main ( int argc, char *argv[] )
{
 
std::vector<int> test {0};
for(int i = 0; i<10; i++ ){
test[i] = i;
std::cout << test[i] << "\t";
}
std::cout << std::endl;
 
vect::Lvalue<int> test2 {test};
for(int j=0, i = 10; i>0; i--, j++){
test[j] = i;
std::cout << test[j] << "\t";
}
std::cout << std::endl;
 
 
 
 
 
 
return EXIT_SUCCESS;
} /* ---------- end of function main ---------- */
 
It returns:
|| g++ -Wall -ggdb -pg -M *.c >make.deps
|| g++ -Wall -ggdb -pg -pg -pthread -o lvalue.exe lvalue.c
|| lvalue.c: In function 'std::ostream& vect::operator<<(std::ostream&, vect::Lvalue<T>)':
lvalue.c|61 col 25| error: invalid use of non-static data member 'vect::Lvalue<T>::_ofthings'
|| for(int i = 0; i < _ofthings.size(); i++ ){
|| ^~~~~~~~~
lvalue.c|69 col 20| note: declared here
|| std::vector<T> _ofthings;
|| ^~~~~~~~~
 
 
I'm not making any const variable or a static variable. The cases I see for this in an only search involve classes wrapped in classes.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Nov 29 06:55AM +0100

On 29.11.2016 06:43, Popping mad wrote:
> || std::vector<T> _ofthings;
> || ^~~~~~~~~
 
> I'm not making any const variable or a static variable.
 
The `friend` function is not a member function.
 
There is no `this` object.
 
 
Cheers & hth.,
 
- Alf
ruben safir <ruben@mrbrklyn.com>: Nov 29 02:52AM -0500

On 11/29/2016 12:55 AM, Alf P. Steinbach wrote:
 
>> I'm not making any const variable or a static variable.
 
> The `friend` function is not a member function.
 
> There is no `this` object.
 
 
yeah, I take it back. You can be right sometimes. I fixed that but it
came back with a different error. I'll post it later. This is supposed
to be the simplified test case of a larger program. And it is tripping
me up on many parts.
Popping mad <rainbow@colition.gov>: Nov 29 06:21AM

I wanted to embed a vector in my class then access it through a wrapper within the
class that involved the subscript operator operator[]<> and I've run across an
unexpected problem I didn't anticipate
 
So a Class looks like this, with the data member _ofthings<T> being a vector type.
 
It has an accessory function ofthings() that returns the vector as an available lvaue
 
T& ofthings(){
return _ofthings;
};
 
the overload is vissible and when I compile I get an error
|| g++ -Wall -ggdb -pg -M *.c >make.deps
|| g++ -Wall -ggdb -pg -pg -pthread -o lvalue.exe lvalue.c
|| lvalue.c: In function 'int main(int, char**)':
lvalue.c|91 col 14| error: assignment of read-only location 'test2.vect::Lvalue<T>::operator[]<int>(j)'
|| test2[j] = i;
|| ^
|| lvalue.c: In instantiation of 'const T& vect::Lvalue<T>::operator[](int) [with T = int]':
lvalue.c|91 col 10| required from here
lvalue.c|57 col 23| error: subscripted value is neither array nor pointer
|| return ofthings()[index];
|| ~~~~~~~~~~^
|| lvalue.c: In instantiation of 'T& vect::Lvalue<T>::ofthings() [with T = int]':
lvalue.c|57 col 21| required from 'const T& vect::Lvalue<T>::operator[](int) [with T = int]'
lvalue.c|91 col 10| required from here
lvalue.c|44 col 13| error: invalid initialization of reference of type 'int&' from expression of type 'std::vector<int>'
|| return _ofthings;
|| ^~~~~~~~~
make: *** [makefile|5| lvalue] Error 1
 
 
namespace vect{
 
/*
* =====================================================================================
* Class: Lvalue
* Description: testing vector access as an lvalue
* =====================================================================================
*/
 
template < class T >
class Lvalue
{
public:
 
// ==================== LIFECYCLE =======================================
Lvalue (){}; /* constructor */
Lvalue (std::vector<T> in): _ofthings{in}{}; /* constructor */
Lvalue ( const Lvalue &other ); /* copy constructor */
~Lvalue (){}; /* destructor */
 
/* ==================== ACCESSORS ======================================= */
T& ofthings(){
return _ofthings;
};
 
void ofthings(std::vector<T> const vec){
_ofthings = vec;
};
/* ==================== MUTATORS ======================================= */
 
/* ==================== OPERATORS ======================================= */
 
const Lvalue& operator = ( const Lvalue &other ); // assignment operator
const T& operator [] (int index)
{
return ofthings()[index];
};
friend std::ostream &operator << (std::ostream &os, const Lvalue in)
{
for(int i = 0; i < in._ofthings.size(); i++ ){
std::cout << i << "\t";
}
return os;
};
 
/* ==================== DATA MEMBERS ======================================= */
protected:
std::vector<T> _ofthings;
 
private:
 
}; /* ----- end of template class Lvalue ----- */
 
};
 
 
Main is this
 
int main ( int argc, char *argv[] )
{
 
std::cout << "TEST INPUT TO VECTOR" << std::endl;
std::vector<int> test {0};
for(int i = 0; i<10; i++ ){
test[i] = i;
std::cout << test[i] << "\t";
}
std::cout << std::endl;
std::cout << "TEST INPUT TO OBJECT" << std::endl;
vect::Lvalue<int> test2 {test};
for(int j=0, i = 10; j<10; i--, j++){
test2[j] = i;
std::cout << test2[j] << "\t";
}
std::cout << std::endl;
std::cout << "__DONE__";
 
 
 
return EXIT_SUCCESS;
} /* ----
 
 
So I can not overload [] unless I access a pointer or an array?
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Nov 29 07:22AM +0100

On 29.11.2016 07:21, Popping mad wrote:
> [snip]
 
Generally, start with the very first error message, and ignore the rest.
 
Figure out what it means.
 
Fix that error.
 
Compile.
 
Repeat.
 
 
Cheers & hth.,
 
- Alf
Popping mad <rainbow@colition.gov>: Nov 29 06:45AM

On Tue, 29 Nov 2016 07:22:54 +0100, Alf P. Steinbach wrote:
 
 
> Generally, start with the very first error message, and ignore the rest.
 
> Figure out what it means.
 
> Fix that error.
 
As usually, Alf, that is the WRONG answer. You're very consistent in being wrong all the time.
But I did fix the problem in that I needed to correct the return type to vector<T> and not T.
 
Good work Alf. WHo knows, in 20 years you might be able to learn how to be helpful or read compiler errors. Neither is likely.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Nov 29 08:14AM +0100

On 29.11.2016 07:45, Popping mad wrote:
> to correct the return type to vector<T> and not T.
 
> Good work Alf. WHo knows, in 20 years you might be able to learn how
> to be helpful or read compiler errors. Neither is likely.
 
If this is "Popping mad" then he's suddenly acquired
 
• very much improved English,
• an ungratefulness and tendency to lie that he's not displayed before, and
• posting via a different server than usual.
 
I guess he'll clear that up, whether he was impersonated. :)
 
In any case this was posted by a person who is not very nice.
 
 
Cheers!,
 
_ Alf
ruben safir <ruben@mrbrklyn.com>: Nov 29 02:49AM -0500

On 11/29/2016 02:14 AM, Alf P. Steinbach wrote:
 
> In any case this was posted by a person who is not very nice.
 
> Cheers!,
 
> _ Alf
 
Alf, your off your rocker, truly.
bleachbot <bleachbot@httrack.com>: Nov 29 02:44AM +0100

bleachbot <bleachbot@httrack.com>: Nov 29 03:05AM +0100

bleachbot <bleachbot@httrack.com>: Nov 29 03:18AM +0100

bleachbot <bleachbot@httrack.com>: Nov 29 03:40AM +0100

ram@zedat.fu-berlin.de (Stefan Ram): Nov 29 06:34AM

>Generally, start with the very first error message, and ignore the rest.
 
I was recently asked in my C++ course about long confusing
error messages. (I just showed them function templates.)
 
I gave the above (Alfs) answer, and added another observation:
 
Sometimes it helps to pick the English-language parts that
one can understand from anywhere in a long error report and
just ignore the rest. (Well, actually one has little choice
to do something else.)
Bob Langelaan <bobl0456@gmail.com>: Nov 28 07:55PM -0800

The code snippet:
 
unsigned long long n = 10000;
 
//Create vector of size n and initialize to 1 to n
vector<unsigned long long> v(n);
for (unsigned long long i = 1; i < v.size(); ++i)
{
v[i] = i+1;
}
 
//Shuffle vector
unsigned long long val;
unsigned long long temp;
for (unsigned long long j = 0; j < v.size(); ++j)
{
val = rand() % v.size();
temp = v[j];
v[j] = v[val];
v[val] = temp;
}
 
I get the following warning for all 4 statements in the last for loop:
 
warning C4244: 'argument': conversion from 'unsigned __int64' to 'unsigned int', possible loss of data
 
I do not understand. Aren't all of the operands unsigned long long?
Ian Collins <ian-news@hotmail.com>: Nov 29 05:30PM +1300

On 11/29/16 04:55 PM, Bob Langelaan wrote:
 
> I get the following warning for all 4 statements in the last for loop:
 
> warning C4244: 'argument': conversion from 'unsigned __int64' to 'unsigned int', possible loss of data
 
> I do not understand. Aren't all of the operands unsigned long long?
 
The warning as at which line?
 
--
Ian
Bob Langelaan <bobl0456@gmail.com>: Nov 28 08:54PM -0800

On Monday, November 28, 2016 at 7:55:30 PM UTC-8, Bob Langelaan wrote:
 
> I get the following warning for all 4 statements in the last for loop:
 
> warning C4244: 'argument': conversion from 'unsigned __int64' to 'unsigned int', possible loss of data
 
> I do not understand. Aren't all of the operands unsigned long long?
 
All 4 lines in the lower for loop. Some other lines as well.
"Christopher J. Pisz" <cpisz@austin.rr.com>: Nov 28 10:57PM -0600

On 11/28/2016 9:55 PM, Bob Langelaan wrote:
 
> I get the following warning for all 4 statements in the last for loop:
 
> warning C4244: 'argument': conversion from 'unsigned __int64' to 'unsigned int', possible loss of data
 
> I do not understand. Aren't all of the operands unsigned long long?
 
What type is i?
What type does std:vector::size return?
What is size_type when you compile for 32 bits?
 
What type is val?
What type does rand() return?
What type does std::vector::size return?
What is size_type when you compile for 32 bits?
 
You can static_cast away the problem when you are sure a variable on one
side will always fall withing the range of the variable on the other. If
you aren't sure, check first, handle error if not, and then static_cast.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Nov 29 06:53AM +0100

On 29.11.2016 04:55, Bob Langelaan wrote:
> v[j] = v[val];
> v[val] = temp;
> }
 
You're compiling this with 32-bit Visual C++, or compatible compiler,
where `size_t` is a 32-bit unsigned type.
 
The size argument of `vector` constructor, as well as the index argument
of `vector::operator[]`, are `size_t`.
 
So your `unsigned long long` (which the standard requires to be at least
a 64-bit type) is converted down to `size_t`, and the compiler informs
you that that conversion can be lossy, can lose information.
 
• • •
 
The fix is not simple, except to use the 64-bit compiler.
 
Here's the program coded up with more sensible types:
 
[code]
#include <stddef.h> // std::ptrdiff_t
#include <algorithm> // std::swap
#include <vector> // std::vector
#include <iostream> // std::(cout, endl)
using namespace std;
 
using Size = ptrdiff_t;
 
template< class Container >
auto n_items_of( Container const& c )
-> Size
{ return c.size(); }
 
auto main()
-> int
{
int const n = 10000;
 
//Create vector of size n and initialize to 1 to n
vector<int> v{ n };
for( int i = 1; i < n_items_of( v ); ++i )
{
v[i] = i;
}
 
//Shuffle vector
for( int i = 0; i < n_items_of( v ); ++i )
{
int const j = rand() % v.size();
swap( v[i], v[j] );
}
}
[/code]
 
In general, just use `int`, the natural integer type for the platform,
unless there is a very good, compelling reason to use some other type.
 
• • •
 
The `n_items_of` function here avoids warnings about comparison of
signed/unsigned, and in other contexts avoids unintended wrap-around
conversions of number values in expressions that use collection sizes.
 
An overload of `n_items_of` for raw arrays can look like this:
 
template< class Item, size_t n >
auto n_items_of( Item (&)[n] )
-> Size
{ return n; }
 
(In C++17 this can be expressed in terms of `std::size`.)
 
The template parameter is `size_t` instead of `ptrdiff_t` in order to
support compilation with g++.
 
 
Cheers & hth.,
 
- Alf
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Nov 29 06:58AM +0100

On 29.11.2016 06:53, Alf P. Steinbach wrote:
> {
> v[i] = i;
> }
 
Sorry, I should have replaced your loop here with std::iota, <url:
http://en.cppreference.com/w/cpp/algorithm/iota>.
 
Cheers!,
 
- Alf
Popping mad <rainbow@colition.gov>: Nov 29 05:44AM

On Mon, 28 Nov 2016 17:18:19 +0000, Ike Naar wrote:
 
 
> In the constructor for ThreadedTree, some members of the root node are not
> initialized, such as root_->data and root->righttThread, but the values of
> those members are used in insert().
 
 
try nullptr on them, perhaps.
Ramine <ramine@1.1>: Nov 28 09:40PM -0500

Hello....
 
Read this:
 
The Functional Revolution in C++
 
https://bartoszmilewski.com/2014/06/09/the-functional-revolution-in-c/
 
I don't agree with Bartosz Milewski, because Bartosz has a binary view
on this subject, because i think it is not just black and white,
because Bartosz Milewski seems to imply that Haskel is the solution
and functional programming because of purity of functions of Haskel is
the solution for composability, but as i said we have to agree that
what consists of a sufficient solution also, Bartosz Milewski is right
that the functional language Haskel because its purity of functions
avoids side effects and allows composability, but we have to agree
on what is a sufficient solution , because i have implied in my previous
post that a sufficient solution is also this:
 
because the presence today of transactional memory that avoids
deadlock and livelock and race conditions is able to provide
us with a tool that solves problems of parallelism
, and it allows composability, and this is mandatory and i think
it is like sufficient for complex systems, so i don't think that purity
of functions of Haskel or functional programming is mandatory, so
i think that Object oriented programming will be still
our prefered tool in the future.
 
The strictness and purity of functions of Haskel is good for
composability and safe-critical systems.
 
But Object oriented programming with transactional memory and
with other tools for safe-critical systems is i think a sufficient tool
that is good for composability and safe-critical systems.
 
So i don't think that functional programming is mandatory,
so i think that object oriented programming is great and will be still
here in the future.
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: Nov 28 09:19PM -0500

Hello,
 
This was my last post about programming in general in this C++ group.
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: Nov 28 09:06PM -0500

Hello..
 
The strictness and purity of functions of Haskel is good for
composability and safe-critical systems.
 
But Object oriented programming with transactional memory and
with other tools for safe-critical systems is i think a sufficient tool
that is good for composability and safe-critical systems.
 
So i don't think that functional programming is mandatory,
so i think that object oriented programming is great and will be still
here in the future.
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: Nov 28 08:45PM -0500

Hello..
 
About functional programming and object oriented programming...
 
I am coming from a long road of software development..
 
But when i read on internet about functional programming such us
Haskel, they seems to imply that since purity of functions
in Haskel avoids side effects and allows composability in
the presence of parallelism, so functional programming is not avoidable,
but i think that there reasoning is not correct,
because the presence today of transactional memory that avoids
deadlock and livelock and race conditions is able to provide
us with a tool that solves problems of parallelism
, and it allows composability, and this is mandatory and i think
it is like sufficient for complex systems, so i don't think that purity
of functions of Haskel or functional programming is mandatory, so
i think that Object oriented programming will be still
our prefered tool in the future.
 
 
Thank you,
Amine Moulay Ramdane.
woodbrian77@gmail.com: Nov 28 03:30PM -0800

On Monday, November 28, 2016 at 3:44:58 PM UTC-6, Vir Campestris wrote:
> > compilation. Whatever they have done is closed source and in beta test.
 
> Is that even legal? Surely Clang's licence requires you to publish
> derived works? (asd no, I haven't checked)
 
This is from Pirkei Avot (Sayings of the fathers/sages):
 
"There are four character types among people. One who says, 'What's mine is mine and what's yours is yours' is of average character, and some say, this is the character of Sodom.
[One who says] 'What's mine is yours and what's yours is mine' is unlearned
[One who says] 'What's mine is yours and what's yours is yours' is pious.
[One who says] 'What's yours is mine and what's mine is mine' is wicked."
 
As Richard points out Clang doesn't try to strangle others
who would dare to think that they should be free to profit
from their work. The Clang license is generous.
 
Does anyone recall how I've said for years that what they
are doing (making the compiler a server) is a good idea?
Sorry to honk my own horn again, but I suggested this with
GCC before Clang existed.
 
 
Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
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:
Subscribe to: Comments (Atom)