Thursday, October 16, 2014

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

comp.lang.c++@googlegroups.com Google Groups
Unsure why you received this message? You previously subscribed to digests from this group, but we haven't been sending them for a while. We fixed that, but if you don't want to get these messages, send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Urs Thuermann <urs@isnogud.escape.de>: Oct 16 11:22PM +0200

> a C style string (similar to using %s in printf). When the operand
> has type pointer to "object that cannot be a string," the generated
> code treats it the same as using %p in printf.
 
Actually, the difference is in the definition of the operator<<()
functions involved. In all cases the array is converted to the
pointer of it's first element, i.e. this code calls
 
std::ostream::operator<<(int *);
std::operator<<(std::ostream &, char *)
std::ostream::operator<<(double *);
std::operator<<(std::ostream &, const char *)
std::operator<<(std::wostream &, const wchar_t *)
 
The operators for int* and double* simply print the address in hex,
since they cannot know the size of the array. The operator function
don't even know that an array is given as argument, they only get a
pointer. The operator<< for char* and wchar_t* also don't the size of
the array, but they rely on the programmer to pass a pointer a
null-terminated string of char's or wchar_t's, respectively. The
print all characters up to (but not including) the first null.
 
BTW, the GNU implementation has
 
std::operator<<(std::ostream &, char *)
std::operator<<(std::wostream &, wchar_t *)
 
which print the characters, and it also has

std::ostream::operator<<(char *);
std::wostream::operator<<(wchar_t *);
 
which print the pointer value in hex. But I don't know the rules
which decide between two when you write
 
cout << arr2;
 
I assume the member function is via template and the other operators
or more specific so they are chosen. But I haven't checked in the
header files.
 
urs
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Oct 16 07:27PM +0100

On Thu, 16 Oct 2014 12:03:06 -0500
 
> > Chris
 
> It turns out that this code came from Codeproject.com...
 
> http://www.codeproject.com/Articles/828776/Generic-Memoization-Infrastructure
 
Interesting. On that point the code is broken but it is easy to leave
off a reference attribute by mistake.
 
Actually, the effect of missing off the reference attribute from the
arguments of Memoize::Func() is worse here than I first thought. The
effect of applying std::forward to a template type representing a
function argument mistakenly taken by value is to cast std::forward's
argument to a rvalue reference. This means that the arguments passed
to T::Func (for a case where the result of applying the function has not
previously been memoized) might be invalid, because those arguments
would have previously been passed via std::forward to make_tuple(),
which applies std::decay to its arguments, so constructing the tuple
values from those arguments using (where available) the value type's
move constructor.
 
Chris
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Oct 16 07:43PM +0100

On Thu, 16 Oct 2014 19:27:52 +0100
> On Thu, 16 Oct 2014 12:03:06 -0500
> Robert Hutchings <rm.hutchings@gmail.com> wrote:
[snip]
> make_tuple(), which applies std::decay to its arguments, so
> constructing the tuple values from those arguments using (where
> available) the value type's move constructor.
 
No, I misspoke, it's worse than that. Even if you correct the function
signature, the code is still broken if you pass Memoize::Func() a
rvalue. The basic point is that you should never apply std::forward
in the body of a function to a value more than once. It may be invalid
after the first application.
 
So there are two significant errors in the code.
 
Chris
Robert Hutchings <rm.hutchings@gmail.com>: Oct 16 01:48PM -0500

On 10/16/2014 1:43 PM, Chris Vine wrote:
> after the first application.
 
> So there are two significant errors in the code.
 
> Chris
 
OK. I am reading one of Bjarne's books now, getting to the variadic
templates section. This is more complicated than I thought, although I
knew it wasn't going to be easy :)
JiiPee <no@notvalid.com>: Oct 16 06:49PM +0100

On 16/10/2014 17:53, Paavo Helde wrote:
> such a process for many years in the past), to avoid any fancy ideas of
> including b.h in the base library (which would by all wrong conceptually
> anyway).
 
And why does this factory version of it not work (for example inserting
the factory in main.cpp)? I have not compiled, but seems like it might
work:
 
// base library (DLL)
// a.h
class A {
public:
virtual ~A() {}
};
 
// -------------------------------------
 
// extension library (DLL) - link to base library
// b.h
//#include <BaseLibrary/a.h>
 
class B: public A {
public:
};
 
// b.cpp
 
// -------------------------------------
 
// main program - link to base library and extension library
// main.cpp
 
//#include <BaseLibrary/a.h>
//#include <Extensionlibrary/b.h>
 
A* foo(A *x) {
B *b1 = nullptr;
if( typeid(*x) == typeid(A) )
b1 = new A(*(dynamic_cast<A*>(b1)));
else if( typeid(*x) == typeid(B) )
b1 = new B(*(dynamic_cast<B*>(b1)));
 
return b1;
}
 
int main() {
A* x = new B();
foo(x);
delete x;
}
JiiPee <no@notvalid.com>: Oct 16 06:53PM +0100

On 16/10/2014 18:38, Paavo Helde wrote:
> Well, how do you propose to do this? Maybe you could try to write a
> replacement for the foo() function which makes a copy of the passed object
> without using the virtual clone() function.
 
I tried to do that, see my other post....
Paavo Helde <myfirstname@osa.pri.ee>: Oct 16 01:04PM -0500


> And why does this factory version of it not work (for example inserting
> the factory in main.cpp)? I have not compiled, but seems like it might
> work:
 
You want the factory in the base library, where the foo() function can use
it. The base library is presumably implementing basic functionality which
is working with abstract base class A pointers and doing lots of things
with them, including cloning. If this is not the case, there is no point to
make a class hierarchy with virtual functions in the first place, or to
have dynamically allocated objects at all.
Evan Sebastian <evanlhoini@gmail.com>: Oct 16 11:02AM -0700

Thanks for the suggestion, I already resolved the problem just now.
 
Turns out there is a there is a static public constant that is used before it is defined, thus the constant which contains unordered set stores nothing but garbage values.
Martin Ba <0xcdcdcdcd@gmx.at>: Oct 16 09:53AM +0200

On 13.10.2014 23:56, Mr Flibble wrote:
> (https://isocpp.org/files/papers/N4165.pdf) looks convincing (the
> initial idea gave me a mental rash though).
 
> /Flibble
 
What I don't buy is that we need a /language/ feature to enable IDEs to
offer sane auto completion.
 
Any "Intellisense" implementation today could offer to select and then
rewrite `x.f()` to `f(x)`. It would make sense with or with this being
in the language.
 
Aside, it seems though that
[D.2](http://www.drdobbs.com/cpp/uniform-function-call-syntax/232700394)
does also have this, so there's even prior art apart from .NET :-)
 
--
Like any language, C++ allows you to shoot yourself
in the foot -- but with C++, you sometimes don't
realize you shot yourself until it's too late. (Jeff Langr)
"Öö Tiib" <ootiib@hot.ee>: Oct 16 12:59AM -0700

On Tuesday, 14 October 2014 00:56:35 UTC+3, Mr Flibble wrote:
> Herb Sutter's new "Unified Call Syntax"
> (https://isocpp.org/files/papers/N4165.pdf) looks convincing (the
> initial idea gave me a mental rash though).
 
Herb Sutter has interesting idea, but he needs to think it through
bit more.
 
First he concentrates too much on that benefit of autocomplete
feature of IDE. However for me it is not such a problem to type but
more important is to read.
 
When reading syntax 'a.f1(b)' I know that 'a' is the 'this' parameter
(an IN-OUT parameter) of call. 'a' is passed by reference.
Even more when reading syntax 'a->f2(b)' I know that '*a' is the 'this'
parameter (an IN-OUT parameter) of call and it is caller who
dereferences 'a' here (and so must make sure that it is legal to).
 
The proposal removes that clarity since it does not talk about how
to match conceptual nature of parameters picked or responsibilities
of caller.
 
There was other benefit he mentioned that this will be somehow good in
generic context (template). However there he leaves too much open to
be convincing.
 
* He does not describe that array-to-pointer decay and how it interacts
with pointer parameters used with that extended syntax.
* He does not describe objects with unary * and -> operators overloaded
and how these interact with that extended syntax.
* He does not talk about other callables (lambdas, functors, function
pointers and function templates) and how these interact with that
extended syntax.
 
However we often alternate raw pointers (and above-mentioned decayed array)
with iterators or smart pointers (and whatever pointer-likes) in
generic context and we alternate functions with other callables.
So unless these are also addressed the "more generic" is rather
questionable point.
 
On the other hand if to make it very generic then it feels like another
tool of making code less readable in style of ...
'"otput.txt"->std::freopen("wb",stdout)' or something like that.
 
Also I imagine that lot of things in libraries (and in C standard library)
only have to look like functions but may be actually macros. That will
also fill StackOwerflow with novice questions about particular
library implementation with what the extended syntax does not compile.
 
So it does feel interesting idea indeed but it may lose lot of clarity
code and cause confusion and so it is strange that such a good author
like Herb Sutter did not write about those aspects at all.
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)