I have the following code that used to compile and work fine:
std::vector<unsigned char> marshal_as(cli::array<System::Byte>^ const& from)
{
std::vector<unsigned char> result;
result.reserve(from->Length);
for (int i = 0; i < from->Length; i++)
{
result.push_back(from[i]);
}
return result;
}
After updating VisualStudio to version 16.10 - which updates the C++ compiler to version 14.29 - the code produces an error:
error C2664: 'void std::vector<unsigned
char,std::allocator<_Ty>>::push_back(const _Ty &)': cannot convert
argument 1 from 'unsigned char' to 'const _Ty &'
with
[
_Ty=unsigned char
]
message : An object from the gc heap (element of a managed array) cannot be converted to a native reference
message : see
declaration of 'std::vector<unsigned
char,std::allocator<_Ty>>::push_back'
with
[
_Ty=unsigned char
]
Changing the code in the loop body to
unsigned char b = from[i];
result.push_back(b);
fixes the problem.
I would like to understand the cause of this error. Is this somehow related to a change due to the C++ 20 standard?
Is this somehow related to a change due to the C++ 20 standard?
No. While std::vector<>::push() has subtly changed in C++20, it's not a change that materially affects what's going on here, the issue is definitely clr-specific.
I would like to understand the cause of this error.
This is almost certainly (see below) an error that was always present in your code, but was not being reported by previous versions of the C++/CLI compiler.
Consider the following function:
void foo(const int& v) {
int* ptr = &v;
// store ptr somewhere, long-term.
}
It's obvious that invoking foo() with a reference to a gc-backed int would be a recipe for disaster. Yet that's exactly what result.push_back(from[i]); does.
Your code "works" because push_back() happens to do nothing with its parameter that causes an issue. However, the compiler is not supposed to know that.
N.B. I say almost certainly because I'm having a heck of a time tracking down the call signature for cli::array<T>::operator[](std::size_t) const. It's not impossible that it used to return a T and now returns const T%.
Related
#include<stdio.h>
int main ()
{
printf("%d\n",z);
return 0;
}
int z=25;
why is output to this code is showing an error ?
The order in which you declare your functions/variables count in C. In your code, when the compiler parses your code, it encounters the symbol z, which has not yet been declared.
So, you need to put your int z = ... before the first time you use z, hence before main.
The extern keyword tells the compiler that the variable has been declared in another file, so it will be resolved during linking, i.e. when all the files are assembled into a program. So for the compilation of this file, the unresolved symbol z can be ignored => no compilation error.
Try this :
#include<stdio.h>
int z=25;
int main ()
{
printf("%d\n",z);
return 0;
}
What is the difference between:
var arr3 = new Vector.<int>(6);
to
var arr3:Vector.<int> = new Vector.<int>(6);
Thanks!
It's the difference between declaring a variable type and not. While declaring a type is optional in AS3, best practice is to always declare a type.
The effect on your code this has is that if you declare a type, it will only compile and run properly if values of that type are assigned to the variable, and it will always be treated strictly as that type of object and nothing else. This is called "type safety". If you don't declare a type, you can assign anything to that variable and write code as if its any kind of object -- which may sound convenient, but it ends up making the code much more confusing, fragile and error prone.
Also note that not declaring a type is equivalent to declaring it as a "wildcard" type, like this: var arr3:*
Here's an example of untyped vs typed variables in code:
var untyped:*;
var string:String;
var number:Number;
var integers:Vector.<int>;
untyped = 1; // ok
untyped = "hello"; // ok
untyped = new Vector.<int>(); // ok
string = 1; // compile error
string = "hello"; // ok
string = new Vector.<int>(); // compile error
number = 1; // ok
number = "hello"; // compile error
number = new Vector.<int>(); // compile error
integers = 1; // compile error
integers = "hello"; // compile error
integers = new Vector.<int>(); // ok
if (untyped == 1) // ok
if (untyped == "hello") // ok
if (untyped.fixed) // compiles ok, but throws runtime error if "fixed" not defined on non-dynamic object
if (string == 1) // compile error, invalid comparison
if (string == "hello") // ok
if (string.fixed) // compile error, "fixed" not a property of String
if (number == 1) // ok
if (number == "hello") // compile error, invalid comparison
if (number.fixed) // compile error, "fixed" not a property of Number
if (integers == 1) // compile error, invalid comparison
if (integers == "hello") // compile error, invalid comparison
if (integers.fixed) // ok
These compile errors serve to show you mistakes you (or other developers) make before they become hard to hunt down problems in your SWF. For example, consider this untyped code:
var value = "hello";
if (value.x < 10) { }
That code doesn't make much sense, but it will compile. Then you will hit a runtime error when it tries to execute the if statement and can't find x on String "hello". In real life you might have a lot of hunting around to do to figure out what's wrong, especially if those 2 lines are not in close proximity to each other. However, if the programmer had specified a type on the variable, it would make the code more type safe:
var value:Point;
if (value.x < 10) { }
In this case the code would not compile if you tried to assign value = "hello". The compiler would also validate that x is a property of type Point. If it wasn't, you'd get a compile error there, too. It even knows that x can be compared using < because it's a Number. This is all helpful to catch errors early rather than later.
In addition to making the code more clear to programmers, it also makes it more clear to authoring tools -- most authoring tools will give you much better code-completion suggestions for typed objects, since it knows exactly what properties and methods that type of object has.
For these reasons and probably others, you'll rarely find AS3 code examples that don't use strict type declarations, and most programmers (including me) will advise you always use them.
Use second option. In first case you will get warning message:
Warning: Error code: 1008: variable 'arr3' has no type declaration.
The first variable is untyped. If you declare a variable, but do not declare its data type, the default data type ***** will apply, which actually means that the variable is untyped. If you also do not initialize an untyped variable with a value, its default value is undefined.
The second one is typed as Vector.. A variable declared with the Vector. data type can only store a Vector instance that is constructed with the same base type int. For example, a Vector that's constructed by calling new Vector.() can't be assigned to a variable that's declared with the Vector. data type.
Good answers from everyone. But the real answer goes a lot further. In case 1 the variable has no type and in case 2 the variable has a type. The difference is that in the second case the compiler is able to provide you with information in case something in your code goes wrong. In the first case the compiler might be able to provide some info or even no info at all in case something goes wrong in your code. If you work with untyped variables (case 1) you the developer are on your own if there's any error in your code. You'll be the one to look for them and try to fix them. In the second case the compiler will tell you where there's an error and most likely why there's an error.
I am trying to test out some exception handling code running on an ARM7 TDMI processor. I am wanting to manually create an instruction opcode which will generate the "Undefined instruction" exception. So far, I've done this:
void createUndefinedException()
{
static const int instr = 0x26889912; // bad opcode
((void(*)(void))instr)();
}
I arrived at the above opcode because of a reference page I found today on the web that talks about undefined instruction opcodes at the very bottom.
The above code generates the prefetch abort exception instead of the undefined instruction exception.
Anyone have an idea of how to create this easily?
I just want to verify my handling of this exception is going to work properly.
create an asm file
.globl test_function
test_function:
.word 0x26889912
bx lr
assemble it
arm-none-linux-gnueabi-as fun.s -o fun.o
call it from your C code
extern void test_function ( void );
...
test_function();
then add it to the list of objects you are linking
arm-none-linux-gnueabi-gcc myprogram.c fun.o -o myprogram
and run it.
You need to create a function out of the address of the int:
typedef void (*Exception)(void)
static unsigned long illegalOpcode=0x26889912;
Exception e=(Exception)&illegalOpcode;
e();
#include "stdio.h"
int main (void) {
char xx[1000] = "hello";
sprintf (xx, "xyzzy plugh %s", xx);
printf ("%s\n", xx);
return 0;
}
::::(error) Undefined behaviour: xx is used wrong in call to sprintf or snprintf. Quote: If copying takes place between objects that overlap as a result of a call to sprintf() or snprintf(), the results are undefined.
Precisely what it says. You are passing the same array both as input and output to sprintf(), which is not a supported usage as there is no guarantee that sprintf will write the output string in ascending order.
You are writing into char array xx as well as using it as the source for the copy. This behaviour is undefined. Here's an existing question about the situation:
Is sprintf(buffer, "%s […]", buffer, […]) safe?
This has been driving me nuts for 3 hours. Anybody see a reason why this isn't working?
struct sortByPropRev
{
bool operator()(const cust_type &a, const cust_type &b) const
{
return a.prop > b.prop;
}
};
...
priority_queue<cust_type, vector<cust_type>, sortByPropRev> x;
I get compile errors:
Error C2664: 'bool (cust_type &,cust_type &)' : cannot convert parameter 1 from 'const cust_type' to 'cust_type &'
and 2 more just like it but on different lines of algorithm.h
You gave it b.pprop, vs a.prop. I think given the error that the compiler failed to parse the struct's definition properly- check for syntax errors in the code just above it.
Never mind. I found the problem. I t was in a different part of the code that was calling the same algorithm functions. Sorry to bother everybody and thanks for trying to help.