Tuesday, June 9, 2015

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

Doug Mika <dougmmika@gmail.com>: Jun 09 12:10PM -0700

I get the following error:
 
welcome.cc: In function 'void pause_thread(int)':
welcome.cc:8:8: error: 'std::this_thread' has not been declared
std::this_thread::sleep_for(std::chrono::seconds(n));
 
when I try to compile the following simply thread example.
 
// example for thread::join
#include <iostream> // std::cout
#include <thread> // std::thread, std::this_thread::sleep_for
#include <chrono> // std::chrono::seconds

void pause_thread(int n)
{
std::this_thread::sleep_for(std::chrono::seconds(n));
std::cout << "pause of " << n << " seconds ended\n";
}

int main()
{
std::cout << "Spawning 3 threads...\n";
std::thread t1(pause_thread,1);
std::thread t2(pause_thread,2);
std::thread t3(pause_thread,3);
std::cout << "Done spawning threads. Now waiting for them to join:\n";
t1.join();
t2.join();
t3.join();
std::cout << "All threads joined!\n";
 
return 0;
}
 
 
 
 
Could someone hint at why?
 
Thanks to all in advance.
(Using MinGW with the following command:
g++ -std=c++11 -c -g -MMD -MP -MF "build/Debug/MinGW-Windows/welcome.o.d" -o build/Debug/MinGW-Windows/welcome.o welcome.cc)
Ian Collins <ian-news@hotmail.com>: Jun 10 07:13AM +1200

Doug Mika wrote:
 
> welcome.cc: In function 'void pause_thread(int)':
> welcome.cc:8:8: error: 'std::this_thread' has not been declared
> std::this_thread::sleep_for(std::chrono::seconds(n));
 
Your compiler is too old? Which version are you using?
 
--
Ian Collins
Doug Mika <dougmmika@gmail.com>: Jun 09 12:14PM -0700

On Tuesday, June 9, 2015 at 2:13:29 PM UTC-5, Ian Collins wrote:
 
> Your compiler is too old? Which version are you using?
 
> --
> Ian Collins
4.8.1
Doug Mika <dougmmika@gmail.com>: Jun 09 12:20PM -0700

On Tuesday, June 9, 2015 at 2:14:34 PM UTC-5, Doug Mika wrote:
 
> > --
> > Ian Collins
> 4.8.1
 
Perhaps I should mention that compiling the code in:
http://www.tutorialspoint.com/compile_cpp11_online.php
 
give me the following error message:
terminate called after throwing an instance of 'std::system_error'
what(): Enable multithreading to use std::thread: Operation not permitted
Aborted (core dumped)
 
Which begs the question, where is the setting to enable threading, and is there a flag that is needed in MinGW to enable threading?
scott@slp53.sl.home (Scott Lurndal): Jun 09 01:59PM


>> Because size_t is unsigned, this is an infinite loop.
 
>ssize_t is a signed version of size_t. It is not part of the C
>standards, but is (I think) in posix.
 
It was added to POSIX/SUS to accomodate interfaces that returned
a negative value of one on error a quarter of a century ago.
 
Now the standard actually requires ssize_t to support the range
[-1, {SSIZE_MAX}], but in practice, no modern implementation
supports only a single negative value (this wording was added
due to one, no longer available, implementation when we added
ssize_t), and in any case, that constraint is sufficient for the
aforementioned loop.
 
The competent programmers at microsoft defined it as unsigned in Visual Studio 2010,
which may have put some people off using it (subsequently fixed).
bartek <bartek@gmail.com>: Jun 09 04:05PM +0200

On 05.06.2015 20:39, Doug Mika wrote:
>> unsigned type. An unsigned variable will always be >= 0.
 
>> Wouter
 
> But of course, for the loop to stop we need to fall below 0,
 
 
Not nesesery
 
for (size_t i = strlen (str) - 1; i < strlen (str); i--){
...
}
 
;-)
 
bartekltg
asetofsymbols@gmail.com: Jun 09 07:18AM -0700

Mr Flibble wrote:"
 
The solution is the arrow idiom but can you spot the arrow?
 
#include <iostream>
#include <string>
 
int main()
{
std::string str = "Hello, World!";
for (size_t i = str.size(); i--> 0;)
{
std::cout << str[i];
}
std::cout << std::endl;
}"
 
int main()
{std::string str = "Hello, World!";
size_t i, j;
i=str.size();
if(i)
for( --i; ; --i)
{std::cout << str[i];
if(i==0) break;
}
legalize+jeeves@mail.xmission.com (Richard): Jun 09 05:00PM

[Please do not mail me a copy of your followup]
 
David Brown <david.brown@hesbynett.no> spake the secret code
 
>ssize_t is a signed version of size_t. It is not part of the C
>standards, but is (I think) in posix.
 
Well, this is a C++ newsgroup, not C. So please, stop posting C code.
 
Also, POSIX is not C and is not C++. POSIX is like Win32.
 
If I posted code that only worked in Win32, you can be sure some people
would complain about my code not being portable. The same goes for
POSIX.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
scott@slp53.sl.home (Scott Lurndal): Jun 09 05:40PM


>>ssize_t is a signed version of size_t. It is not part of the C
>>standards, but is (I think) in posix.
 
>Well, this is a C++ newsgroup, not C. So please, stop posting C code.
 
You know, C is still a subset of C++; and it always will be, purists
like yourself notwithstanding.
David Brown <david.brown@hesbynett.no>: Jun 09 08:00PM +0200

On 09/06/15 19:00, Richard wrote:
 
>> ssize_t is a signed version of size_t. It is not part of the C
>> standards, but is (I think) in posix.
 
> Well, this is a C++ newsgroup, not C. So please, stop posting C code.
 
Neither I nor anyone else has posted C here - it is all C++. Try asking
a C compiler to accept "str::count << str[i]".
 
 
I suppose I could have written "ssize_t is not part of the C++
standards", but C++ gets these sorts of thing from C.
 
> Also, POSIX is not C and is not C++. POSIX is like Win32.
 
No, POSIX is widely supported across a range of platforms, including
Windows - Win32 is just for Windows. And POSIX and POSIX headers can be
used with C++, even if they were originally made for C.
 
You are correct that POSIX is not C or C++ - that is, in fact, exactly
what I wrote. I don't see why you feel the need to repeat it.
 
 
> If I posted code that only worked in Win32, you can be sure some people
> would complain about my code not being portable. The same goes for
> POSIX.
 
Non-portable code can be relevant in this newsgroup - but should usually
be marked to show that depends on additional features. Perhaps Scott
didn't realise that ssize_t was not portable.
 
But rather than moan and complain about the use of non-standard types,
and rather than simply misunderstanding the post (as you did by
suggesting Scott meant "size_t" instead of "ssize_t"), you could do like
I did - just point out the facts to clarify the situation.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jun 09 08:19PM +0100

On Tue, 09 Jun 2015 13:59:41 GMT
 
> The competent programmers at microsoft defined it as unsigned in
> Visual Studio 2010, which may have put some people off using it
> (subsequently fixed).
 
ssize_t is poorly implemented in POSIX and has rightly not been
incorporated into either C or C++.
 
Take the most basic of POSIX functions, namely read(). It takes a
second count argument of type size_t, indicating the maximum number of
bytes that the read buffer can take, and returns a ssize_t type
representing (if positive) the number of bytes read or -1 in case of
error. Because std::size_t/SIZE_MAX is required by the C and C++
standards to be wide enough to take the maximum addressable size of an
object, this means that a call to read() with a count argument greater
than SSIZE_MAX and less than SIZE_MAX will result in an overrun
generating undefined behaviour (§4.7/3). So the typing actually
operates to reduce safety rather than increase it.
 
ssize_t should generally be avoided where not mandated as part of a
POSIX interface that a program is obliged to use.
 
Chris
Thomas Richter <thor@math.tu-berlin.de>: Jun 09 04:40PM +0200

On 09.06.2015 13:32, Öö Tiib wrote:
 
> The 'struct' and 'class' mean same thing in context of forward declaration.
> I am not sure why such inconsistent usage is permitted but AFAIK it
> must compile and run.
 
Unfortunately, this bug has a long tradition in VS, it exists at least
since VS6 (ancient, pre-dates ANSI C++). Despite being a bug, I would at
least consider it reasonable to use "class" and "struct" consistently,
and that a compiler would emit a warning in case it is not - even though
C++ allows the mixture.
 
 
Greetings,
Thomas
legalize+jeeves@mail.xmission.com (Richard): Jun 09 05:01PM

[Please do not mail me a copy of your followup]
 
Thomas Richter <thor@math.tu-berlin.de> spake the secret code
>> must compile and run.
 
>Unfortunately, this bug has a long tradition in VS, it exists at least
>since VS6 (ancient, pre-dates ANSI C++). Despite being a bug, [...]
 
I don't think it's a bug so much as implementation defined behavior.
The compiler has pretty broad latitude in deciding how to mangle names.
 
I'd love to know which part of the standard prohibits this behavior or
declares it undefined behavior.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
David Brown <david.brown@hesbynett.no>: Jun 09 08:15PM +0200

On 09/06/15 19:01, Richard wrote:
> The compiler has pretty broad latitude in deciding how to mangle names.
 
> I'd love to know which part of the standard prohibits this behavior or
> declares it undefined behavior.
 
The nearest I found is in section 7.1.6.3 of N3797 (C++14 standards),
under "Elaborated type specifiers" :
 
 
The class-key or enum keyword present in the elaborated-type-specifier
shall agree in kind with the declaration to which the name in the
elaborated-type-specifier refers. This rule also applies to the form of
elaborated-type-specifier that declares a class-name or friend class
since it can be construed as referring to the definition of the class.
Thus, in any elaborated-type-specifier, the enum keyword shall be used
to refer to an enumeration (7.2), the union class-key shall be used to
refer to a union (Clause 9), and either the class or struct class-key
shall be used to refer to a class (Clause 9) declared using the class or
struct class-key.
 
 
That doesn't seem precise enough wording to decide the rule.
Bo Persson <bop@gmb.dk>: Jun 09 08:26PM +0200

On 2015-06-09 20:15, David Brown wrote:
> shall be used to refer to a class (Clause 9) declared using the class or
> struct class-key.
 
> That doesn't seem precise enough wording to decide the rule.
 
We have to know that a 'class' is declared using a 'class-key', which is
one of class, struct, or union.
 
The intention is that
 
"either the class or struct class-key shall be used to refer to a class
(Clause 9) declared using the class or struct class-key. "
 
should tell us that, unlike enum and union, "either [...] class or
struct" can be used to refer to a non-union class.
 
 
 
Bo Persson
Doug Mika <dougmmika@gmail.com>: Jun 09 10:33AM -0700

On Monday, June 8, 2015 at 4:44:56 PM UTC-5, Mr Flibble wrote:
> return vector<C>(size);
> }
 
> /Flibble
 
That worked, much thanks, and it makes sense. But it leaves me wondering why then the following code has "typename C" and not merely "C" in the find_all function definition and inside of it? (code is taken from Stroustrup's book)
 
template<typename C, typename V>
vector<typename C::iterator> find_all(C& c, V v) //find all occurrences of v in c
{
vector<typename C::iterator> res;
for (auto p = c.begin(); p!=c.end(); ++p)
if (∗p==v) res.push_back(p);
return res;
}
red floyd <no.spam@its.invalid>: Jun 09 10:51AM -0700

On 6/9/2015 10:33 AM, Doug Mika wrote:
> if (∗p==v) res.push_back(p);
> return res;
> }
 
Because the compiler has no way of knowing that C::iterator is a type,
so you need to tell it that.
Victor Bazarov <v.bazarov@comcast.invalid>: Jun 09 01:52PM -0400

On 6/9/2015 1:33 PM, Doug Mika wrote:
> [..] it leaves me wondering why then the following code has
> "typename
C" and not merely "C" in the find_all function definition and inside of
it? (code is taken from Stroustrup's book)
 
It's not "typename C". It's "typename C::iterator". It's a hint to the
compiler that the 'iterator' member of 'C' *is a typename*.
 
> if (∗p==v) res.push_back(p);
> return res;
> }
 
V
--
I do not respond to top-posted replies, please don't ask
Doug Mika <dougmmika@gmail.com>: Jun 09 10:55AM -0700

On Tuesday, June 9, 2015 at 12:34:08 PM UTC-5, Doug Mika wrote:
> if (∗p==v) res.push_back(p);
> return res;
> }
 
The following for example will not work: (but why do we need typename C here and just C previously?)
 
//this won't compile, "typename" is needed, but why is it needed here but
//not previously?
template<typename C, typename V>
vector<C::iterator> find_all(C& c, V v)
{
vector<C::iterator> res;
for(auto p = c.begin(); p!=c.end(); ++p)
if(*p==v) res.push_back(p);
return res;
}
Doug Mika <dougmmika@gmail.com>: Jun 09 10:57AM -0700

On Tuesday, June 9, 2015 at 12:52:29 PM UTC-5, Victor Bazarov wrote:
 
> V
> --
> I do not respond to top-posted replies, please don't ask
 
So what would be the rule, when do I need typename C and when do I just write C? It should be obvious that inside the <> brackets is always a type, what else could it be?
Victor Bazarov <v.bazarov@comcast.invalid>: Jun 09 02:02PM -0400

On 6/9/2015 1:55 PM, Doug Mika wrote:
> if(*p==v) res.push_back(p);
> return res;
> }
 
A bit impatient, aren't you?
 
It's good that you tried this. It's bad that you don't actually reach
for a decent book and study instead of just posting here. Find a copy
of "C++ Templates" by Vandevoorde and Josuttis, and perhaps you will get
more questions answered than raised by your attempts.
 
C::iterator is what's known as a "dependent name". In order for the
compiler to be able to do the syntactic analysis of the template, it has
to know what 'C::iterator' is. We need to tell it that it's a typename,
and not, say, a non-static member function. Otherwise the compiler will
need to instantiate your template before it can do the syntactic
analysis, which is not good, and probably leads to chicken-and-egg type
of problems.
 
V
--
I do not respond to top-posted replies, please don't ask
Victor Bazarov <v.bazarov@comcast.invalid>: Jun 09 02:05PM -0400

On 6/9/2015 1:57 PM, Doug Mika wrote:
>> I do not respond to top-posted replies, please don't ask
 
> So what would be the rule, when do I need typename C and when do I
> just write C?
 
Get a damn book and study. You can't expect a single rule to apply to
all freaking cases in the entire language now, can you?
 
> It should be obvious that inside the <> brackets is
> always a type, what else could it be?
 
It's *not* always a type. It can be an object. It can be a constant.
It can be a template. It can be a function pointer.
 
Let me spell this out for you: G-E-T A B-O-O-K A-N-D S-T-U-D-Y!
 
V
--
I do not respond to top-posted replies, please don't ask
legalize+jeeves@mail.xmission.com (Richard): Jun 09 05:03PM

[Please do not mail me a copy of your followup]
 
Hongyi Zhao <hongyi.zhao@gmail.com> spake the secret code
>including the data format depicted here:
 
>http://aria2.sourceforge.net/manual/en/html/technical-notes.html
 
>Could you please give me some snipped codes for this purpose?
 
If you want people to do your work for them, it is customary to pay them.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Victor Bazarov <v.bazarov@comcast.invalid>: Jun 09 01:54PM -0400

On 6/9/2015 1:03 PM, Richard wrote:
 
>> http://aria2.sourceforge.net/manual/en/html/technical-notes.html
 
>> Could you please give me some snipped codes for this purpose?
 
> If you want people to do your work for them, it is customary to pay them.
. ^^^^^^^^^^
I think you meant "for you". ;-)
 
V
--
I do not respond to top-posted replies, please don't ask
drew@furrfu.invalid (Drew Lawson): Jun 09 05:39PM

In article <13819f2e-c2cd-4afd-990c-e983d69b9f81@googlegroups.com>
> iter != items.end();
 
>My question is about the third, iter = items.upper_bound(*iter).
 
>In a general for loop, the third is the step size for the variable.
 
The third expression in the 'for' is most commonly an increment or
decrement, but that is not the only thing that it can be. It can
be anything that is useful.
 
>Here, I do not see
 
>items.upper_bound(*iter)
 
>is a step from the std::multiset documentation.
 
It has the effect of a step, but not a fixed size step.
Multiset can have multiple objects that compare as equal.
The effect of
iter = items.upper_bound(*iter)
 
is to move to the next item which is not equal to the current one.
It is skipping duplicates.
 
 
http://www.cplusplus.com/reference/set/multiset/upper_bound/
 
Returns an iterator pointing to the first element in the container
which is considered to go after val.
 
 
 
 
--
Drew Lawson For it's not the fall, but landing,
That will alter your social standing
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)