Is there a way to typecast void pointers in Lauterbach - debugging

I have a structure containing a void pointer but when I need to view the contents of this pointer, I want it to be displayed as a pointer of a particular type. Is there a means to do this within Lauterbach? I tried using the symbol.AddInfo.Type command but it doesn't work as I expect.

I suggest to use a cast operator directly in the watch window.
E.g.: Var.AddWatch (struct struct1 *)pLinkedListBuf

Related

Go pointer dereferencing

I'm currently trying to learn GO and mainly knowing and working with Java, ASP.Net and some Python, there is no experience working with C-like pointers, which causes my current confusion.
A library I'm currently using to write my first GO project is called Commando.
There I have the struct CommandRegistry and the variable of interest is called Commands.
In the struct the variable is described as the following:
// registered command configurations
Commands map[string]*Command
On a first glimpse I would understand this as a Map object containing a list of Strings, however it also shows the pointer reference to the actual Command object.
All I can see is that it is a map I can loop over which returns the name of the command ( the string ),
however I'm wondering if the *Command in the type description means I can somehow dereference the pointer and retrieve the object itself to extract the additional information of it.
As I know the & operand is used to create a new pointer of another object. Pass-by-reference basically instead of pass-by-value.
And the * operand generally signals the object is a pointer or used to require a pointer in a new function.
Is there a way I can retrieve the Command object or why does the type contain the *Command in it's declaration?
Commands is a map (dictionary) which has strings as keys, and pointers to Commands as values. By passing it a key, you will get a pointer to the command it belongs to. You can then dereference the pointer to an actual Command object by using the * operator. Something like dereferencedCommand := *Commands["key"].
The * operator can be quite confusing, at least it was for me. When used as a type it denotes that we are receiving the memory address of some variable. But to dereference a memory address to a concrete type, you also use the * operator.

Polymorphism without methods in go

Note: I'm editing this question to a concrete example of why I want to do this, which is why some of the answers might no longer make sense in context.
I am writing a bit of code that passes data from an input. The data is in the form of tags that have an identifier of what kind of data they contain and then the data.
Unfortunately I have no control over the input and don't know in advance what tags will be in it, one might be an int another might be a string, yet another might be an array of ints.
The problem arises when I need to handle all tags like the same type, for instance if I have a slice of tags, of a function that either accepts or returns a tag.
The solutions I have so far seen to this is to define the slices/functions with an empty interface which would allow me to do so, however that is kinda undesirable as it would not tell anything to other people using the package about what types are expected and also kinda defies the point of having a typed language in the first place.
Interfaces does however seem to be the solution here, and i would love to have a Tag interface to pass around, that does require though that I define methods on them, and there are really no methods they need.
My current solution looks like this
type Tag interface{
implementTag()
}
type TagInt int
func (tag TagInt) implementTag() {}
type TagString string
func (tag TagInt) implementTag() {}
While this does indeed work and solves my problem, having to define dummy methods just for that feels very wrong.
So my question sums up in this: Are there any way that I can define that something is a Tag without having to define dummy methods?
And now want to make a slice that can hold both t1 and t2 but nothing else.
You cannot do that. Sorry.
What I would do in your scenario is accept any type in the parameters with an empty interface then use a type assertion inside to confirm that it's the type that you want.
if t1, ok := interfaceInput.(t1); !ok{
// handle it being the wrong type here
return
}
Also if you want the tight coupling between a data type and it's method, namely an object, what's so wrong with having it be a method of the object?
You can use []interface{} for a "slice of any type" but then it's up to you to use type assertions and/or type switches to discover the actual runtime types of that slice's members.
Learn more about empty interfaces in the Tour of Go
And now want to make a slice that can hold both t1 and t2 but nothing
else.
This is quite an unusual requirement and you're unlikely to need this in Go. But you could also do your own discriminated union with:
type item struct {
typeSelector int
t1Value t1
t2Value t2
}
And then use []item, checking typeSelector at runtime to see which value is populated.
Alternatively you could even use *t1 and *t2 and have nil signify "no value in this field".

iterate over non-const std::unordered_set

I have a std::unordered_set that contains instances of class bar.
I'd like to iterate over all the bars in the set and call some void foo(bar& b) function on each one.
You'll probably notice from the function signature that I want foo to change the state of the bar& b parameter in some way.
Now, I do know that foo won't change bar in a way that affects hashing or equality comparisons, but I still have a problem.
However I iterate over the set, the best I can hope for is a const bar& which obviously won't work.
I can think of a couple of possible ways around this:
Use const_cast. Don't know if this will work (yet). It kind of smells bad to me, but I'm happy to be enlightened!!
Use a std::unordered_map instead of std::unordered_set, so that even if I can only get a const of the key, I can just use that key to lookup the bar object and safely call foo on it.
I'd really appreciate some advice!
Thanks in advance!
Some clean solutions have already been shown in this answer.
Another clean way would be to add a layer of indirection through a pointer. Even if the pointer itself is const, the data pointed to will not be:
struct Bar
{
int key;
std::unique_ptr<int> pValue;
};
std::unordered_set< Bar, BarHash, BarEqual > bars;
for( const auto& bar : bars )
{
// Works because only the pointer is constant, not the data pointed to.
*bar.pValue = 42;
}
This obviously has the overhead of an additional memory allocation, the space required to store the pointer and the indirection when accessing the value through the pointer.
You will also have to write a custom copy constructor and an assignment operator if you want to keep value semantics.
Use const_cast. Don't know if this will work (yet). It kind of smells bad to me, but I'm happy to be enlightened!!
Yes, it will work. You can easily have an overload foo(bar const&), const_cast the reference, and then call foo(bar&). I agree with you that it smells bad and points to a flaw in design. You might want to take a fresh look at the design and see if there is a clean solution.
Use a std::unordered_map instead of std::unordered_set, so that even if I can only get a const of the key, I can just use that key to lookup the bar object and safely call foo on it
That is not too different from the first approach. std::unordered_set<T> is essentially std::unordered_map<T, bool>.
Potential clean solutions:
Get a copy of the object from the set, remove the entry from the set, update the copy, and put the copy back in the set. If that proves too expensive ...
Use a std::vector<Bar>. You can get a Bar& from the vector and all is well.
Make the member variables of Bar that don't impact its hash value to be mutable. Then, you can just use foo(Bar const&) and be able to call it directly using a reference to the objects in the set.

what should be used New() or var in go?

How a object should be created for a struct?
object := new(struct)
or
var object struct
I could not understatnd when to use what? and if both are same which one should be prefered?
The new syntax you're showing returns a pointer while the other one is a value. Check out this article here; https://golang.org/doc/effective_go.html#allocation_new
There's actually even one other option which I prefer. It's called composite literal and looks like this;
object := &struct{}
The example above is equivalent to your use of new. The cool thing about it is you can specify values for any property in struct within the brackets there.
When to use what is a decision you need to make on a case by case basis. In Go there are several reasons I would want one or the other; Perhaps only the pointer *myType implements some interface while myType does not, an instance myType could contain about 1 GB of data and you want to ensure you're passing a pointer and not the value to other methods, ect. The choice of which to use depends on the use case. Although I will say, pointers are rarely worse and because that's the case I almost always use them.
When you need a pointer object use new or composite literal else use var.
Use var whenever possible as this is more likely to be allocated in stack and memory get freed as soon as scope ends. I case of new memory gets allocated most likely in heap and need to be garbage collected.

using new vs. { } when initializing a struct in Go

So i know in go you can initialize a struct two different ways in GO. One of them is using the new keyword which returns a pointer to the struct in memory. Or you can use the { } to make a struct. My question is when is appropriate to use each?
Thanks
I prefer {} when the full value of the type is known and new() when the value is going to be populated incrementally.
In the former case, adding a new parameter may involve adding a new field initializer. In the latter it should probably be added to whatever code is composing the value.
Note that the &T{} syntax is only allowed when T is a struct, array, slice or map type.
Going off of what #Volker said, it's generally preferable to use &A{} for pointers (and this doesn't necessarily have to be zero values: if I have a struct with a single integer in it, I could do &A{1} to initialize the field). Besides being a stylistic concern, the big reason that people normally prefer this syntax is that, unlike new, it doesn't always actually allocate memory in the heap. If the go compiler can be sure that the pointer will never be used outside of the function, it will simply allocate the struct as a local variable, which is much more efficient than calling new.
Most people use A{} to create a zero value of type A, &A{} to create a pointer to a zero value of type A. Using newis only necessary for int and that like as int{} is a no go.

Resources