Wednesday, May 27, 2015

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

Doug Mika <dougmmika@gmail.com>: May 27 10:47AM -0700

To Bazarov: I am very impressed with that little google presentation, first time I have seen it, HOWEVER, if you look at the search results, not one describes what exactly is an adaptive function (a mere definition would have suficed)!
 
So to Richard, a neat little function, but it has only one operator() function, not two, I guess that's not what makes a function object an adaptive function object? Then what exactly makes an adaptive function object ADAPTIVE?
Victor Bazarov <v.bazarov@comcast.invalid>: May 27 01:51PM -0400

On 5/27/2015 1:47 PM, Doug Mika wrote:
> To Bazarov: I am very impressed with that little google
> presentation,
first time I have seen it, HOWEVER, if you look at the search results,
not one describes what exactly is an adaptive function (a mere
definition would have suficed)!
 
> So to Richard, a neat little function, but it has only one
> operator()
function, not two, I guess that's not what makes a function object an
adaptive function object? Then what exactly makes an adaptive function
object ADAPTIVE?
 
I am guessing you need to learn terminology a bit, and it's outside of
the scope of this newsgroup to explain to you what "adaptive" or "an
adapter" means. Perhaps you should get a copy of the GoF book and read
about the Adapter pattern. Or you could just google for "Adapter
pattern"...
 
V
--
I do not respond to top-posted replies, please don't ask
legalize+jeeves@mail.xmission.com (Richard): May 27 09:56PM

[Please do not mail me a copy of your followup]
 
Doug Mika <dougmmika@gmail.com> spake the secret code
 
>So to Richard, a neat little function, but it has only one operator()
>function, not two,
 
Why would it have two?
 
What I wrote was a functor that adapted a less-than comparison
function and a greater-than comparison function, defaulting to
std::less and std::greater, respectively. By your original post:
 
> By definition: A function object that combines two function objects is
> called an adaptive function object.
 
This is an example of exactly that.
 
As others have pointed out, if you don't understand what adapters are
in the context of functions, then you need to go learn that first.
--
"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>
Lynn McGuire <lmc@winsim.com>: May 27 11:10AM -0500

"A second dark age for C++"
http://kennykerr.ca/2015/05/26/a-second-dark-age-for-c/
 
C++ looks very healthy to me right now.
 
Lynn
Lynn McGuire <lmc@winsim.com>: May 27 11:15AM -0500

On 5/27/2015 11:10 AM, Lynn McGuire wrote:
> http://kennykerr.ca/2015/05/26/a-second-dark-age-for-c/
 
> C++ looks very healthy to me right now.
 
> Lynn
 
In fact, the only thing that C++ is missing is an excellent cross platform user interface toolkit.
 
Lynn
Victor Bazarov <v.bazarov@comcast.invalid>: May 27 01:05PM -0400

On 5/27/2015 12:15 PM, Lynn McGuire wrote:
 
>> Lynn
 
> In fact, the only thing that C++ is missing is an excellent cross
> platform user interface toolkit.
 
People have been saying this for years. As if there is no Qt or any
other similar ones... C++ is *not* missing it. C++ is just fine with
those things existing on their own.
 
V
--
I do not respond to top-posted replies, please don't ask
Cholo Lennon <chololennon@hotmail.com>: May 27 02:10PM -0300

On 05/27/2015 01:10 PM, Lynn McGuire wrote:
> "A second dark age for C++"
> http://kennykerr.ca/2015/05/26/a-second-dark-age-for-c/
 
> C++ looks very healthy to me right now.
 
IMO the article title is misleading. It should be "A second dark age for
C++ *on Windows*" or maybe better "A second dark age for C++ *in Microsoft*"
 
Regards
 
--
Cholo Lennon
Bs.As.
ARG
Melzzzzz <mel@zzzzz.com>: May 27 07:55PM +0200

On Wed, 27 May 2015 13:05:14 -0400
> other similar ones... C++ is *not* missing it. C++ is just fine
> with those things existing on their own.
 
> V
 
How many languages (besides Java) have stdlib gui toolkit at all?
Lynn McGuire <lmc@winsim.com>: May 27 03:51PM -0500

On 5/27/2015 12:55 PM, Melzzzzz wrote:
>> with those things existing on their own.
 
>> V
 
> How many languages (besides Java) have stdlib gui toolkit at all?
 
C#
 
Lynn
Glen Stark <mail@glenstark.net>: May 27 12:55PM

Hi everyone
 
I have something like the following:
 
template <typename T>
class Foo
{
Foo(std::vector<T*>);
/*...*/
}
 
Now I'd like to be able to instantiate Foo without specifying the type,
since I already have the type available to the constructor... For
example, if I were so inclined, I could write the following:
 
std::vector<some_component_type> components;
Foo<std::remove_pointer<decltype(components)::value_type>::type>
cm(components);
 
and it would compile.
 
I'm doing a refactoring where this obviously that's a silly way of doing
this. I'd like to be able to do
Foo f(components);
 
and have the correct type instantiated. Is that possible? Is it
considered evil since it's no longer obvious it's a different type than
Foo g (diff_components)
 
What wisdom do you have to offer?
Wouter van Ooijen <wouter@voti.nl>: May 27 03:02PM +0200

Glen Stark schreef op 27-May-15 om 2:55 PM:
 
> I'm doing a refactoring where this obviously that's a silly way of doing
> this. I'd like to be able to do
> Foo f(components);
 
It seems that you (IMO rightly) object to mentioning T both explictily
in the type and implicitly in the parameter. Maybe a good alternative is:
 
auto f = Foo( components );
 
?
 
 
Wouter van Ooijen
Victor Bazarov <v.bazarov@comcast.invalid>: May 27 09:36AM -0400

On 5/27/2015 9:02 AM, Wouter van Ooijen wrote:
> in the type and implicitly in the parameter. Maybe a good alternative is:
 
> auto f = Foo( components );
 
> ?
 
The usual solution to it is to roll your own "make_a_Foo" function:
 
template<class T> Foo<T> make_a_Foo(T t) { return
Foo<T>(t);
}
 
after that, do the 'auto' trick:
 
auto f = make_a_Foo(components);
 
V
--
I do not respond to top-posted replies, please don't ask
Wouter van Ooijen <wouter@voti.nl>: May 27 03:49PM +0200

Victor Bazarov schreef op 27-May-15 om 3:36 PM:
> }
 
> after that, do the 'auto' trick:
 
> auto f = make_a_Foo(components);
 
What are the advantages of using such a function over the direct use of
the constructors?
 
Wouter
Victor Bazarov <v.bazarov@comcast.invalid>: May 27 10:05AM -0400

On 5/27/2015 9:49 AM, Wouter van Ooijen wrote:
 
>> auto f = make_a_Foo(components);
 
> What are the advantages of using such a function over the direct use of
> the constructors?
 
"Direct use of the constructors" requires specifying the type in the
angle brackets after the template name. Using such a function removes
that necessity. Did you try experimenting with your suggestion? Could
you post the code that works that uses only the c-tor, please?
 
V
--
I do not respond to top-posted replies, please don't ask
Glen Stark <mail@glenstark.net>: May 27 06:49AM

On Wed, 27 May 2015 07:52:23 +1200, Ian Collins wrote:
 
 
> You could make m_code a static member and specialise:
 
> template<> const int Foo<A>::m_code = 5;
> template<> const int Foo<B>::m_code = 10;
 
 
This is the solution that occurred to me, but I will need a different
code for each type I pass as template argument, and I don't want to have
to specialize the constructor for each use. What I'd really like is some
kind of compile-time lookup table.
 
Type traits (as suggested by Victor) might be my best bet. I gues what I
had hoped for was some kind of templated initializer which takes a type
and returns an integer. Something like:
 
template <typename T>
Foo<T>::Foo():m_class(template_magic_here<T>)
{
}
Ian Collins <ian-news@hotmail.com>: May 27 07:34PM +1200

Glen Stark wrote:
> code for each type I pass as template argument, and I don't want to have
> to specialize the constructor for each use. What I'd really like is some
> kind of compile-time lookup table.
 
You're not specialising a constructor, just a member. This is probably
the least amount of work and you get the added bonus of a link fail if
you try and pass a type you haven't specialised.
 
You could get want you want (compile-time lookup) with type-lists, but
you probably don't want to go there...
 
--
Ian Collins
"Lőrinczy Zsigmond" <zsiga@nospam.for.me>: May 27 08:25AM +0200

This is a long history.
Originally, NULL should represent the null-pointer (or pointer-null),
like it does in C, but someone (I won't say the name,
because I respect Bjarne Stroustrup) thought it would be very funny
to define it as integer-null.
It was illogical, but it became standard, so it cannot be changed.
After some decades there came another idea:
nullptr, which is a pointer-null.
Also it has a separate type (nullptr_t), which opens another funny
options for overloading.
 
For example, one should test these in both LP64 and LLP64:
 
void foo (nullptr_t);
void foo (void *);
void foo (long);
void foo (int);
 
foo (nullptr);
foo (NULL);
foo ((void *)0);
foo (0);
foo (0L);
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)