I have just started exploring into the world of GCC plugins API and I'm trying to extend GCC for the following example.
class Foo { ... };
Foo* f = __construct Foo(); // __construct is meant to be a new keyword
Ideally, I'd like the plugin to simply replace __construct with something like new (foo_class_info), so you'll end up with
Foo* f = new (foo_class_info) Foo();
where foo_class_info has been made available via PLUGIN_FINISH_TYPE callback (i.e. __construct cannot be replaced at the preprocessor pass).
What would be the right / easiest way to achieve this? I don't even mind combining some user-land template codes with the plugin.
Would adding a new pass be the way to go? If so, I could really use some pointers.
Plugins fundamentally cannot change the syntax.
The most you can do is add a new pragma, attribute, or builtin, then do something with that in a later pass.
Related
In this question, I've given examples of package/object that :
implement some functions.
are used to define other functions by only making them availaible to those functions. It means. I don't write a function body but only a spec with "using package_name" or "using package_body" in the end.
I suppose that the way to use my pakcage/object to implement another function is defined somewhere.
I would like to know if there a way to define myself how to use a package/object. I want a way to implement a functions without writing the body everytime but only by writing in the spec that the function is using my package.
What I'm asking for is similar to already implemented function in a interface in java or an extention method in c#.
P.S. : I don't think that title is very clear. I would be glad if someone would propose another title.
I want a way to implement a functions without writing the body everytime but only by writing in the spec that the function is using my package.
You cannot define a function/procedure that references an SQL stored function/procedure like that. If you declare a function or procedure then it must include the signature and the body.
From the documentation:
create_function::=
plsql_function_source ::=
For a standalone function the body is required.
For a call specification, you can reference a function but it will be an external Java method or a C function and NOT another function defined in SQL.
I have a function that takes a variadic template parameter as its input. What I really need to do is use some kind of magic container (typelist, tuple, etc.) to feed this function parameter. The main problem is that this magic container needs to be dynamically assembled at runtime based on inputs to previous function calls.
Standard tuple generation obviously cannot work in this environment, so I believe some type of wrapper or helper with some typename mangling is in order, but the way to do so eludes me. Some example pseudo-code of what I'm trying to do follows. The user will call AddComponent() any number of times to add a number of components to an owning manager. For each instance of AddComponent(), I need to store the passed in 'Component' type to the magic container so that I end up with a container of all the Component types that have been added. After all this, I need to call GetView() using the assembled typename list as the parameter to the variadic template. A tuple fits best here, but how to correctly assemble it? Here's the code:
template<typename Component, typename ... Args>
void Blueprint::AddComponent(ComponentUsage usage, Args&& ... args)
{
// Create component object with given args
// Add 'Component' type to magic container
}
template<typename ... Component>
EntityView<Component...> EntityManager::GetView()
{
// Create view from list of component types
}
What you're describing sounds a lot like a builder pattern and you can get similar behavior with syntax like this:
// view would be EntityView<Location, Enemy, Flying>
auto view = makeBlueprint()
.AddComponent<Location>(...)
.AddComponent<Enemy>(...)
.AddComponent<Flying>(...)
.GetView();
This would use a dynamic builder where each component added would create a slightly different builder like Builder<> then .AddComponent<Location>() would return a Builder<Location> and then Builder<Location, Enemy> and so on.
However, this is still does not allow for dynamic typing; something like this would not work:
auto blueprint = makeBlueprint()
.AddComponent<Location>(...)
.AddComponent<Enemy>(...);
if (... some check ...)
blueprint = blueprint.AddComponent<Flying>(...);
auto view = blueprint.GetView();
I doubt this solves your problem since must still be dynamically typed and is not "dynamically assembled at runtime". But I hope it offers you insight regardless.
Let's say in Java, I have class CryptoFormat, which has a static method named getLegacyFormat(). When I want to use the method, I just need to call CryptoFormat.getLegacyFormat(). This is clear because I know where the method comes from.
In Go, there is no static method. I don't really want to just make a file called crypto_format.go and define the method there. The reason is that whenever I need the method, I just call GetLegacyFormat(), which doesn't contain the context where the method comes from.
I could think of two ways to solve the problem:
Make a separate package named cryptoformat, and define the method as a global function in the package. This way, I need to make a new package for just few methods. Also, whenever I need static methods like this, I have to define new packages.
Define a struct named cryptoFormat containing method GetLegacyFormat(). Also, define a global public variable named CryptoFormat, which points to an instance of struct cryptoFormat. This way, I can call CryptoFormat.GetLegacyFormat() when I need the method.
I am not sure which one is better, or whether there is better way.
I would say option 1 you mention is the more idiomatic way to define such functions, if they don't need any state that would warrant to tie them to an underlying struct.
If there is some state you'd like to have as context for the function, then option 2 would be the way to go.
Note that in Go, functions are "first class citizens", so you don't have Java's constraints of needing to define a class for static methods.
And yes, if you want a separate namespace you'd need to define separate packages (just as in Java you'd need to define separate classes and/or packages).
If you want your implementation to be idiomatic, I'd suggest you take a look at Go's standard libraries (pick a few packages and explore how they implement their functions) to get a better feeling of the usual ways to structure this.
whenever I need the method, I just call GetLegacyFormat(), which doesn't contain the context where the method comes from.
So add context to the function name.
GetLegacyCryptoFormat()
I'm using C++11 compiler to generate embedded code and I'd like to use lambda functions in it. However I need to put the actual generated code for my lambda functions in a different section or always inline it into the function/method where it is used (by default if some lambda function is not inlined it is put into '.text' section). Is there a way to set section attribute for the lambda function? Alternatively is there a way to make GCC compiler always inline lambda functions?
This will put the lambda in the .mylambdas section
auto myLambda = [&]() __attribute__((section(".mylambdas"))
{
...
};
Note : There's a bug with gcc where it complains if you use the same section name for lambdas in both regular class methods and const class methods. Clang is ok. One workaround is to use another section name for const methods, if that's possible.
I have a mocked DTO class that has properties in it I'm setting via a callback function. This works below for me, but is there a cleaner way to go about it?
Mock<MyDto> _MyDto = new Mock<MyDto>();
_MyDto.Setup(dto => dto).Callback<MyDto>(dto =>
{
dto.FirstName = "John";
dto.LastName = "Doe";
});
I'd like to set those properties in the Setup call if possible, but it accepts an expression and I can't do a multi-line statement in there. But my Linq knowledge isn't encyclopedic and I was wondering if there was a better to approach what I'm doing.
According to the Moq quickstart guide to properties, you could possibly change your code to look like this instead:
_MyDto.SetupProperty(dto => dto.FirstName, "John");
_MyDto.SetupProperty(dto => dto.LastName, "Doe");
I've not yet had the chance to use Moq myself, but this appears to be the way to mock properties in Moq.
I think you misunderstand what the Setup() method is for. You're not supposed to call it just once with all of the initialization code. Instead, you call it once for each individual item that you want to setup.