Hello I hope I might consult your expertise, I'm wondering about
a use-case where for a given library object, to provide an instance
of same type, that on any access, throws an exception.
The idea is that there's an idea in a different language where
the runtime throws a null_pointer_dereference exception
when dereferencing a null pointer, yet in C++ it's signal segfault.
So, what I wonder about is how to make an object in C++,
of a given standard library type, and any arbitrary type,
that on any access, throws.
I suppose I might static_cast an object yet I wonder how
to make it so then that any access to it throws.
As you might imagine it's a use-case for exceptions
as part of flow-of-control, that in the other language
just is null yet in C++ would be for "an object of all types",
that throws on any access.
Hello I hope I might consult your expertise, I'm wondering about
a use-case where for a given library object, to provide an instance
of same type, that on any access, throws an exception.
On 04/22/2024 07:32 PM, Sam wrote:
Ross Finlayson writes:
Hello I hope I might consult your expertise, I'm wondering about
a use-case where for a given library object, to provide an instance
of same type, that on any access, throws an exception.
What does "any access" mean? Please be specific.
As if it were null, whatever would raise a segfault,
is the idea of "any access", then I wish I better
explain the differences among pointers, references, and
class returns from functions, looking at C++ 11,
and trying to understand some of the newer syntactic
sugar with regards to declarations.
std::vector<int> values() {
return static_cast<std::vector<int>> nullptr; // no
}
The idea is that some code can compute partial results,
or to the effect of launching asynchronous requests
void rr1(const std::string& s) {
std::list<std::string> l1 = rr2(s);
int i1 = rr3(s);
int i2 = rr4(s);
int siz = l1.size(); // throw
int i3 = rr5(i1, i2, l1.size());
}
so the idea is the re-routine runs through statements
as long as the inputs are satisfied, then these
rr1, 2, 3, 4, 5 throw if their arguments are the
null_throwing type, and any library code access
It's an idea for writing co-routines in the language
This way then the re-routine sort of automatically
primes its asynchronous results in whatever results
getting to the invoked re-routines, "satisfied" or
"satisfying" inputs, so that they're initiated
with completion handlers to populate the monad
and push the next re-run or the re-routine to
the task queue, which flows in the otherwise
flow-of-control in the language exactly the same
each time until it itself actually completes
and calls back to the originating (initiating)
callback (completion handler).
(It's been a while, I need to learn C++ 11
The idea is that this sort of approach to cooperative multithreading
needs thread_local storage specifier, and, basically aspects to
instrument the routine with its semantics of memoizing its results
in the partial monad of the sub-routines' results in the re-launches,
that the re-routine invokes all its asynchronous dependencies going
along, those returning their memoized results if available else
these null-throwing placeholders while launching themselves,
that it results non-blocking routines in re-routines,
with nothing at all about the semantics of asynchrony or callback,
because in the aspect its implicit, in the language,
in the defined behavior of the language and runtime.
So, right, it's not runtime or library coroutines or in the language
anything at all with the semantics of asynchrony, the idea is
re-routines that can be sort of implemented in regards to there
being virtual functions for these aspects, and thread_local storage,
and threads, for a pattern (anti-pattern) of non-blocking re-routines.
So, I suppose that would require C++ 11 for threads and thread_local,
while, otherwise it would be a usual simple sort of portability layer.
int *object = NULL;
Zhengyi Fu <i@fuzy.me> wrote or quoted:
int *object = NULL;
This seems to be what's helping the OP, but when you consider
that the subject line is "how to make an object that throws",
you'd actually have to say that the thrower here is not an
object, but rather the /absence of an object/.
This of course has to do with how objects are specified.
In C++, an expression can stand directly for an object, so
an assignment copies that object. In other languages,
objects
are always implicitly specified by references/pointers, and
an assignment copies that reference/pointer.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 300 |
Nodes: | 16 (2 / 14) |
Uptime: | 02:09:11 |
Calls: | 6,706 |
Calls today: | 6 |
Files: | 12,235 |
Messages: | 5,350,059 |