2024-11-14 22:10:43 +01:00
|
|
|
/* try.cpp - to try out and experiment with new features....
|
2007-08-17 00:36:07 +02:00
|
|
|
* scons will create the binary bin/try
|
2014-08-16 02:04:29 +02:00
|
|
|
*/
|
Buffer-Provider: investigate Problem with embedded type-constructor-arguments
This is a possible extension which frequently comes up again during the design of the Engine.
Basically, the `TypeHandler` in the metadata-descriptor used by the `BufferProvder` could capture
additional context-arguments, which are then later passed to an object instance embedded into the buffer.
Yesterday I attempted to use this feature for a simple demonstration in `NodeBasic_test`,
just to find out that passing additional constructor arguments to the capture fails with
a confusing compilation error message. This failure could be traced down to the function binder;
and what at first sight seemed to be a compiler error, turned out to be a quite logical limitation:
When we »close« some objects of the constructor, but delay the construction itself, we'll have to
store a copy in the constructor-λ. And this implies, that we'll have to change the types
used for instantiation of the compiler, so that the construction-function can be invoked
by passing references from the captured copy of the additional arguments.
When naively passing those forwarded arguments into the std::bind()-call,
the resulting functor will fail at instantiation, when the compiler attempts
to generate the function-call `operator()`
see: https://stackoverflow.com/q/30968573/444796
2024-12-16 23:01:57 +01:00
|
|
|
// 12/24 - investigate problem when perfect-forwarding into a binder
|
2024-12-12 04:38:55 +01:00
|
|
|
// 12/24 - investigate overload resolution on a templated function similar to std::get
|
2024-11-14 22:10:43 +01:00
|
|
|
// 11/24 - how to define a bare object location comparison predicate
|
2023-11-27 21:58:37 +01:00
|
|
|
// 11/23 - prototype for grouping from iterator
|
2012-01-07 03:28:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
/** @file try.cpp
|
Buffer-Provider: investigate Problem with embedded type-constructor-arguments
This is a possible extension which frequently comes up again during the design of the Engine.
Basically, the `TypeHandler` in the metadata-descriptor used by the `BufferProvder` could capture
additional context-arguments, which are then later passed to an object instance embedded into the buffer.
Yesterday I attempted to use this feature for a simple demonstration in `NodeBasic_test`,
just to find out that passing additional constructor arguments to the capture fails with
a confusing compilation error message. This failure could be traced down to the function binder;
and what at first sight seemed to be a compiler error, turned out to be a quite logical limitation:
When we »close« some objects of the constructor, but delay the construction itself, we'll have to
store a copy in the constructor-λ. And this implies, that we'll have to change the types
used for instantiation of the compiler, so that the construction-function can be invoked
by passing references from the captured copy of the additional arguments.
When naively passing those forwarded arguments into the std::bind()-call,
the resulting functor will fail at instantiation, when the compiler attempts
to generate the function-call `operator()`
see: https://stackoverflow.com/q/30968573/444796
2024-12-16 23:01:57 +01:00
|
|
|
* Partially binding / closing arguments of a function with _perfect forwarding_ can be problematic.
|
|
|
|
|
* The problem was encountered in the steam::engine::TypeHandler::create() - function with additional
|
|
|
|
|
* constructor arguments. Obviously, we want these to be _perfect forwarded_ into the actual constructor,
|
|
|
|
|
* but the binding must store a captured copy of these values, because the handler can be used repeatedly.
|
2024-12-12 15:55:02 +01:00
|
|
|
*
|
Buffer-Provider: investigate Problem with embedded type-constructor-arguments
This is a possible extension which frequently comes up again during the design of the Engine.
Basically, the `TypeHandler` in the metadata-descriptor used by the `BufferProvder` could capture
additional context-arguments, which are then later passed to an object instance embedded into the buffer.
Yesterday I attempted to use this feature for a simple demonstration in `NodeBasic_test`,
just to find out that passing additional constructor arguments to the capture fails with
a confusing compilation error message. This failure could be traced down to the function binder;
and what at first sight seemed to be a compiler error, turned out to be a quite logical limitation:
When we »close« some objects of the constructor, but delay the construction itself, we'll have to
store a copy in the constructor-λ. And this implies, that we'll have to change the types
used for instantiation of the compiler, so that the construction-function can be invoked
by passing references from the captured copy of the additional arguments.
When naively passing those forwarded arguments into the std::bind()-call,
the resulting functor will fail at instantiation, when the compiler attempts
to generate the function-call `operator()`
see: https://stackoverflow.com/q/30968573/444796
2024-12-16 23:01:57 +01:00
|
|
|
* The actual problem is caused by the instantiation of the target function, because the arguments are
|
|
|
|
|
* also passed into the binding mechanism by _perfect forwarding._ The target function template will thus
|
|
|
|
|
* be instantiated to expect RValues, but the binder can only pass a copy by-reference. At this point then
|
|
|
|
|
* the problem materialises (with a rather confusing error message).
|
|
|
|
|
*
|
|
|
|
|
* The Problem was already discussed on [Stackoverflow]
|
|
|
|
|
*
|
|
|
|
|
* A simple workaround is to change the types in the instantiation into references;
|
|
|
|
|
* obviously this can not work for some argument types; if a more elaborate handling is necessary,
|
|
|
|
|
* the [handling of bound arguments] should be considered in detail.
|
|
|
|
|
*
|
|
|
|
|
* [Stackoverflow]: https://stackoverflow.com/q/30968573/444796
|
|
|
|
|
* [handling of bound arguments]: http://en.cppreference.com/w/cpp/utility/functional/bind#Member_function_operator.28.29
|
2012-01-07 03:28:12 +01:00
|
|
|
*/
|
|
|
|
|
|
2015-08-29 17:09:03 +02:00
|
|
|
typedef unsigned int uint;
|
|
|
|
|
|
2020-03-07 19:39:51 +01:00
|
|
|
|
2016-01-06 04:36:53 +01:00
|
|
|
#include "lib/format-cout.hpp"
|
2018-03-17 03:36:58 +01:00
|
|
|
#include "lib/test/test-helper.hpp"
|
2022-12-18 03:47:40 +01:00
|
|
|
#include "lib/test/diagnostic-output.hpp"
|
2018-08-16 21:40:10 +02:00
|
|
|
#include "lib/util.hpp"
|
2019-04-19 18:37:30 +02:00
|
|
|
|
Buffer-Provider: investigate Problem with embedded type-constructor-arguments
This is a possible extension which frequently comes up again during the design of the Engine.
Basically, the `TypeHandler` in the metadata-descriptor used by the `BufferProvder` could capture
additional context-arguments, which are then later passed to an object instance embedded into the buffer.
Yesterday I attempted to use this feature for a simple demonstration in `NodeBasic_test`,
just to find out that passing additional constructor arguments to the capture fails with
a confusing compilation error message. This failure could be traced down to the function binder;
and what at first sight seemed to be a compiler error, turned out to be a quite logical limitation:
When we »close« some objects of the constructor, but delay the construction itself, we'll have to
store a copy in the constructor-λ. And this implies, that we'll have to change the types
used for instantiation of the compiler, so that the construction-function can be invoked
by passing references from the captured copy of the additional arguments.
When naively passing those forwarded arguments into the std::bind()-call,
the resulting functor will fail at instantiation, when the compiler attempts
to generate the function-call `operator()`
see: https://stackoverflow.com/q/30968573/444796
2024-12-16 23:01:57 +01:00
|
|
|
#include <functional>
|
2024-12-12 04:38:55 +01:00
|
|
|
|
Buffer-Provider: investigate Problem with embedded type-constructor-arguments
This is a possible extension which frequently comes up again during the design of the Engine.
Basically, the `TypeHandler` in the metadata-descriptor used by the `BufferProvder` could capture
additional context-arguments, which are then later passed to an object instance embedded into the buffer.
Yesterday I attempted to use this feature for a simple demonstration in `NodeBasic_test`,
just to find out that passing additional constructor arguments to the capture fails with
a confusing compilation error message. This failure could be traced down to the function binder;
and what at first sight seemed to be a compiler error, turned out to be a quite logical limitation:
When we »close« some objects of the constructor, but delay the construction itself, we'll have to
store a copy in the constructor-λ. And this implies, that we'll have to change the types
used for instantiation of the compiler, so that the construction-function can be invoked
by passing references from the captured copy of the additional arguments.
When naively passing those forwarded arguments into the std::bind()-call,
the resulting functor will fail at instantiation, when the compiler attempts
to generate the function-call `operator()`
see: https://stackoverflow.com/q/30968573/444796
2024-12-16 23:01:57 +01:00
|
|
|
using std::cout;
|
|
|
|
|
using std::endl;
|
|
|
|
|
using std::forward;
|
|
|
|
|
using std::placeholders::_1;
|
2024-12-12 04:38:55 +01:00
|
|
|
|
Buffer-Provider: investigate Problem with embedded type-constructor-arguments
This is a possible extension which frequently comes up again during the design of the Engine.
Basically, the `TypeHandler` in the metadata-descriptor used by the `BufferProvder` could capture
additional context-arguments, which are then later passed to an object instance embedded into the buffer.
Yesterday I attempted to use this feature for a simple demonstration in `NodeBasic_test`,
just to find out that passing additional constructor arguments to the capture fails with
a confusing compilation error message. This failure could be traced down to the function binder;
and what at first sight seemed to be a compiler error, turned out to be a quite logical limitation:
When we »close« some objects of the constructor, but delay the construction itself, we'll have to
store a copy in the constructor-λ. And this implies, that we'll have to change the types
used for instantiation of the compiler, so that the construction-function can be invoked
by passing references from the captured copy of the additional arguments.
When naively passing those forwarded arguments into the std::bind()-call,
the resulting functor will fail at instantiation, when the compiler attempts
to generate the function-call `operator()`
see: https://stackoverflow.com/q/30968573/444796
2024-12-16 23:01:57 +01:00
|
|
|
template<typename...ARGS>
|
|
|
|
|
inline void
|
|
|
|
|
dummy (int extra, ARGS&& ...args)
|
|
|
|
|
{
|
|
|
|
|
cout << extra <<"▷";
|
|
|
|
|
((cout << forward<ARGS>(args) << "•"), ...)
|
|
|
|
|
<< endl;
|
|
|
|
|
}
|
2024-12-12 04:38:55 +01:00
|
|
|
|
Buffer-Provider: investigate Problem with embedded type-constructor-arguments
This is a possible extension which frequently comes up again during the design of the Engine.
Basically, the `TypeHandler` in the metadata-descriptor used by the `BufferProvder` could capture
additional context-arguments, which are then later passed to an object instance embedded into the buffer.
Yesterday I attempted to use this feature for a simple demonstration in `NodeBasic_test`,
just to find out that passing additional constructor arguments to the capture fails with
a confusing compilation error message. This failure could be traced down to the function binder;
and what at first sight seemed to be a compiler error, turned out to be a quite logical limitation:
When we »close« some objects of the constructor, but delay the construction itself, we'll have to
store a copy in the constructor-λ. And this implies, that we'll have to change the types
used for instantiation of the compiler, so that the construction-function can be invoked
by passing references from the captured copy of the additional arguments.
When naively passing those forwarded arguments into the std::bind()-call,
the resulting functor will fail at instantiation, when the compiler attempts
to generate the function-call `operator()`
see: https://stackoverflow.com/q/30968573/444796
2024-12-16 23:01:57 +01:00
|
|
|
template<typename...ARGS>
|
|
|
|
|
auto
|
|
|
|
|
bound (ARGS&& ...args)
|
|
|
|
|
{
|
|
|
|
|
return std::bind (dummy<ARGS&...>, _1, forward<ARGS>(args) ...);
|
|
|
|
|
}
|
2024-12-12 15:55:02 +01:00
|
|
|
|
Buffer-Provider: investigate Problem with embedded type-constructor-arguments
This is a possible extension which frequently comes up again during the design of the Engine.
Basically, the `TypeHandler` in the metadata-descriptor used by the `BufferProvder` could capture
additional context-arguments, which are then later passed to an object instance embedded into the buffer.
Yesterday I attempted to use this feature for a simple demonstration in `NodeBasic_test`,
just to find out that passing additional constructor arguments to the capture fails with
a confusing compilation error message. This failure could be traced down to the function binder;
and what at first sight seemed to be a compiler error, turned out to be a quite logical limitation:
When we »close« some objects of the constructor, but delay the construction itself, we'll have to
store a copy in the constructor-λ. And this implies, that we'll have to change the types
used for instantiation of the compiler, so that the construction-function can be invoked
by passing references from the captured copy of the additional arguments.
When naively passing those forwarded arguments into the std::bind()-call,
the resulting functor will fail at instantiation, when the compiler attempts
to generate the function-call `operator()`
see: https://stackoverflow.com/q/30968573/444796
2024-12-16 23:01:57 +01:00
|
|
|
void
|
|
|
|
|
fun (int&& a)
|
|
|
|
|
{
|
|
|
|
|
std::cout << a << std::endl;
|
|
|
|
|
}
|
2024-12-12 15:55:02 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-01-05 03:32:24 +01:00
|
|
|
int
|
|
|
|
|
main (int, char**)
|
|
|
|
|
{
|
Buffer-Provider: investigate Problem with embedded type-constructor-arguments
This is a possible extension which frequently comes up again during the design of the Engine.
Basically, the `TypeHandler` in the metadata-descriptor used by the `BufferProvder` could capture
additional context-arguments, which are then later passed to an object instance embedded into the buffer.
Yesterday I attempted to use this feature for a simple demonstration in `NodeBasic_test`,
just to find out that passing additional constructor arguments to the capture fails with
a confusing compilation error message. This failure could be traced down to the function binder;
and what at first sight seemed to be a compiler error, turned out to be a quite logical limitation:
When we »close« some objects of the constructor, but delay the construction itself, we'll have to
store a copy in the constructor-λ. And this implies, that we'll have to change the types
used for instantiation of the compiler, so that the construction-function can be invoked
by passing references from the captured copy of the additional arguments.
When naively passing those forwarded arguments into the std::bind()-call,
the resulting functor will fail at instantiation, when the compiler attempts
to generate the function-call `operator()`
see: https://stackoverflow.com/q/30968573/444796
2024-12-16 23:01:57 +01:00
|
|
|
dummy (55,2,3,5,8);
|
2023-11-20 02:00:56 +01:00
|
|
|
|
Buffer-Provider: investigate Problem with embedded type-constructor-arguments
This is a possible extension which frequently comes up again during the design of the Engine.
Basically, the `TypeHandler` in the metadata-descriptor used by the `BufferProvder` could capture
additional context-arguments, which are then later passed to an object instance embedded into the buffer.
Yesterday I attempted to use this feature for a simple demonstration in `NodeBasic_test`,
just to find out that passing additional constructor arguments to the capture fails with
a confusing compilation error message. This failure could be traced down to the function binder;
and what at first sight seemed to be a compiler error, turned out to be a quite logical limitation:
When we »close« some objects of the constructor, but delay the construction itself, we'll have to
store a copy in the constructor-λ. And this implies, that we'll have to change the types
used for instantiation of the compiler, so that the construction-function can be invoked
by passing references from the captured copy of the additional arguments.
When naively passing those forwarded arguments into the std::bind()-call,
the resulting functor will fail at instantiation, when the compiler attempts
to generate the function-call `operator()`
see: https://stackoverflow.com/q/30968573/444796
2024-12-16 23:01:57 +01:00
|
|
|
auto bun = bound (2,3,5);
|
|
|
|
|
using Bun = decltype(fun);
|
|
|
|
|
SHOW_TYPE(Bun)
|
|
|
|
|
bun (55);
|
|
|
|
|
|
|
|
|
|
auto bi = std::bind (fun, 55);
|
|
|
|
|
// bi(); /////////// this invocation does not compile, because the Binder passes a copy to the RValue-Ref
|
2024-12-12 15:55:02 +01:00
|
|
|
|
Buffer-Provider: investigate Problem with embedded type-constructor-arguments
This is a possible extension which frequently comes up again during the design of the Engine.
Basically, the `TypeHandler` in the metadata-descriptor used by the `BufferProvder` could capture
additional context-arguments, which are then later passed to an object instance embedded into the buffer.
Yesterday I attempted to use this feature for a simple demonstration in `NodeBasic_test`,
just to find out that passing additional constructor arguments to the capture fails with
a confusing compilation error message. This failure could be traced down to the function binder;
and what at first sight seemed to be a compiler error, turned out to be a quite logical limitation:
When we »close« some objects of the constructor, but delay the construction itself, we'll have to
store a copy in the constructor-λ. And this implies, that we'll have to change the types
used for instantiation of the compiler, so that the construction-function can be invoked
by passing references from the captured copy of the additional arguments.
When naively passing those forwarded arguments into the std::bind()-call,
the resulting functor will fail at instantiation, when the compiler attempts
to generate the function-call `operator()`
see: https://stackoverflow.com/q/30968573/444796
2024-12-16 23:01:57 +01:00
|
|
|
cout << "\n.gulp." <<endl;
|
2007-08-17 00:36:07 +02:00
|
|
|
return 0;
|
|
|
|
|
}
|