I have some simple C++ code which won't be compiled by the Clang based C++11 compiler bccaarm of C++ Builder 10.1 Berlin.
This is the code:
TComponent* Comp = new TComponent(this);
std::vector<TComponent*> Comps;
Comps.push_back(Comp);
And this is the error:
[bccaarm error] stl_iterator.h(963): rvalue reference to type
'value_type' (aka 'System: classes::TComponent * __strong') can not be
bound to lvalue of type '__borland_class * isTObj __strong' (aka
'System::Classes::TComponent * __strong')
The compiler stops at line 963 in the file stl_iterator.h:
The other C++ compilers bcc32 and bcc32c(also Clang based) have no problems with this code.
When Compis not from type TComponent or another descendant from TObject the code compiles without any problem.
I have no idea what is wrong with this code and why there is a problem with R and L values...
Does anybody know what to do here?
To get the above code compiled the vector type has to be defined as an unsafe pointer.
TComponent* Comp = new TComponent(this);
std::vector<__unsafe TComponent*> Comps;
Comps.push_back(Comp);
I openened a support case for an other problem I had. The embarcadero support gave me the following information which I applied to this problem and it seems to work:
__unsafe tells the compiler that object lifetimes will be handled and no ARC code is generated for the objects
More about this topic:
http://docwiki.embarcadero.com/RADStudio/Berlin/en/Automatic_Reference_Counting_in_C%2B%2B#weak_and_unsafe_pointers
Related
A snip of Rust code:
pub fn main() {
let a = "hello";
let b = a.len();
let c =b;
println!("len:{}",c)
}
When debugging in CLion, Is it possible to evaluate a function? For example, debug the code step by step, now the code is running to the last line println!... and the current step stops here, by adding the expression a.len() to the watch a variable window, the IDE can't evaluate the a.len(). It says: error: no field named len
This is the same reason you can't make conditional breakpoints for Rust code:
Can't create a conditional breakpoint in VSCode-LLDB with Rust
I hope, I'm not too late to answer this, but with both lldb and gdb, Rust debugging capability is currently rather constrained.
Expressions that are straightforward work; anything complex is likely to produce issues.
My observations from rust-lldb trying this, are that only a small portion of Rust is understood by the expression parser.
There is no support for macros.
Non-used functions are not included in the final binary.
For instance, since that method is not included in the binary, you are unable to execute capacity() on the HashMap in the debugger.
Methods must be named as follows:
struct value.method(&struct value)
There is no technique that I've discovered to call monomorphized functions on generic structs (like HashMap).
For example, "hello" is a const char [5] including the trailing NUL byte. String constants "..." in lldb expressions are produced as C-style string constants.
Therefore, they are not valid functions
The old syntax in the 6.5.0 that works for this statement:
set {int}(&FlashBufferStart+$EraseCnt*2+0) = 0x1000
This would mean placing value 0x1000 into into into the allocated address.
With the new 10.2.0 this sentence will result an error:
Cannot perform pointer math on incomplete type "<data variable, no debug info>"
I have tried using type casting parenthesis, {int} , {void*}, or value might just ended totally different, I have seen similar post for this error but it didn't solve the issue. Any idea?
With the new 10.2.0 this sentence will result an error:
It appears that GDB doesn't know the type of FlashBufferStart.
GDB-6.5 probably assumed that this is a char (or maybe in int), and silently performed arithmetic corresponding to the assumed pointer type.
GDB=6.10 is telling you that it doesn't understand what you want it to do instead.
Solution: cast &FlashBufferStart to appropriate pointer type, so GDB knows what you want.
I was going through a project code in C. In there, I saw this declaration of thread :
pthread_t ui_thread = (pthread_t) 0;
I didn't understand the part starting from '=' operator. What is it and how can I code the same declaration in C++.
(pthread_t) 0 converts the literal integer value 0 to a thread handle pthread_t. This assumes that such a conversion is possible, and valid, and that this is a meaningful value (probably expected to be "no thread").
The full statement creates a variable ui_thread which is a thread handle of type pthread_t, and initializes it with this value.
In C++, you could probably write the same if you were on a platform where it was valid for C. However, you would be better to use the C++ thread library.
std::thread t;
will create a default-constructed thread handle with no associated thread, which is likely the equivalent to the above.
The (pthread_t) part is known as type casting in C. Also called explicit type conversion. It is just a way for the programmer to inform the compiler that the programmer means for the value (0 in this case) to be treated as the type pthread_t.
The code you have is still valid C++.
In C++11 you can probably just do this:
pthread_t ui_thread{nullptr};
With the new Xcode 7.0 GM (Apple LLVM version 7.0), the clang static analyser flags the following code as "called C++ object pointer is uninitialized".
auto&& x = T();
x.hello(); // issue at this point
However I'm pretty sure the rvalue reference x extends the lifetime of the temporary constructed by T(), so the x at the marked line is definitely still alive. I can confirm this at runtime by getting the constructors and destructors to log their calls.
Also if I substitute const auto& x = T();, the issue also goes away. I would do that myself but the exact issue is rather to a range-for loop, so I can't change the nature of the reference.
Is the analyzer over-zealous here?
See the reference initialization rules: http://en.cppreference.com/w/cpp/language/reference_initialization
What's happened with CMutablePointer and CConstPointer in Xcode Beta3?
Code that successfully compiles in Beta2 fails with the errors:
Use of undeclared type 'CMutablePointer'
Use UnsafePointer and ConstUnsafePointer respectively.
From the Release Notes:
APIs imported from C that use C pointers are now imported with a much simpler API type
structure which is more predictable, preserves const mutability in more cases, and preserves
__autoreleased pointer information. Now you will see UnsafePointer,
ConstUnsafePointer, AutoreleasingUnsafePointer, etc. Function pointers are also
imported now, and can be referenced and passed around. However, you cannot call a C
function pointer or convert a closure to C function pointer type.!