I have this code:
DispatcherTimer^ CalenderClock();
When I use * instead of ^ visual studio tells me:
an ordinary pointer to C++\CX mapping ref class or inteface class is not allowed
what is the difference between ^ and * pointers?
The handle-to-object operator ^ is known as a "hat" and is fundamentally a C++ smart pointer. The memory it points to is automatically destroyed when the last hat goes out of scope or is explicitly set to nullptr.
Source: https://learn.microsoft.com/en-us/cpp/cppcx/ref-classes-and-structs-c-cx (Found by googling your error message.)
Note that this syntax is non-standard. It is a Microsoft extension to the C++ language.
Related
I have a script to work out how much free stack space there is in each FreeRTOS task. GDB’s language is set to auto. The script works fine when the current language is c, but fails when the current language is ada.
I have, in the class Stacks,
tcb_t = gdb.lookup_type("TCB_t")
int_t = gdb.lookup_type("int")
used to:
find {Ada task control block}.Common.Thread,
thread = atcb["common"]["thread"]
convert to a pointer to the FreeRTOS task control block,
tcb = thread.cast(Stacks.tcb_t.pointer()).dereference()
find the logical top of the stack
stk = tcb["pxStack"].cast(Stacks.int_t.pointer())
Now I need to loop logically down the stack until I find an entry not equal to the initialised value,
free = 0
while stk[free] == 0xa5a5a5a5:
free = free + 1
which works fine if the current frame’s language is c, but if it’s ada I get
Python Exception <class 'gdb.error'> not an array or string:
Error occurred in Python command: not an array or string
I’ve traced this to the expression stk[free], which is being interpreted using the rules of the current language (in Ada, array indexing uses parentheses, so it would be stk(free), which is of course illegal since Python treats it as a function call).
I’ve worked round this by
def invoke(self, arg, from_tty):
gdb.execute("set language c")
...
gdb.execute("set language auto")
but it seems wrong not to set the language back to what it was originally.
So,
is there a way of detecting the current GDB language setting from Python?
is there an alternate way of indexing that doesn’t depend on the current GDB language setting?
I have found similar questions but none that worked for my situation, so I am asking my own.
I want to use a library function that takes a pointer to a std::vector, and fills it with data.
I already have a C++/CLI Wrapper set up.
I am currently trying to instantiate the vector in the wrapper,
private:
std::vector<int>* outputVector
and in the constructor, I instantiate it :
outputVector = new std::vector<int>();
Now, in the wrapper method that calls the c++ library function :
m_pUnmanagedTPRTreeClass->GetInRegion(..., &outputVector)
I omitted the other parameters because they dont matter for this case. I can already use other functions of the library and they work without a problem. I just can't manage to pass a pointer to a std::vector.
With the code like this, I get the error message :
error C2664: 'TPSimpleRTree<CT,T>::GetInRegion' : cannot convert parameter 3 from 'cli::interior_ptr<Type>' to 'std::vector<_Ty> &'
I have tried removing the "&", as I am not great at C++ and am unsure how to correctly use pointers. Then, the error becomes :
error C2664: 'TPSimpleRTree<CT,T>::GetInRegion' : cannot convert parameter 3 from 'std::vector<_Ty> *' to 'std::vector<_Ty> &'
EDIT: I have tried replacing "&" by "*", it does not work, I get the error :
cannot convert from 'std::vector<_Ty>' to 'std::vector<_Ty> &'
The signature of the c++ function for the vector is so :
GetInRegion(..., std::vector<T*>& a_objects)
Given the signature:
GetInRegion(..., std::vector<T*>& a_objects)
You would call this (in C++ or C++/CLI) like:
std::vector<int*> v;
m_pUnmanagedTPRTreeClass->GetInRegion(..., v);
Then you can manipulate the data as needed or marshall the data into a .Net container.
'std::vector<_Ty> *' to 'std::vector<_Ty> &'
is self explanatory, you need to dereference instead of taking a pointer, so instead of:
m_pUnmanagedTPRTreeClass->GetInRegion(..., &outputVector)
use:
m_pUnmanagedTPRTreeClass->GetInRegion(..., *outputVector)
^~~~~~~!!
after your edit I see your getinregion signature is:
GetInRegion(..., std::vector<T*>& a_objects)
so it accepts std::vector where T is a pointer, while you want to pass to getinregion a std::vector where int is not a pointer.
Suppose I have a vector, v: Vec<T> with length 5 and capacity 10. Does the following invoke undefined behavior?
let p = v.as_mut_ptr();
unsafe {
std::mem::swap(p, p.offset(5));
std::mem::swap(p.offset(5), p);
}
Yes, this is undefined. From Section 6.1.3.2.3 of the Rust Reference:
The following is a list of behavior which is forbidden in all Rust code, including within unsafe blocks and unsafe functions. Type checking provides the guarantee that these issues are never caused by safe code.
...
Reads of undef (uninitialized) memory
...
p.offset(5) is undefined memory and you have to read it to be able to swap it.
Of course, I don't really see the point to your question, as even if it were defined, the operation would be a no-op. I suspect that this is an artifact of the XY Problem, and that you have an actual problem you are trying to solve.
I tried to do some simple UIView layout math in swift and tried the following line of code...
var offset: CGFloat = (bounds.width / 2.0) - ((sortedSymptoms.count * bounds.height) / 2.0)
and got the following error from the compiler:
cannot invoke '-' with an argument list of type '(($T6), ($T17))'
var offset: CGFloat = (bounds.width / 2.0) - ((sortedSymptoms.count * bounds.height) / 2.0)
~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The compiler error isn't all that helpful, but it looks like there's a type conflict between Double, Int, and CGFloat of some kind. I was able to get the line to compile by sprinkling in some explicit creations of CGFloats, but I can't believe that this is the right way to do this.
var offset: CGFloat = (bounds.width / CGFloat(2.0)) - ((CGFloat(sortedSymptoms.count) * bounds.height) / CGFloat(2.0))
What's the right way?
This is a known issue in Swift and the dev team has been working on improving the issue around CGFloat in particular. But at this time, yes, that's how you write it.
Some followup from devforums (which may make you happy or sad, but at least roughly explains the current status): https://devforums.apple.com/message/1026028#1026028
Note that the main issue here is that the literal 2.0 doesn't coerce to CGFloat, which it arguably should. But count will likely always require a cast, by intent. You cannot always safely convert between numeric types, and Swift intentionally forces you to consider each time you do these kinds of casts. But it should be possible to determine if a literal conversion is safe at compile-time, so that should be fixable.
I would like to check if a pointer inside a derived type has already been defined or not. I wrote the following simple code to show you my problem:
program test
implicit none
type y
real(8), pointer :: x(:)
end type y
type(y), pointer :: w(:)
allocate(w(2))
allocate(w(1)%x(2))
write(*,*) associated(w(1)%x), associated(w(2)%x)
end program test
Compiling this code with gFortran 4.4.1 and running it on Ubuntu gives the result:
T F
whereas the same code compiled on Windows Vista with the Intel Fortran compiler 11.0 provides:
T T
The first result (gFortran) is what I am actually expecting. But the fact that the Intel compiler provides a different result makes me fear my code might not be correct. Am I doing something terribly wrong with the pointers in this example? Any idea or explanation?
Many thanks in advance for your help!
You are testing to see if a pointer is associated without explicitly using nullify on the pointers. A great page on common Fortran mistakes remarks (with the code sample removed):
Many people think that the status of a pointer which has never been associated is .not. associated. This is false. (...) When a pointer is declared its status is undefined, and cannot be safely queried with the associated intrinsic.
It looks like the gfortran compiler may be set up to explicitly nullify pointers on declaration - you should probably think of this like the compiler automatically setting declared variables to zero, and not count on that behavior. If you want to be sure, you will nullify it yourself.
Edit:
I'm reading through the Intel compiler guide, and it specifies how to make sure that the pointer is nullified correctly - you can set up your derived type as
type y
real(8), pointer :: x(:) => null()
end type y
Note, however, that it seems like this is limited to Fortran 95, as mentioned in the linked article.