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:

Post a Comment

Subscribe to: Post Comments (Atom)