Monday, June 13, 2016

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

jacobnavia <jacob@jacob.remcomp.fr>: Jun 13 10:21AM +0200

https://www.sciencedaily.com/releases/2016/06/160610140645.htm
 
Many with migraines have vitamin deficiencies, says study
Researchers uncertain whether supplementation would help prevent migraines
Date:
June 10, 2016
Source:
Cincinnati Children's Hospital Medical Center
Summary:
A high percentage of children, teens and young adults with migraines
appear to have mild deficiencies in vitamin D, riboflavin and coenzyme
Q10 -- a vitamin-like substance found in every cell of the body that is
used to produce energy for cell growth and maintenance.
 
 
A high percentage of children, teens and young adults with migraines
appear to have mild deficiencies in vitamin D, riboflavin and coenzyme
Q10 -- a vitamin-like substance found in every cell of the body that is
used to produce energy for cell growth and maintenance.
 
These deficiencies may be involved in patients who experience migraines,
but that is unclear based on existing studies.
 
"Further studies are needed to elucidate whether vitamin supplementation
is effective in migraine patients in general, and whether patients with
mild deficiency are more likely to benefit from supplementation," says
Suzanne Hagler, MD, a Headache Medicine fellow in the division of
Neurology at Cincinnati Children's Hospital Medical Center and lead
author of the study.
 
Dr. Hagler and colleagues at Cincinnati Children's conducted the study
among patients at the Cincinnati Children's Headache Center. She will
present her findings at 9:55 am Pacific time June 10, 2016 at the 58th
Annual Scientific Meeting of the American Headache Society in San Diego.
 
Dr. Hagler's study drew from a database that included patients with
migraines who, according to Headache Center practice, had baseline blood
levels checked for vitamin D, riboflavin, coenzyme Q10 and folate, all
of which were implicated in migraines, to some degree, by previous and
sometimes conflicting studies. Many were put on preventive migraine
medications and received vitamin supplementation, if levels were low.
Because few received vitamins alone, the researchers were unable to
determine vitamin effectiveness in preventing migraines.
 
She found that girls and young woman were more likely than boys and
young men to have coenzyme Q10 deficiencies at baseline. Boys and young
men were more likely to have vitamin D deficiency. It was unclear
whether there were folate deficiencies. Patients with chronic migraines
were more likely to have coenzyme Q10 and riboflavin deficiencies than
those with episodic migraines.
 
Previous studies have indicated that certain vitamins and vitamin
deficiencies may be important in the migraine process. Studies using
vitamins to prevent migraines, however, have had conflicting success.
 
Story Source:
 
The above post is reprinted from materials provided by Cincinnati
Children's Hospital Medical Center. Note: Materials may be edited for
content and length.
jacobnavia <jacob@jacob.remcomp.fr>: Jun 13 10:24AM +0200

Sorry, wrong destination !
 
Excuse me
jacob
Vir Campestris <vir.campestris@invalid.invalid>: Jun 13 09:09PM +0100

On 13/06/2016 09:24, jacobnavia wrote:
> Sorry, wrong destination !
 
Forgiven.
 
That might explain why I get them in groups for a few days, then not for
a while.
 
Andy
jacobnavia <jacob@jacob.remcomp.fr>: Jun 14 12:43AM +0200

Le 13/06/2016 à 22:09, Vir Campestris a écrit :
 
> That might explain why I get them in groups for a few days, then not for
> a while.
 
> Andy
 
Since you publish no mail address I can answer only by the group.
 
I retired the message, and I do not know if you got it. It was a msg to
my daughter (that has a migraines often) that vitamin D could help
lessen the symptoms, as reported in the science daily site.
To see more go to:
/www.sciencedaily.com/releases/2016/06/160610140645.htm
ram@zedat.fu-berlin.de (Stefan Ram): Jun 13 10:13PM

> if (str == "Good Morning!") str == "Guten Morgan!";
> std::cout << str << std::endl;
> }
 
Nowhere is »str« being assigned to above,
so it can be declared as »const«.
"K. Frank" <kfrank29.c@gmail.com>: Jun 13 06:40AM -0700

Hi Ian!
 
On Sunday, June 12, 2016 at 3:57:15 PM UTC-4, Ian Collins wrote:
> temporary string. You can't bind a temporary object to a reference, so
> you will have to use const std::string&, std::string or std::string&& as
> the parameter type in this case.
 
Just to be sure I understand:
 
The language could have permitted passing a temporary as
a non-cost reference, f (std::string &str);, but most of
the time you would be making a mistake doing this, so the
language prohibits it.
 
In this case -- passing in a temporary -- by using a
non-const rvalue reference, f (std::string &&str), you
are really just telling the compiler that you do want
to do this, and are not making a mistake.
 
That is, the code generated when binding a temporary
to a non-cost rvalue reference is the same as what
one would have expected (okay, what I would have expected)
if binding to a non-cost lvalue reference has been
allowed.
 
Is this correct, or am I missing something important
about this specific use case?
 
> Ian
 
 
Thanks for any clarification.
 
 
K. Frank
"Öö Tiib" <ootiib@hot.ee>: Jun 13 10:30AM -0700

On Monday, 13 June 2016 16:40:56 UTC+3, K. Frank wrote:
> a non-cost reference, f (std::string &str);, but most of
> the time you would be making a mistake doing this, so the
> language prohibits it.
 
The language could have permitted taking l-value reference to
r-value or taking r-value reference to l-value but it would be
misleading most of the time. The differences are complexity
that can give benefit in optimizing or mix everything up and
confuse.
 
It is somewhat similar taking pointer to non-const to string literal:
 
char* p = "wrong";
 
For legacy reasons we get only warning about that from most
of the compilers and if we don't attempt to modify *p then
it works fine.
 
> non-const rvalue reference, f (std::string &&str), you
> are really just telling the compiler that you do want
> to do this, and are not making a mistake.
 
Yes, with that const we have 4 references:
 
Reference to l-value of type X is 'X&'.
Reference to r-value of type X is 'X&&'.
Reference to const of type X is 'X const&'.
Thing we seemingly need for nothing is 'X const&&'.
 
> one would have expected (okay, what I would have expected)
> if binding to a non-cost lvalue reference has been
> allowed.
 
It is hard to know what you would had expected. Reference is
meant to be alias name to some value so compiler is not required
to generate any code about such alias. If a reference is stored
somewhere (for example class member) then to there it goes
most likely as memory address but it is nowhere required. Same
is with pointer, it is not specified what its bits mean.
 
 
> Is this correct, or am I missing something important
> about this specific use case?

Programming languages are meant for describing behavior of
programs and are not for instructing processors. That is the
sole little step we have ever taken above assemblers.
James Moe <jimoeDESPAM@sohnen-moe.com>: Jun 13 11:57AM -0700

On 06/12/2016 12:57 PM, Ian Collins wrote:
>> > Is it not possible to use std::string by reference?
> Yes, but in this case you are passing a char* which will create a
> temporary string. You can't bind a temporary object to a reference, [...]
 
Ah, I understand.
Thank you.
 
--
James Moe
jmm-list at sohnen-moe dot com
kfrank29.c@gmail.com: Jun 13 01:41PM -0700

Hello Öö!
 
On Monday, June 13, 2016 at 1:30:45 PM UTC-4, Öö Tiib wrote:
> > if binding to a non-cost lvalue reference has been
> > allowed.
 
> It is hard to know what you would had expected.
 
Here's a not-too-badly-contrived example to illustrate
what I would have expected:
 
void translateInPlaceAndPrint (std::string &str) {
if (str == "Good Morning!") str == "Guten Morgan!";
std::cout << str << std::endl;
}
 
// use case 1 -- won't compile
translateInPlaceAndPrint ("Good Morning!");
 
// use case 1 -- work-around
std::string tmp = "Good morning!";
translateInPlaceAndPrint (tmp);
 
// use case 2
std::string useMoreThanOnce = "Good Morning!";
translateInPlaceAndPrint (useMoreThanOnce);
// print again just for fun
std::cout << useMoreThanOnce << std::endl;
 
If "// use case 1 -- won't compile" were permitted, what
I would expect would be:
 
1) A temporary std::string is constructed on the stack
from "Good Morning!"
2) The temporary is bound to the non-const reference
argument
3) The lifetime of the temporary is extended to when
the function call returns
4) The function modifies its (non-const reference)
argument in place (and prints it out)
5) The function returns, the temporary's extended
lifetime ends, and the temporary is destroyed
 
This seems quite reasonable, and seems to me to be what
most people would expect if this were actually permitted.
 
It's certainly not necessary to permit this -- the
work-around is easy and obvious. (And the work-around
is almost the same as my hypothetical "expected"
behavior. The only difference is that the lifetime
of tmp is to the end of its block scope, rather than
just to when the function returns.)
 
 
> Programming languages are meant for describing behavior of
> programs and are not for instructing processors. That is the
> sole little step we have ever taken above assemblers.
 
Well, yes. And it is true that forbidding the binding of
temporaries to non-const references does prevent a certain
class of errors.
 
But the design of c++ has generally been to be
self-consistently flexible, rather than preventing you
from shooting yourself in the foot.
 
It just seems to me that permitting the binding of a
temporary to non-cost reference would be very much in
the spirit of c++, and would work just fine if implemented
as I described above, unless there is some other set
of problems I've overlooked.
 
I'm not proposing that the language permit this. I'm
just asking whether the language could have easily
permitted this (for example, as outlined above), or
whether I'm missing something and trying to permit this
would generate a whole other set of complications that
I've overlooked.
 
 
Thanks for any further enlightenment.
 
 
K. Frank
Paavo Helde <myfirstname@osa.pri.ee>: Jun 14 12:30AM +0300

On 13.06.2016 16:40, K. Frank wrote:
> a non-cost reference, f (std::string &str);, but most of
> the time you would be making a mistake doing this, so the
> language prohibits it.
 
Yes it could, and earlier MSVC versions indeed allowed it for a long
time, at least in some situations.
 
I believe this was prohibited this feature was extremely fragile. Make a
innocent-looking change in the code like replacing an int with a long,
and the program would silently start misbehaving because a temporary
would be created where there was none before, or vice versa.
 
> one would have expected (okay, what I would have expected)
> if binding to a non-cost lvalue reference has been
> allowed.
 
In some sense, this is correct, a temporary would be created and its
address passed to the function. What is different are the assumptions
what the called function would make: a temporary cannot be used for
transporting information out of the function, whereas non-const lvalue
references are often used exactly for that purpose.
 
So from the point of the overall functionality the two scenarios
(calling with a non-const lvalue reference and calling with a temporary)
differ drastically; using the same syntax for two drastically different
things would not be a good design.
 
Cheers
Paavo
Lynn McGuire <lmc@winsim.com>: Jun 13 12:19PM -0500

On 6/10/2016 12:15 AM, Paavo Helde wrote:
>> are using Visual Studio C++ 2015.
>> http://en.cppreference.com/w/cpp/language/override
 
> Have been using it for many years already (it was available in MSVC long before being standardized). Helps a lot during refactoring.
 
Man, is it ever. I am converting our data storage from distributed to sparse and adding an owner argument to methods all over the
place. The override specifier is saving my bacon.
 
Lynn
"Öö Tiib" <ootiib@hot.ee>: Jun 13 10:34AM -0700

On Monday, 13 June 2016 20:19:32 UTC+3, Lynn McGuire wrote:
 
> > Have been using it for many years already (it was available in MSVC long before being standardized). Helps a lot during refactoring.
 
> Man, is it ever. I am converting our data storage from distributed to sparse and adding an owner argument to methods all over the
> place. The override specifier is saving my bacon.
 
Hiding of members of base class is confusing regardless if
knowingly or by accident and if it is virtual function that
is hidden in such a way then that is even worse.
 
IOW I would often appreciate some warning in situations
that 'override' makes illegal even without that 'override'
present.
"K. Frank" <kfrank29.c@gmail.com>: Jun 13 05:10AM -0700

Hi Alf (and Friends)!
 
Thank you for this discussion on one of the musty (for
me) corners of c++ syntax.
 
But why?
 
On Sunday, June 12, 2016 at 9:35:24 AM UTC-4, Alf P. Steinbach wrote:
 
> For you /can/ write this:
 
> if( std::operator==( z, {} ) )
> ; // empty statement.
 
My test version:
 
#include <vector>
int main (int argc, char* argv[]) {
std::vector<int> v;
 
// bool b = (v == {}); // doesn't compile
bool b = operator==(v, {}); // compiles
 
return 0;
}
 
I did this test with g++ -std=c++11, with version 4.9.2.
 
Note, I got rid of the std:: in front of operator== just
to make sure that this wasn't dome adl thing (not that it
should have been).
 
I think I understand what everyone is saying, and what the
issue is, but why? Which pieces of the standard work together?
Why is "v == {}" not effectively equivalent to
"operator==(v, {})"?
 
(And, although I expect not, is there any difference here
between c++11 and c++14 / c++17?)
 
> Cheers & hth.,
 
> - Alf
 
 
Thanks for any standardese parsing.
 
 
K. Frank
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)