Saturday, April 11, 2015

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

Jorgen Grahn <grahn+nntp@snipabacken.se>: Apr 11 02:53AM

On Fri, 2015-04-10, Peter wrote:
> metaprogramming merely a curiosity, an unexpected side effect of
> adding templates to language definition and everything about it is
> either undefined or implementation defined?
 
Well, /The C++ Programming Language/ dedicates chapter 28 to TMP ...
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
"Öö Tiib" <ootiib@hot.ee>: Apr 11 03:26AM -0700

On Saturday, 11 April 2015 01:22:32 UTC+3, Peter wrote:
> It's going to be a very general question, but here it goes: is template
> metaprogramming a serious programming technique, used in real-life code?
 
Yes. Every trick (including preprocessor or template metaprogramming)
for to achieve that something is done compile-time or before it
rather than run-time is actually used in real programs written in C++.
 
> metaprogramming merely a curiosity, an unexpected side effect of
> adding templates to language definition and everything about it is
> either undefined or implementation defined?
 
Why you ask several, orthogonal to each other questions in same
sentence?
a) Turing-complete set of template metaprogramming techniques is
guaranteed by C++ standard.
b) These techniques are non-portable only to where the compilers
are non-conformant.
c) It is curiosity.
d) It was unexpected side effect of adding templates to language.
e) Some people will always use (either by accident or knowingly)
some undefined or implementation defined effects regardless if
those are related to templates or not.
 
Important questions you did not ask:
 
Is metaprogramming in general needed for writing better programs?
No. We can do metaprogramming in our heads. Often we can also let
programs to do things run-time without big disadvantage. It may be
performs slightly worse and gives defect reports bit later.
 
Is the template metaprogramming needed for writing better programs?
It is not. We can ourselves always use other, nicer means of code
generation.
 
Is the C++ template metaprogramming needed for writing better
C++ libraries?
Sometimes. Flexibility in integration layer may give wider
usability. Early diagnostics are good so user does not waste his
time to trying to misuse the library and what little is
performance-critical for user may differ per user. The C++
preprocessor metaprogramming is even worse and delivering
separate tools with library adds to complexity of its usage.
Juha Nieminen <nospam@thanks.invalid>: Apr 11 06:05PM

> It's going to be a very general question, but here it goes: is template metaprogramming a serious programming technique, used in real-life code? Is there anything in C++ standard that guarantees its validity and/or portability (at least to some extent) or is template metaprogramming merely a curiosity, an unexpected side effect of adding templates to language definition and everything about it is either undefined or implementation defined?
 
Btw, define "template metaprogramming".
 
Would you consider the following "template metaprogramming", or would
you consider it something else?
 
Consider what happens here:
 
std::vector<size_t> v(10, 20);
 
You are constructing a vector with 10 elements, each having the value 20.
But how does the compiler know you are wanting to do that? The question
raises because std::vector has a constructor taking two iterators, which
is declared effectively as:
 
template<typename Iter>
std::vector<ValueType>::vector(Iter begin, Iter end);
 
That vector creation earlier matches that declaration perfectly. Yet still,
somehow, the compiler doesn't try to call this, and instead calls the
correct constructor (ie. the one that takes a number and a value to
initialize the vector with).
 
std::vector achieves this via template trickery. Would you consider
this "template metaprogramming"? It certainly is non-trivial trickery
using templates.
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
Jorgen Grahn <grahn+nntp@snipabacken.se>: Apr 11 06:20PM

On Sat, 2015-04-11, Juha Nieminen wrote:
> Peter <pilarp@poczta.onet.pl> wrote:
 
>> It's going to be a very general question, but here it goes: is
>> template metaprogramming a serious programming technique, used in
...
 
 
> std::vector achieves this via template trickery. Would you consider
> this "template metaprogramming"? It certainly is non-trivial trickery
> using templates.
 
"Trickery" implies, as I understand the word, something devious and
undocumented that you're not supposed to learn about. Isn't this just
the usual overloading rules, extended to include templates? Out of
the two constructors
 
vector(size_type n, const T& t)

template <class InputIterator>
vector(InputIterator, InputIterator)
 
the former is a decent match, and the latter is worse (and wouldn't
compile anyway if it was chosen).
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Paavo Helde <myfirstname@osa.pri.ee>: Apr 11 04:32PM -0500

Jorgen Grahn <grahn+nntp@snipabacken.se> wrote in
> vector(InputIterator, InputIterator)
 
> the former is a decent match, and the latter is worse (and wouldn't
> compile anyway if it was chosen).
 
10 and 20 are of type int, which is different from size_type and const
size_t&. A little experiment shows this is not so trivial:
 
#include<iostream>
 
template<class T>
class myvector {
public:
myvector(size_t n, const T& value) {
std::cout << "A\n";
}
template<typename ITER>
myvector(ITER a, ITER b) {
std::cout << "B\n";
}
};
 
int main() {
myvector<size_t> x(10, 20);
return 0;
}
 
This prints "B" with my compiler. When 10 and 20 are cast to size_t, it
prints "A" indeed, but requiring such exact types would make using
std::vector much more cumbersome.
 
As far as I understand, the "template trickery" is needed for getting the
second constructor to fail at the substitution stage (SFINAE) for integer
types so that the first constructor gets selected. And yes, switching
overloads on and off at compile time seems pretty TMP for me.
 
Cheers
Paavo
asetofsymbols@gmail.com: Apr 11 03:37AM -0700

#define P printf
#define G(a,b) if(a)goto b
#define u8 unsigned int
#define R Return
 
u8 i,k,r;main(){++k;m:i=0;v:P(i++<k?"0":"1");++r;G(i<2*k,v);G(r%16,m);P("\n");k=i;G(r<64,m);}
 
There is someone know why this:
u8 i,k,r;main(){++k;m:i=0;v:P(i<k?"0":"1");++r;G(i++<2*k,v);G(r%16,m);P("\n");k=i;G(r<64,m);}
is not ok?
asetofsymbols@gmail.com: Apr 11 07:12AM -0700

I wrote:
"u8 i,k,r;main(){++k;m:i=0;v:P(i<k?"0":"1");++r;G(i++<2*k,v);G(r%16,m);P("\n");k=i;G(r<64,m);}
is not ok?"
 
I make one error in believe macro
expansion was not ok; instead was
one my programming error it would be ++i<2*k
 
u8 i,k,r;main(){++k;m:i=0;v:P(i<k?"0":"1");++r;G(++i<2*k,v);G(r%16,m);P("\n");k=i;G(r<64,m);}
asetofsymbols@gmail.com: Apr 11 07:36AM -0700

Stefan Ram wrote:
"#include<stdio.h>Nint main(){for(int i=0;i<64;i%16?0:puts(""))putchar('0'+i++/(1<<(i>>4))%2);}"
 
#include<stdio.h>Nint i;int main(){m:putchar('0'+i++/(1<<(i>>4))%2);
G(i%16,m);puts("");G(i<64,m)}
 
The code that use macro
#define G(a,b) if(a)goto b
Would be 4 char more
but it would be + clear to me
asetofsymbols@gmail.com: Apr 11 09:41AM -0700

#include<iostream.h>
#include<bitset.h>
#define b(x) cout<<bitset<16> x << "\n";
main(){b(21845)b(13107)b(3855)b(255)}
I don't know if it compile...
Jorgen Grahn <grahn+nntp@snipabacken.se>: Apr 11 03:43PM

On Thu, 2015-04-09, 嘱 Tiib wrote:
> full yo yo of virtuals to realize how *not* to use C++ well. People
> learn fastest from their own mistakes. Usage of other ways but
> 'clone' is one certain source of those headaches.
 
Ah, I see it now: he was critizising the clone(), not the
virtual-ness. You're probably right, then. (I have to admit I use
inheritance so rarely that I never had to fight slicing.)
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Paavo Helde <myfirstname@osa.pri.ee>: Apr 11 12:59AM -0500

Ian Collins <ian-news@hotmail.com> wrote in
 
> That doesn't make any sense.
 
> The only virtual functions you need to implement in a derived class
> are pure virtual functions.
 
I guess Norman meant "implementing" in a broader sense, i.e. adding needed
virtual function interfaces to a class hierarchy. Using some other word
would have been more suitable to avoid confusion.
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)