I have two different variables defined as ^Byte as in:
var
P1 : ^Byte;
P2 : ^Byte;
Yet when I I try:
P1:=P2;
it says Type mismatch yet I can do:
P1:=Pointer(P2);
Coming from C, I don't get it? Wouldn't P1 and P2 be the value of the pointer and when you want to access what it points to you would use P1^ and P2^ and if you use #P1 or #P2 you are getting the address to the pointer variable itself?
What am I missing?
Afaik in classic (70's) standard pascal this should work. But Turbo Pascal adn Delphi and derivatives went a different route, and consider both ^byte's declaration of new separate types.
Solution: declare pbyte = ^byte; and use pbyte everywhere. If you are using a recent Delphi or Free Pascal, pbyte is already predefined or in unit types.
Related
I wonder if there is something like a UINT_MAX (= 65535) define in any of the twincat3 system libraries.
I've also never seen them. But you could create them easily as follows
PROGRAM MAIN
VAR
number : UINT;
UINT_MAX : UINT;
END_VAR
UINT_MAX := number - 1;
You could also do it with just a single variable UINT_MAX := UINT_MAX - 1;, but then you have to make sure the 1 only gets subtracted once.
The easiest would be to define them once in a global variable list and make that into a library.
There does not appear to be anything specific inside of TwinCAT that does what you are looking for. There is something similar however inside of the C layer of objects though.
UINT
There are multiple versions of UINT inside the type system (UINT, UINT24, UINT40, UINT48, UINT56) which are all devoted to the same informational range and values.
When viewed inside of the TMC handling (Datatypes), each of these datatypes has 2 properties:
DisplayMinValue: #x0000
DisplayMaxValue: #xFFFF
Implementation and access to these properties appears to be limited to access via the C interface and unavailable from inside TwinCAT itself, but they are there.
Another way around this problem is using the bitwise operator NOT. Define a UINT called UINT_MAX and use the following snippet during the first cycle of the PLC:
UINT_MAX := NOT UINT_MAX;
Is there a way to use the reflection libraries in Go to go from the name of a type to its Type representation?
I've got a library where the user needs to provide Type representations for some code generation. I know it must be possible (in a sense) because they can just create a variable of that type and call the TypeOf function, but is there a way to circumvent this and just get representation from the name?
The question is not quite explicit, it can be interpreted in 2 ways, to one of which the answer is no, not possible; and the other to which the answer is yes, it's possible.
At runtime
If the type name is provided as a string value, then at runtime it's not possible as types that are not referred to explicitly may not get compiled into the final executable binary (and thus obviously become unreachable, "unknown" at runtime). For details see Splitting client/server code. For possible workarounds see Call all functions with special prefix or suffix in Golang.
At "coding" time
If we're talking about "coding" time (source code writing / generating), then it's possible without creating / allocating a variable of the given type and calling reflect.TypeOf() and passing the variable.
You may start from the pointer to the type, and use a typed nil pointer value without allocation, and you can navigate from its reflect.Type descriptor to the descriptor of the base type (or element type) of the pointer using Type.Elem().
This is how it looks like:
t := reflect.TypeOf((*YourType)(nil)).Elem()
The type descriptor t above will be identical to t2 below:
var x YourType
t2 := reflect.TypeOf(x)
fmt.Println(t, t2)
fmt.Println(t == t2)
Output of the above application (try it on the Go Playground):
main.YourType main.YourType
true
I'm trying to understand the definition of the keyword TYPE in pascal. I understand that typedef in C just gives a new name to the type (alasing). But as I understand TYPE in Pascal does not work that way. It will create a new unique type.
I was trying to search and create a simple example which shows the mechanism of TYPE. I tried to create an example which creates some types and a function. After that, it pass each time one of the types to that function. It should fail because the function should get only one type, which proves that those types are not just aliasing. Due to my lack of knowledge of Pascal syntax, I failed each time.
Could you share a simple short program which proves the power of TYPE?
EDIT:
I have created the following example:
program Check;
TYPE
Meters = Real; Seconds = Real;
VAR
m: Meters; s: Seconds;
Procedure PRINT_SEC(s: Seconds);
Begin
WriteLn(s, ' sec');
end;
Begin
PRINT_SEC(s);
PRINT_SEC(m);
end.
Output:
0.0000000000000000E+000 sec
0.0000000000000000E+000 sec
But why it does not fail? I passed m which has type Meters no? Also, How can I initialize those variables?
First a minor point, in Pascal, the keyword TYPE does not create types. The keyword TYPE must occur before type definitions, but it is the type definitions which MAY create types. Not all type definitions create types.
The Pascal Standard says the following:
A type-definition shall introduce an identifier to denote a type.
which means a type definition introduces (i.e. creates or redefines) an identifier which denotes (i.e. is an alias for) a type.
The Pascal Standard defines a type definition as:
type-definition = identifier '=' type-denoter
type-denoter = type-identifier | new-type
new-type = new-ordinal-type | new-structured-type | new-pointer-type
Which means that a type definition is a identifier, followed by the equal side, followed by a type denoter. A type denoter is either a type identifier or a new type.
So a type identifier introduces an identifier that denotes (i.e. is an alias for) either another type identifier or a new-type. A type is created only in the case where the type denoter is a new type.
So in your example:
TYPE
Meters = Real; Seconds = Real;
The type denoter in both type definitions is the type identifier Real, so Meters and Seconds are both aliases for Real.
Yes, in Pascal, Real is not a Type, it is a built-in type identifier for the real type.
The Pascal Standard says
The required type identifier real shall denote the real-type.
So real is actually a type identifier and not a type. It is as if, there is an invisible type definition.
TYPE
Real = real-type;
where real-type is the actual real type.
Variables like m and s are defined by a type. In this case both types origins from a real type. That is called a type alias. They are compatible, both as a type and by assignment.
If you want a distinct type (in Freepascal and delphi), define:
type Seconds = type real;
That would have made the print procedure to only accept the Seconds type argument. Note that variables of Seconds and Meters declared as distinct types still are assignment compatible.
To initialize variables, just assign a value:
s := 42.0;
Note: most types are named starting with a T. Like TSeconds. Just to distinct them from variables. It is a common convention (in pascal).
Is there a way to use the reflection libraries in Go to go from the name of a type to its Type representation?
I've got a library where the user needs to provide Type representations for some code generation. I know it must be possible (in a sense) because they can just create a variable of that type and call the TypeOf function, but is there a way to circumvent this and just get representation from the name?
The question is not quite explicit, it can be interpreted in 2 ways, to one of which the answer is no, not possible; and the other to which the answer is yes, it's possible.
At runtime
If the type name is provided as a string value, then at runtime it's not possible as types that are not referred to explicitly may not get compiled into the final executable binary (and thus obviously become unreachable, "unknown" at runtime). For details see Splitting client/server code. For possible workarounds see Call all functions with special prefix or suffix in Golang.
At "coding" time
If we're talking about "coding" time (source code writing / generating), then it's possible without creating / allocating a variable of the given type and calling reflect.TypeOf() and passing the variable.
You may start from the pointer to the type, and use a typed nil pointer value without allocation, and you can navigate from its reflect.Type descriptor to the descriptor of the base type (or element type) of the pointer using Type.Elem().
This is how it looks like:
t := reflect.TypeOf((*YourType)(nil)).Elem()
The type descriptor t above will be identical to t2 below:
var x YourType
t2 := reflect.TypeOf(x)
fmt.Println(t, t2)
fmt.Println(t == t2)
Output of the above application (try it on the Go Playground):
main.YourType main.YourType
true
uint32_t u32 = 0;
uint16_t u16[2];
static_assert(sizeof(u32) == sizeof(u16), "");
memcpy(u16, &u32, sizeof(u32)); // defined?
// if defined, how to we access the data from here on?
Is this defined behaviour? And, if so, what type of pointer may we use to access the target data after the memcpy?
Must we use uint16_t*, because that suitable for the declared type of u16?
Or must we use uint32_t*, because the type of the source data (the source data copied from by memcpy) is uint_32?
(Personally interested in C++11/C++14. But a discussion of related languages like C would be interesting also.)
Is this defined behavio[u]r?
Yes. memcpying into a pod is well-defined and you ensured that the sizing is the correct.
Must we use uint16_t*, because that suitable for the declared type of u16?
Yes, of course. u16 is an array of two uint16_ts so it must be accessed as such. Accessing it via a uint32_t* would be undefined behavior by the strict-aliasing rule.
It doesn't matter what the source type was. What matters is that you have an object of type uint16_t[2].
On the other hand, this:
uint32_t p;
new (&p) uint16_t(42);
std::cout << p;
is undefined behavior, because now there is an object of a different type whose lifetime has begin at &p and we're accessing it through the wrong type.
The C++ standard delegates to C standard:
The contents and meaning of the header <cstring> are the same as the C standard library header <string.h>.
The C standard specifies:
7.24.1/3 For all functions in this subclause, each character shall be interpreted as if it had the type unsigned char (and therefore every possible object representation is valid and has a different value).
So, to answer your question: Yes, the behaviour is defined.
Yes, uint16_t* is appropriate because uint16_t is the type of the object.
No, the type of the source doesn't matter.
C++ standard doesn't specify such thing as object without declared type or how it would behave. I interpret that to mean that the effective type is implementation defined for objects with no declared type.
Even in C, the source doesn't matter in this case. A more complete version of quote from C standard (draft, N1570) that you are concerned about, emphasis mine:
6.5/6 [...] If a value is copied into an object having no declared type using memcpy or memmove, or is copied as an array of character type, then the effective type of the modified object for that access and for subsequent accesses that do not modify the value is the effective type of the object from which the value is copied, if it has one. [...]
This rule doesn't apply, because objects in u16 do have a declared type