Friday, February 19, 2016

Digest for comp.lang.c++@googlegroups.com - 12 updates in 4 topics

Ian Collins <ian-news@hotmail.com>: Feb 20 11:22AM +1300

Wouter van Ooijen wrote:
>> opinion: you might add functionality by removing code!
 
> OK, so I think we agree that taking that Uncle Bob page literally is not
> a good idea?
 
Taking anything related to Agile practices too literally isn't a good
idea! Doing so goes against the underlying people over process
philosophy of agile.
 
The "rules" laid down by the well known agile evangelists should be
interpreted as guidelines rather than strict process steps (like those
mandated by RUP). Look on them as somewhere to start the development of
your own process. Every agile team I know have their own modified
processes, some of these go back well before the "agile boom" in the
early 2000s.
 
> Can you refer me to a page or document or whatever that describes the
> version of TDD that you find usefull?
 
Not really, I was shown TDD by Kent Beck at an agile development
conference back in 2002 and realised it put a more formal structure
around the way I had been working for years. My then team developed our
own process based on the concepts we had learned at the conference.
 
Learning how to use agile processes isn't easy on your own, the long
standing advice is to hire a coach for the first few weeks or months
(depending on your budget). You really do have to learn by doing.
 
 
> And back to the UART :)
 
> After the first test case, would I be allowed to write the UART init
> code that calculates the settings from the specified baudrate?
 
Why not? Just TDD the code...
 
--
Ian Collins
legalize+jeeves@mail.xmission.com (Richard): Feb 19 10:39PM

[Please do not mail me a copy of your followup]
 
Ian Collins <ian-news@hotmail.com> spake the secret code
 
>The "rules" laid down by the well known agile evangelists should be
>interpreted as guidelines rather than strict process steps (like those
>mandated by RUP).
 
Instead of generalizing, I'm going to say that for Uncle Bob's rules
of TDD you should *literally* do them when learning TDD. You should
obey those rules literally and without deviation. Doing so is crucial
to learning TDD and actually "getting it" IMO.
 
You'll know you're in a good TDD workshop when the instructor reviews
the code of students and tells them to delete everything they've done
and start over when they've violated the rules.
 
In martial arts, this is known as "shuhari". When you are beginning
to learn TDD you aren't yet masterful enough to know *when* you can
bend or break the rules, so you must follow them rigidly. (You are
"shu".) As you achieve mastery, you advance to "ha" where you can
start to bend the rules or even break them completely. When you
become a true master, you advance to "ri" and the rules are no longer
necessary because you've internalized them as habit and you can be
more expressive and freeform or even make up your own competing
system.
<https://en.wikipedia.org/wiki/Shuhari>
 
Many of the people I've seen struggle with TDD are programmers with
many years of experience outside of TDD that feel uncomfortable being
placed into a position where they have to rigidly follow the rules
because they haven't achieved mastery.
 
This is somewhat akin to saying:
"What's so hard about programming? It's just typing!"
 
From what I can tell, Ian has been doing this a while and he has a
good intuition for when he can bend the rules without getting himself
into trouble. For an absolute beginner, it is my opinion that they
follow the rules literally. Otherwise, they will miss the crucial
insight that TDD brings because they will keep doing things the old
way.
 
I describe TDD as turning your normal pyramid of development upside
down. It is a significantly different way of thinking about the code
development process.
--
"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>
Wouter van Ooijen <wouter@voti.nl>: Feb 20 12:20AM +0100

Op 19-Feb-16 om 11:39 PM schreef Richard:
 
> I describe TDD as turning your normal pyramid of development upside
> down. It is a significantly different way of thinking about the code
> development process.
 
I think I am a rather good programmer / system designer (don't we all
think we are?) and I decide for myself what I find usefull. There are
lots of development processes available, and I can't 'walk' them all, so
I'll have to choose, upfront, based on what I see, waht is worth trying.
You (Richard) and Ian present two rather different views of what you
think TDD is (or should be). Based on what you say, and a few Uncle Bob
talks, I reject the Bob/Richard path as rediculous, but the
Ian/Kent-Beck path might be interesting. I'll watch a few Kent Beck
talks before I decide.
 
Wouter van Ooijen
"Öö Tiib" <ootiib@hot.ee>: Feb 19 04:46AM -0800

13.6 Built-in operators [over.built]
8 For every type T there exist candidate operator functions of the form T* operator+(T*);
 
I can find zero uses in my code-bases so I started to wonder if
anyone uses it and what is the common usage of it?
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Feb 19 02:28PM +0100

On 2/19/2016 1:46 PM, Öö Tiib wrote:
> 8 For every type T there exist candidate operator functions of the form T* operator+(T*);
 
> I can find zero uses in my code-bases so I started to wonder if
> anyone uses it and what is the common usage of it?
 
I don't think it's used at all for pointers, but it /can/ be used to
produce an rvalue, which e.g. might guide overload resolution.
 
For integral types the unary `+` is a nice way to force promotion.
 
However, writing `+ 0` is perhaps more clear.
 
 
Cheers & hth.,
 
- Alf
Marcel Mueller <news.5.maazl@spamgourmet.org>: Feb 19 09:07PM +0100

On 19.02.16 13.46, Öö Tiib wrote:
> 8 For every type T there exist candidate operator functions of the form T* operator+(T*);
 
> I can find zero uses in my code-bases so I started to wonder if
> anyone uses it and what is the common usage of it?
 
I remember some code fragments where I needed operator + to make the
code compile.
[...seeking...]
Ah, here it is:
 
ControlBase(+GetHwnd()).Text(title);
 
ControlBase is a constructor of a lightweight C++ wrapper around dialog
controls taking HWND as parameter. GetHwnd() returns HWND. .Text(...) is
a member function of ControlBase to send a window message to set the
window title.
 
Without operator+ gcc complains:
 
gui/dialog.cpp: In constructor `UrlDialog::UrlDialog(long unsigned int,
const char*)':
gui/dialog.cpp:177: error: parse error before `.' token
 
 
 
Marcel
wander <wandersys@gmail.com>: Feb 19 06:46AM -0800

Good day!
I came across an interesting feature in the behavior of popular compilers and would like to understand the reasons.
There's a simple code:
 
#include <iostream>
 
template <typename F>
void (* declval() ) (F);
 
template <typename X>
char (& probe( void(*) ( X * ) ) )[1];
 
template <typename X>
char (& probe( void(*) ( X ) ) )[2];
 
int main()
{
std::cout << sizeof( probe(declval<void() const>()) );
}
 
The question is about type deduction. If you run this code on
* compiler GCC 4.8.x (or later)
* compiler Clang 3.4 (or later)
* compiler in the Visual Stuido (tested on VS 2013 Community)
* compiler Intel ICC 13.0.1
 
it will display the number "1". And I thought it is logical, since function type, being substituted argument in another function, acquires the properties of a pointer type.
On newer versions of compilers mentioned (except for VS and ICC) behavior has changed and now this code for Clang 3.5 (or higher), GCC 4.9 (or higher) displays the number "2". If you remove the second overload, then the mentioned versions of GCC and Clang error occurs:
"Forming pointer to qualified function type"
I understand why but doubt whether this rule applies in this context.
 
Maybe together we can find the truth.
Thank you.
wander <wandersys@gmail.com>: Feb 19 06:45AM -0800

Good day!
I came across an interesting feature in the behavior of popular compilers and would like to understand the reasons.
There's a simple code:
 
#include <iostream>
 
template <typename F>
void (* declval() ) (F);
 
template <typename X>
char (& probe( void(*) ( X * ) ) )[1];
 
template <typename X>
char (& probe( void(*) ( X ) ) )[2];
 
int main()
{
std::cout << sizeof( probe(declval<void() const>()) );
}
 
The question is about type deduction. If you run this code on
* compiler GCC 4.8.x (or later)
* compiler Clang 3.4 (or later)
* compiler in the Visual Stuido (tested on VS 2013 Community)
* compiler Intel ICC 13.0.1
 
it will display the number "1". And I thought it is logical, since function type, being substituted argument in another function, acquires the properties of a pointer type.
On newer versions of compilers mentioned (except for VS and ICC) behavior has changed and now this code for Clang 3.5 (or higher), GCC 4.9 (or higher) displays the number "2". If you remove the second overload, then the mentioned versions of GCC and Clang error occurs:
"Forming pointer to qualified function type"
I understand why but doubt whether this rule applies in this context.
 
Maybe together we can find the truth.
Thank you.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Feb 19 05:00PM +0100

On 2/19/2016 3:46 PM, wander wrote:
> Good day!
 
Yes, and a good day to u2! :)
 
 
> * compiler in the Visual Stuido (tested on VS 2013 Community)
> * compiler Intel ICC 13.0.1
 
> it will display the number "1".
 
Huh, that's weird.
 
The argument type F is not a pointer.
 
It should not match a pointer, as indicated by result "1".
 
 
> And I thought it is logical, since function type, being substituted
> argument in another function, acquires the properties of a pointer
> type.
 
Oh.
 
Well, yes, now that you mention it, argument type F should decay to
pointer to function.
 
Yes.
 
 
> the second overload, then the mentioned versions of GCC and Clang
> error occurs: "Forming pointer to qualified function type" I
> understand why but doubt whether this rule applies in this context.
 
Dunno. What's that rule? I could search the standard or just google it,
but I think that the one who asks should provide such info. :)
 
 
> Maybe together we can find the truth. Thank you.
 
Well, whatever this code is meant to support, it can surely be expressed
in some less ambiguous and more clear way?
 
I'd also change the name `declval` to something not used by the standard
library, or at least put this in a namespace of its own.
 
In passing, is that `const` really well formed? It's not long ago since
I disabled a sillywarning from MSVC about `const` on function having no
effect, which popped for their own standard library implementation...
Still I feel not quite certain that it's ignored, because when I changed
this to function pointer the compiler complained about it.
 
 
Cheers & hth.,
 
- Alf
wander <wandersys@gmail.com>: Feb 19 08:45AM -0800


> Huh, that's weird.
 
> The argument type F is not a pointer.
 
> It should not match a pointer, as indicated by result "1".
 
There is online test (prints 1 on gcc 4.8.2): http://melpon.org/wandbox/permlink/1NDBIzVwEFbOn9UY
And second test (prints 2 on gcc 4.9): http://melpon.org/wandbox/permlink/PN721vPquuUtrAfH
 
> > understand why but doubt whether this rule applies in this context.
 
> Dunno. What's that rule? I could search the standard or just google it,
> but I think that the one who asks should provide such info. :)
 
In the new standard there is 8.3.1/4 (last draft):
"Forming a pointer to function type is ill-formed if the function type has cv-qualifiers or a ref-qualifier."
 
But I'm also interested in the discussion of this in the context of C++03.
In C++03 does not say so just as explicitly, and I need some help to formulate correct conclusions.
 
8.3.5/7 (std c++03):
"A typedef of a function type whose declarator includes a cv-qualifier-seq shall be used only to declare the function type for a nonstatic member function, to declare the function type to which a pointer to member refers, or to declare the top-level function type of another function typedef declaration."
 
 
> > Maybe together we can find the truth. Thank you.
 
> Well, whatever this code is meant to support, it can surely be expressed
> in some less ambiguous and more clear way?
 
No. It is theoretical question. I just want to understand what is happening: if I should, for example, send a bug to VS support, or vice versa, to the clang or gcc.
 
> I'd also change the name `declval` to something not used by the standard
> library, or at least put this in a namespace of its own.
 
`declval` name plays no role in this context. The examples in the online compiler, I have changed its name to the `test`.
 
> In passing, is that `const` really well formed?
 
Actually - yes. See quote from the Standard.
 
ram@zedat.fu-berlin.de (Stefan Ram): Feb 19 03:20AM

>For <iostream> in particular, the standard makes an exception and
>explicitly requires these includes:
>#include <ios>
 
There seem to be other such inclusions too:
 
utility -> initializer_list
bitset -> string, iosfwd
string -> initializier_list
array -> initializier_list
...
ram@zedat.fu-berlin.de (Stefan Ram): Feb 19 12:59PM

>I can find zero uses in my code-bases so I started to wonder if
>anyone uses it and what is the common usage of it?
 
Used on an array, it would make it decay into a pointer,
should this be ever needed. Or an overload could be defined
for it.
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)