ICPP – Run C++ anywhere like a script
github.com
github.com
Borrowed this idea from Nothing Real, the developers of Shake, the video/film compositing system.
https://learn.microsoft.com/en-us/windows/win32/api/heapapi/...
> HEAP_CREATE_ENABLE_EXECUTE
> 0x00040000
> All memory blocks that are allocated from this heap allow code execution, if the hardware enforces data execution prevention. Use this flag heap in applications that run code from the heap. If HEAP_CREATE_ENABLE_EXECUTE is not specified and an application attempts to run code from a protected page, the application receives an exception with the status code STATUS_ACCESS_VIOLATION.
I think POSIX has equivalent memory protection calls, but no equivalent to HeapCreate
I don't think Windows provides a mechanism to disable creating any further executable pages, although I've seen Chrome do it by hooking those functions (and I know it because I've had to bypass it :)).
>It just means that whatever foreign data you load into those pages can't execute, which is a security mechanism (for example, game save data can be loaded into these heaps so that you can load all game state but without the save file potentially running foreign code)
But malloc() and all the other standard memory allocation functions already return pointers into non-executable pages, anyway. Perhaps those functions call into this one internally, but using this over whatever your language offers by default offers no additional protection.
a tiny part of points that come to my mind:
- education
- iteration on writing simple functionality
- loading and trying out several APIs to see what's possible (I use it frequently with Elixir / Erlang for example)
It makes life easier for newcomers to wrap their head around something and produce a good solution rather than a "working" one
The advantage of a lot of scripting tech is some form of REPL, which is really just a super-fast code-compile-run loop. In your example, "why?" boils down to how useful/painful those five seconds-per-change are. Maybe that adds up and slows the coder down, or maybe it's no big deal. It all kind of depends on the workflow and how fast you need to be able to iterate on code changes. Moving to a scripted interpreter would eliminate that wait period at the cost of runtime performance, which might be a valuable business tradeoff.
FWIW, that "script" solution sounds awesome for the time. I'll add that five seconds to build a hot-loaded DLL in the 90's is really, really good performance for that solution, regardless of its role as a scripting alternative. Today, that would probably be mere milliseconds to compile - impossible to distinguish from an embedded LUA or JS solution.
Any other great open source tools like this that you can share?
It's just a normal library you can use with any compiled project, but it works nicely with Root C++ for built-in and std types.
Great if (say) you're working through implementing vector or linear algebra and want a nice way to display your multi-dimensional arrays and vectors.
Just copy the project folder somewhere (most conveniently where you invoke the interpreter from), do `#include "cpp-dump/dump.hpp` and then `cpp_dump(myVariable)` to print your variables.
You can see how it looks in this example where I was mucking about with permutations of vectors: https://i.imgur.com/yRpY5Bj.png
All I know is most of the large scale C/C++ code bases eventually become these monolithic giant code bases that require some really specialised software tools to compile and link.
It's clear as mud how one would hook a jumbo codebase into the REPL. If it's possible, that would be a game changer.
Most of the code is here : https://github.com/ossia/score/tree/master/src/plugins/score... with the actual LLVM API interoperation contained there : https://github.com/ossia/score/tree/master/src/plugins/score...
It's been used for fun projects, for instance for this paper about data sonification : https://www.researchgate.net/profile/Maxime_Poret/publicatio...
gdb also doesn't handle overloaded functions well, e.g. `x[i]`.
What does that mean? I think `print str.c_str()` has worked for me in GDB before, but sounds like you did something different.
Some implementations even put char[0] at the first byte in the optimized form.
It doesn't seem possible in actual C++ that the cast from non-pointer to pointer would work at all (even if a small string happens to be inlined at offset 0.) Like GP, I looked for a conversion operator, and I don't think it's there. Maybe it is a feature of the gdb parser.
https://devblogs.microsoft.com/oldnewthing/20240510-00/?p=10...
(gdb) p unrolls_[0]
Could not find operator[].
(gdb) p unrolls_[(long)0]
Could not find operator[].
(gdb) p unrolls_.data_.mem[0]
$2 = {
`unrolls_[i]` works within C++. This `operator[]` method isn't even templated (although the container type is); the index is hard-coded to be of type `ptrdiff_t`, which is `long` on my platform.I'm on Linux, gdb 15.1.
That might be it. If that operator isn’t actually ever emitted out of line, then GDB will (naturally) have nothing to call. If it helps, with the following program
template<typename T>
struct Foo {
int operator[](long i) { return i * 3; }
};
Foo<bool> bar;
template int Foo<bool>::operator[](long); // [*]
int main(void) {
Foo<int> foo;
__asm__("int3");
return foo[19];
}
compiled at -g -O0 I can both `p foo[19]` and `p bar[19]`, but if I comment out the explicit instantiation marked [*], the latter no longer works. At -g -O2, the former does not work because `foo` no longer actually exists, but the latter does, provided the instantiation is left in.https://github.com/vpand/icpp-qt
Ok now things are getting interesting. I think this could be used to add easily shareable/hackable plugins to existing C++ projects.