Thursday, June 11, 2015

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

Doug Mika <dougmmika@gmail.com>: Jun 11 09:33AM -0700

Could someone quickly confirm, in the program below, we need to join() the threads because, amongst other things, the functions running inside the threads store data in a variable that is itself inside the main() thread, correct?
 
void f(const vector<double>& v, double* res);//take input from v; place //result in *res
class F {
public:
F(const vector<double>& vv, double* p) :v{vv}, res{p} { }
void operator()(); // place result in *res
private:
const vector<double>& v; //source of input
double* res; //target for output
};
 
int main() {
vector<double> some_vec;
vector<double> vec2;
// ...
double res1;
double res2;
thread t1 {f,some_vec,&res1}; //f(some_vec,&res1) executes in a separate //thread
thread t2 {F{vec2,&res2}}; // F{vec2,&res2}() executes in a separate //thread
t1.join();
t2.join();
cout << res1 << ' ' << res2 << '\n';
}
Victor Bazarov <v.bazarov@comcast.invalid>: Jun 11 12:59PM -0400

On 6/11/2015 12:33 PM, Doug Mika wrote:
> Could someone quickly confirm, in the program below, we need to
> join()
the threads because, amongst other things, the functions running inside
the threads store data in a variable that is itself inside the main()
thread, correct?
> t2.join();
> cout << res1 << ' ' << res2 << '\n';
> }
 
The 'join' makes the calling function block until the thread finishes,
no? If you don't use both 'join' calls, then the 'cout' will get the
output before the threads will have a chance to complete execution, I
believe. If you don't care about that, you don't need to 'join'. If
you care to wait for the results to be calculated, *then* output them,
then you need to 'join'.
 
V
--
I do not respond to top-posted replies, please don't ask
"K. Frank" <kfrank29.c@gmail.com>: Jun 11 10:18AM -0700

Hello Doug!
 
On Thursday, June 11, 2015 at 12:33:23 PM UTC-4, Doug Mika wrote:
> Could someone quickly confirm, in the program below, we need to join() the threads because, amongst other things, the functions running inside the threads store data in a variable that is itself inside the main() thread, correct?
 
I wouldn't phrase it quite the way you do.
 
As you probably know, thread::join() causes the
calling thread (in your case the "main" thread)
to pause its execution until the thread you're
joining has completed -- that is, until the thread
function of the thread with which you're joining has
exited.
 
In your specific example there are three reasons
you want thread::join (or some other synchronization
mechanism):
 
1) You don't want to access res1 and res2 until t1
and t2 are done doing there stuff. So you wait for
t1 and t2 to finish (i.e., join them).
 
2) res1 and res2 are variables local to the function
"main" (on the stack). You don't want them to go out
of scope -- i.e., you don't want main to exit -- until
t1 and t2 are done. Otherwise t1 and t2 would be
accessing and modifying stack space that might be being
used for some other purpose.
 
3) t1 and t2 are *also* stack variables local to main.
You *really* don't want them to go out of scope until
t1 and t2 (more precisely, the execution of t1's and
t2's thread functions) are done.
 
Now reasons 2 and 3 are kind of hidden by the fact that
when main completes (and its local variables go out of
scope) your program exits, so you might not see any
corruption that has occurred (but you might).
 
Also, I wouldn't say that res1, for example, is "a
variable that is itself inside the main() thread."
res1 and res2 are variables that are in the address
space of your program (your multi-threaded process).
(They happen to be on the stack, but that is part
of your process's address space.) As such they are
available to all threads in your process. (There is
such a thing as "thread-local storage," but you're
not using it.)
 
It is true that res1 and res2 are variables local to
the function "main," but (in c++) there is no notion
(not counting thread-local storage) of specific variables
belonging to specific threads. "main" is a special
function, but, in general, any given function can be
called by many different threads.
 
It's not exactly wrong to say that the variable res1
is "inside the main() thread," but it's an odd way of
putting, and is more likely to be confusing than
helpful.
 
 
By the way (following up on an earlier post of yours)
what compiler / version and command line did you end
up using for exploring std::thread?
 
 
Happy Multi-Threaded Hacking!
 
 
K. Frank
 
 
> t2.join();
> cout << res1 << ' ' << res2 << '\n';
> }
 
 
P.S. I haven't tested it or looked at it that closely, but
this code of yours looks correct to me.
Paul <pepstein5@gmail.com>: Jun 11 10:11AM -0700

The below appears (to me) to contain an error. Please could someone confirm if there's an error? Otherwise, I need to review my understanding of some basics. Thank you. I would have thought that &x denotes the address of a variable and is therefore not an lvalue. This is not given as an error in the online errata list.
 
Thanks again for your help.
 
BEGIN QUOTE
 
vector<string> arr( 3 );
const int x = 2;
int y;
 
...
 
int z = x + y;
string str = "foo";
vector<string> *ptr = &arr;
 
With these declarations, arr, str, arr[x], &x, y, z, ptr, *ptr, (*ptr)[x] are all lvalues.
END QUOTE
Joe <no.spam@noemail.com>: Jun 11 11:39AM -0500

I'd like to know if it's possible to initialize a class w/o passing in a
type to the template, just use the base class since I don't need any of
the template members. I thought I read that passing in null pointers was
ok, but didn't quite understand the const expression part of it.
 
template <class MyType>
class MyClass
{
private:
std::shared_ptr<MyType> tvar; // <---- don't need to use
 
public:
MyClass() { } // <--------- use this ctor
MyClass(std::shared_ptr<MyType> myT) : tvar(myT) { }
};
 
So to create a simple object of MyClass, I tried something like this.
 
std::unique_ptr<MyType<nullptr>> mt;
mt = std::unique_ptr<MyType<nullptr>> { new MyClass(); };
Victor Bazarov <v.bazarov@comcast.invalid>: Jun 11 01:02PM -0400

On 6/11/2015 12:39 PM, Joe wrote:
> I'd like to know if it's possible to initialize a class w/o passing in a
> type to the template,
 
No. Templates are *instantiated* when their *arguments* have specific
values. If the argument is a type, it needs to be specified in order to
instantiate the template.
 
> just use the base class since I don't need any of
> the template members.
 
By definition, you do. You're free to rewrite your program in such a
way that it doesn't have a template, and instead has a class which you
then use. But a class template *needs* its argument to become a class.
 
> I thought I read that passing in null pointers was
> ok, but didn't quite understand the const expression part of it.
 
Huh?
 
 
> So to create a simple object of MyClass, I tried something like this.
 
> std::unique_ptr<MyType<nullptr>> mt;
> mt = std::unique_ptr<MyType<nullptr>> { new MyClass(); };
 
This is wrong on several levels. Perhaps you could start over by
explaining what exactly you're trying to accomplish.
 
V
--
I do not respond to top-posted replies, please don't ask
"Öö Tiib" <ootiib@hot.ee>: Jun 11 10:06AM -0700

On Thursday, 11 June 2015 19:39:02 UTC+3, Joe wrote:
 
> So to create a simple object of MyClass, I tried something like this.
 
> std::unique_ptr<MyType<nullptr>> mt;
> mt = std::unique_ptr<MyType<nullptr>> { new MyClass(); };
 
'MyType<nullptr>' can't compile. 'MyType' expects a type as
template argument but 'nullptr' is a keyword that denotes a
value not type.
 
Perhaps you did mean 'MyType<std::nullptr_t>'?
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jun 09 08:52PM +0100

On Tue, 09 Jun 2015 20:26:57 +0200
> 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.
 
I have come across this outside VS when specializing std::hash for a
type which might be used as the key for an unordered container. The
standard does not specify whether the std::hash<T> class template type
is defined using the 'class' or 'struct' keyword. §20.8.12 of the C++11
standard uses the 'struct' keyword when specifying the specializations
required by the standard, but only requires that any given
specialization must comprise a 'class template'.
 
clang exhibits the annoying behaviour of emitting a bogus warning if
you provide a hash specialization using a different keyword from the
one which happens to be used by the C++ standard library in question
for std::hash<T>, which means that if you use clang with a recent
version of libstdc++ you get the warning when using the 'struct' keyword
instead of the 'class' keyword for a specialization. I am glad to say
that gcc does not do this.
 
Chris
Mel <mel@zzzzz.com>: Jun 05 09:50PM +0300

On Fri, 5 Jun 2015 11:25:45 -0700 (PDT), Doug Mika
> I found this on a discussion group, and it said that the following
will cause an infinite loop, but why?
 
 
> for (size_t i = strlen (str) - 1; i >= 0; i--){
> ...
> }
 
size_t is unsigned...
 
--
Press any key to continue or any other to quit
Mel <mel@zzzzz.com>: Jun 08 04:03PM +0300

On Mon, 8 Jun 2015 05:52:49 -0700 (PDT), gwowen <gwowen@gmail.com>
wrote:
> On Friday, June 5, 2015 at 9:41:32 PM UTC+1, Mr Flibble wrote:
> > On 05/06/2015 19:25, Doug Mika wrote:
> > > I found this on a discussion group, and it said that the
following will cause an infinite loop, but why?
 
> for (size_t i = str.size(); i+1 > 0; --i)}
 
 
> }
 
 
> even better than that monstrosity. "Idioms" that arise to work
around braindead design choices (e.g. an unsigned type as a
decreasing index).
 
Nope, it is not better as indice have to be subtracted..
 
--
Press any key to continue or any other to quit
David Brown <david.brown@hesbynett.no>: Jun 08 03:22PM +0200

On 08/06/15 15:03, Mel wrote:
> around braindead design choices (e.g. an unsigned type as a decreasing
> index).
 
> Nope, it is not better as indice have to be subtracted..
 
Do you mean you need to write this?
 
for (size_t i = str.size(); i + 1 > 0; --i) {
std::cout << str[i - 1];
}
 
It's a little inconvenient, but IMHO it is still better than the "arrow
idiom". But for such code, I'd rather write:
 
size_t i = str.size();
while (i--) {
std::cout << str[i];
}
 
(Yes, I know that "--i" is more common in C++, and "i--" looks like C -
but it's find to use it when it makes sense.)
 
If I see a "for" loop that doesn't have all three sections (or even
worse, has multiple comma-separated sub-sections), I usually switch to a
while loop.
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>
ram@zedat.fu-berlin.de (Stefan Ram): Jun 05 05:36PM

>- the int-to-string conversion is a bit heavyweight operation and will
>probably dominate in the timings. Your profiler will tell you more exactly.
 
#include <iostream> // ::std::cout
#include <ostream> // <<
#include <string>
 
static constexpr char const * string[] =
{ "0", "1", "2", "3", "4", "5", "6" };
 
static inline char const * to_string
( int const i )
{ return i < 7 ? string[ i ] :
::std::to_string( i ).c_str(); }
 
static void test( ::std::ostream & out )
{ out << to_string( 0 )<< '\n';
out << to_string( 1 )<< '\n';
out << to_string( 2 )<< '\n';
out << to_string( 20 )<< '\n';
out << to_string( 40 )<< '\n'; }
 
int main(){ test( ::std::cout ); }
ram@zedat.fu-berlin.de (Stefan Ram): Jun 08 03:21PM

>Ugh. Even:
>for (size_t i = str.size(); i+1 > 0; --i)}
 
#include <climits>
 
And what is the value of i+1,
when str.size() == SIZE_MAX?
Vir Campestris <vir.campestris@invalid.invalid>: Jun 05 09:46PM +0100

On 05/06/2015 06:37, Lőrinczy Zsigmond wrote:
> It's just a provocation from a brain-dead troll
> that should be ignored, innit?
 
In future please do. Don't post it back.
Paavo Helde <myfirstname@osa.pri.ee>: Jun 05 02:26PM -0500

Paul <pepstein5@gmail.com> wrote in
 
> Uncompression is uniquely determined by the constraint,
> given in the comments, that inputs only contain chars that are letters
> of the English alphabet.
 
OK, I had overlooked that. Yes, if each input byte contains less than 6
bits of information, then it can always be compressed into a shorter
length.
 
> in different ways. I don't understand why this would be any type of
> problem -- we would simply have a non-injective function. Nobody said
> that we wanted to uncompress strings.
 
In that case 'return "";' should be the fastest implementation.
 
 
> If you believe that it sometimes results in a runtime error, please
> can you give inputs that cause incorrect output? If you believe that
> this is inefficient, please can you explain why?
 
No, I somehow assumed all bits in the input are used, and if it were so
then this statement would make it impossible to have lossless
compression.
 
Cheers
Paavo
"Skybuck Flying" <skybuck2000@hotmail.com>: Jun 05 10:41PM +0200

What I find lacking of this/my tool is the inability to find stuff,
declarations, vars, fields, structs, etc.
 
Maybe some day I can add some pascal/c/c++ parsers to it which could be used
for finding stuff.
 
That would make this tool even more usefull for quick browsing/examining
files of source code.
 
(Fortunately, meanwhile I find a nice rainbow around the pot of gold which
sweetens it :))
 
Bye,
Skybuck.
"Skybuck Flying" <skybuck2000@hotmail.com>: Jun 05 04:21PM +0200

Hello,
 
807 megabytes of C/CPP source code was leaked onto the internet, I want to
analyze/explore it real fast so an much desired update to Skybuck's ODE tool
was needed (possibly the fastest source code browser and editor in the world
! =D)
 
So nice handy new features:
 
1. C/CPP highlighting (next to the already existing delphi/pascal
highlighting)
2. Super fast source code browser thanks to key up, key down support in tree
view.
 
The rar file can be downloaded from here:
 
http://www.skybuck.org/Applications/SkybuckODE/
 
I think this is the first release of mine which has the bugs fixed...
version 0.09 had a bug in the rippling... let for an exercise for there
reader, version 0.10 was never released ?
 
So version 0.12 is your first chance to get your hands on some great
software.
 
Most of the greatness comes from TSynEdit/TSynCPP/TSynPas and
TVirtualTreeString.
 
And some handy dandy Skybuck code for folder rippling and so forth.
 
Unfortunately this will be a "closed source" release cause I have no time to
bother with uploading it to some versioning system like sourceforge or
whatever.
 
However any interested folks can send me a mail if you want the latest and
greatest source code. (It was compiled by using Delphi XE8 and GetIt build
in feature to download embar... TSynEdit and TVirtualTreeString, so far it
seems to work quite nicely.
 
However the application might sometimes produce an exception when it's
terminated... not sure if it will how up or if it's a problem or what the
cause of it is. so far it doesn't seem to severe... not bad for freeby ! ;)
 
Now hurry up... download it so you can enjoy fast source code browsing...
 
And here are some last hints for the source code leak:
 
ots
 
enozegar
 
^ read it backwards and google it and you might hit upon a pot of gold ! =D
 
Bye,
Skybuck =D
Paavo Helde <myfirstname@osa.pri.ee>: Jun 02 12:56AM -0500

Lane <software.research.development@gmail.com> wrote in news:mkjda812947
 
> I'm using a C api within the C++ MyClass. This works, but I'd like to be
> able to use the private fields (varX) within these callbacks. Is there
> anyway to make the callbacks look like class member functions?
 
(1) You can declare callback functions as friends.
 
(2) You can add public member functions to your class which are called by
the callback functions. A bit more tedious, but clearer in the long run.
 
The drawback with (2) is that these member functions are typically not
really "public". A way to cope with that is to add comments like
 
public: // implementation
 
and use some naming schema like Foo_impl() in the method names to indicate
these are not to be called willy-nilly.
 
The static member function approach suggested by another poster is similar
to (1), but a bit unportable (the static member function linkage may or may
not be compatible with the C linkage assumed by the C API). To be fully
portable one needs to use extern "C" callback functions with a C API, and
(static) member functions cannot be declared extern "C".
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jun 03 10:40PM +0100

On Wed, 03 Jun 2015 17:35:34 GMT
> }
 
> c_library_function_register_callback(callback_function, this);
 
> portable yet friendless.
 
You do not disagree. Classname::callback() must be public for this to
work. If Classname::callback() were protected or private,
callback_function() would need to be a friend.
 
Chris
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jun 03 10:50PM +0100

On Wed, 03 Jun 2015 12:18:29 -0500
> > are declared to have C language linkage, then there would be a name
> > clash.
 
> Is it anymore of a problem than it currently is with namespaces?
 
Not with named namespaces. As you suggest, a named namespace is ignored
for any function declared within the namespace with C language linkage,
leading (for those who don't know that) to the possibility of name
clashes between such functions declared with the same name within
different namespaces. However, in C++11/14 (but not C++98/03), unnamed
namespaces are effective for functions with C linkage in enforcing
internal linkage (that is, it has the same effect as applying the
static keyword).
 
The lesson: in C++11/14 do not declare functions within a named
namespace with C language linkage; and with C++98/03 don't do it within
an unnamed namespace either.
 
However, I was answering a question about why static member functions
cannot have C language linkage.
 
Chris
Paavo Helde <myfirstname@osa.pri.ee>: Jun 02 12:35AM -0500

fl <rxjwg98@gmail.com> wrote in
> public:
> Bar() { std::cout << "Bar's constructor" << std::endl; }
> };
 
Maybe they think something like:
 
class Bar {
private:
int i;
};
 
Bar a;
* (int*) &a = 42;
 
or
 
class Foo {
public:
int i;
};
 
class Bar: private Foo {};
 
Bar a;
((Foo*) &a)->i = 42;
 
If so, then the casts are not only violating the intended access rules,
but are also pretty fragile and unportable (as they assume a certain
memory layout).
gwowen <gwowen@gmail.com>: Jun 11 12:31AM -0700

On Wednesday, June 10, 2015 at 6:09:14 PM UTC+1, Mr Flibble wrote:
 
> In maths 1/0 is not infinity, 1/0 is undefined. In maths negative zeros
> don't exist. IEEE floating point is wrong.
 
> /Flibble
 
Sure, in \mathbb{R} it is undefined. But real mathematicians don't limit themselves to a single model of numbers, if other models are better for their purposes.
 
On the real projective line \mathbb{R}^*, you can absolutely have 1/0 = infinity. The numbers stop being a field of course, but IEEE floats aren't a field either.
 
Since IEEE floats can't reasonably model \mathbb{R} while the field axioms, a mathematician might very reasonably decide they might as well model the projective line instead.
"Öö Tiib" <ootiib@hot.ee>: Jun 11 12:58AM -0700

On Thursday, 11 June 2015 10:32:16 UTC+3, gwowen wrote:
 
> Sure, in \mathbb{R} it is undefined.
 
Are there Usenet clients that support LaTeX?
Some support Unicode ... u8"ℝ" <- tried to achieve u8"\u211D" .
gwowen <gwowen@gmail.com>: Jun 11 03:31AM -0700

On Thursday, June 11, 2015 at 8:58:14 AM UTC+1, Öö Tiib wrote:
 
> > Sure, in \mathbb{R} it is undefined.
 
> Are there Usenet clients that support LaTeX?
> Some support Unicode ... u8"ℝ" <- tried to achieve u8"\u211D" .
 
Not that I know of. I just used the LaTeX markup on the basis that anyone who cared about the projective real line and field axioms would just parse it mentally. FWIW: on the hated google group interace, that UTF-8 shows up correctly.
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)