Monday, May 22, 2017

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

"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: May 22 09:44PM +0200

It's said [by whom? hey needs reference] that "Info" as a name indicates
a design problem.
 
Consider the following code of mine:
 
class Encoding_value
{
private:
struct Info
{
int n_leading_ones;
Byte bits;
 
Info( Byte const code )
: n_leading_ones{ 0 }
, bits{ code }
{
for( Byte mask = 0b1000'0000; bits & mask; mask >>= 1 )
{
bits &= static_cast<Byte>( ~mask );
++n_leading_ones;
}
}
};
 
public:
Info const info;
 
Encoding_value( Byte const code )
: info{ code }
{}
};
 
It would be nice, probably, to find some way to express it without the
non-descriptive "Info" as a name, yet without ugly accessors or code
verbosity or other negative properties.
 
One possible design problem, that "Info" maybe indicates, is that the
`private` declaration of the "Info" class is partially public in the
sense that client code is intended to use its member names, like
 
auto const& value = Encoding_value{
static_cast<Byte>( *in_pos++ )
}.info;
 
// E.g. access `value.n_leading_ones` here.
 
Oh well that usage has its own problems, it's a darkish little corner
case of the language. Hm. Comments?
 
 
Cheers!,
 
- Alf
legalize+jeeves@mail.xmission.com (Richard): May 22 11:11PM

[Please do not mail me a copy of your followup]
 
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> spake the secret code
 
>It's said [by whom? hey needs reference] that "Info" as a name indicates
>a design problem.
 
Additional candidates:
 
"Data"
"Manager"
"Helper"
"Utility"
 
Although Manager sometimes isn't abused.
--
"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>
JiiPee <no@notvalid.com>: May 22 09:31PM +0100

On 21/05/2017 06:02, Alf P. Steinbach wrote:
> []( Person const& p, Person2 p2 ) { p2.age = p.age; return
> p2; }
> );
 
 
I tested this with a debugger.
It does make Person2 object copies (3 times). So it copies 3 times
Person2 objects to another Person2 objects. But originally I did not
want this neither (I think I could have solved this myself if object
copy was allowed). Copying is an expensive operation , so I dont think
this is a good solution compared to the best solution (only copying the
age values). Obviously the lambda has to return an object which is then
copied, right? So i guess its not possible to change/modify/copy *only*
the age values.
 
 
In your example you do copy also name height and name values (although
they are the original values - no none of thos evalues is changed..
copied but no value change).
JiiPee <no@notvalid.com>: May 22 09:53PM +0100

On 21/05/2017 06:02, Alf P. Steinbach wrote:
> []( Person const& p, Person2 p2 ) { p2.age = p.age; return p2; }
 
 
another thing is that cant you just do:
 
[](Person const& p, Person2& p2) { p2.age = p.age; return p2; }
 
 
so using a reference. I get the same result, and there is one object
copy less then.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: May 22 10:58PM +0200

On 22-May-17 10:53 PM, JiiPee wrote:
 
> [](Person const& p, Person2& p2) { p2.age = p.age; return p2; }
 
> so using a reference. I get the same result, and there is one object
> copy less then.
 
Yes we can, as Obama said. But you don't get rid of the final copying
except as an optimization performed by the compiler. In contrast, when
you drop the restriction of using standard library functionality only,
then you can get both efficiency, conciseness, safety and clarity. ;-)
 
 
Cheers!,
 
- Alf
JiiPee <no@notvalid.com>: May 22 10:02PM +0100

On 22/05/2017 21:58, Alf P. Steinbach wrote:
> then you can get both efficiency, conciseness, safety and clarity. ;-)
 
 
totally agree :). Yes I can see that is the way in this example. Now
going to do that in my real code.... :)
 
Ye true in this case its more clear. Bjarne would definitely also say
that.... he supports simple solutions.
JiiPee <no@notvalid.com>: May 22 10:03PM +0100

On 22/05/2017 21:58, Alf P. Steinbach wrote:
> Yes we can, as Obama said.
 
haha
 
so how would Trump answer?
Juha Nieminen <nospam@thanks.invalid>: May 22 06:30AM

>> const auto values = { 1, 3, 5, 7 };
 
> Interesting... g++ 6.3.0 doesn't mind the use of constexpr, but it
> dislikes the vector assignment (with or without constexpr):
 
I checked, and clang makes 'values' of type std::initializer_list<int>,
while gcc makes it of type std::initializer_list<const int>.
 
Which one is right? Or are both right?
Ian Collins <ian-news@hotmail.com>: May 22 06:49PM +1200

On 05/22/17 06:30 PM, Juha Nieminen wrote:
 
> I checked, and clang makes 'values' of type std::initializer_list<int>,
> while gcc makes it of type std::initializer_list<const int>.
 
> Which one is right? Or are both right?
 
Um.. The type for the initializer_list underlying array should be const
int, the elements are immutable. I wonder if the compiler implement the
underlying storage differently, it is unspecified,
 
--
Ian
Juha Nieminen <nospam@thanks.invalid>: May 22 08:39AM


> Um.. The type for the initializer_list underlying array should be const
> int, the elements are immutable. I wonder if the compiler implement the
> underlying storage differently, it is unspecified,
 
I doubt you can modify the values pointed by std::initializer_list
(at least not standard-legally). std::initializer_list<T>::iterator
is a const T*, and std::initializer_list<T>::reference is const T&.
And those are the only ways to access the elements. The only way you
could try to modify the elements is to cast the constness away, which
I doubt is very kosher.
 
Thus I would guess that from a standard perspective it doesn't make
a difference whether the element type is int or const int (but I don't
know what the standard says about this.)
Juha Nieminen <nospam@thanks.invalid>: May 22 06:42AM

> statements. Recently I have been getting push back from some of my
> students with statements like "my friends at Microsoft tell me they
> use break; statements all the time" and similar types of objections.
 
Either programming practices at Microsoft are pretty lax, or they
are just making that up (which wouldn't actually surprise me).
 
Personally I don't find the use of 'break' or 'continue' to be
problematic, but I find myself *needing* to use them very
rarely. It's indeed quite rare the situation where they are the
most natural and handy solution.
 
Of course "rare" does not mean "they are never, ever the best
solution". Sometimes they are (although in my experience, and
for some reason, cases where 'continue' is the most natural
solution is much, much rarer than cases where 'break' is.)
 
The inner loop of calculating the mandelbrot set is the perfect
example of where 'break' is the most natural solution:
 
for(iter = 0; iter < maxIterations; ++iter)
{
const double zr2 = zr*zr, zi2 = zi*zi;
if(zr2 + zi2 > 4.0) break;
zi = 2.0*zr*zi + im;
zr = zr2 - zi2 + re;
}
 
The only other (and perhaps arguably better) solution would be to
use 'return' instead of 'break', but that's in essense no
different. In either case the loop is being exited from the middle,
rather than at its ending condition. It's hard to argue for a better
and more fluent solution.
 
Personally I detest in these cases artificially and forcefully
introducing some boolean value which is checked in the loop conditional
and set inside the loop. It feels unnatural, artificial, and forced.
It feels like a kludge trying to fix a non-existent problem, and that
is its major flaw.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: May 21 06:05PM -0700

Corrected URL:
 
https://www.youtube.com/watch?v=ETc-nG7X5cM
 
Thank you,
Rick C. Hodgin
"Chris M. Thomasson" <invalid@invalid.invalid>: May 21 06:15PM -0700

On 5/21/2017 6:05 PM, Rick C. Hodgin wrote:
> Corrected URL:
 
> https://www.youtube.com/watch?v=ETc-nG7X5cM
 
I know you are a good person. Thank you. Perhaps we can get along. I
have to learn to be a better person for I have called you very mean
things in public. Yikes!
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)