I am new to VB. I am reading some VB6 code and I come across declaration statements like
PQR_SSN(8) As Byte // this probably refers to social security number
TR_DATA(7) As TransactionDetail
In another file, TransactionDetial is defined
Public Type TransactionDetail
A(0) As Byte
B(0) As Byte
Comment(40) As Byte
//... etc
//...
End Type
Does TR_DATA(7) mean that it is an "array" that can store 8 instances of TransactionDetail?
Also, Consider Comment(40). Can I access individual bytes of the comment like this -
Comment(3)
Also, suppose that I do not assign all 41 bytes to Comment. Then will the rest of the bytes contain garbage values?
Please help. Thanks.
Yes, TR_DATA(7) is an array of 8 elements of type TransactionDetail.
Yes, the Comments array can be accessed through individual elements as you show.
Unassigned elements may contain garbage values - I wouldn't trust them - but I can't recall whether VB helpfully pre-initialises variables. I would expect it would, just to be helpful to users, and that it would initialise numeric variables to 0, fixed-length strings to all zeros, and objects to Empty.
Found this web link which gives some useful guidance on arrays in VB6.
Also just found this: VB6 Variable Scope; which says:
Unlike many other languages, VB does not allow you to initialize
variables; this must be done with an executable statement. However,
each variable does have a default initialization value. Numeric
variable types are initialized to zero, Strings are initialized to "",
Booleans are initialized to False, etc.
#Nick: yes, VB helpfully does exactly as you surmise.
#CodeBlue: your last question suggests that you may want to investigate dynamic arrays. If so, I would suggest that you investigate in particular the Redim and Preserve statements.
Related
What I am reading about ints and strings over internet is they are immutable in the nature.
But the following code shows that after changing the values of these types, still they points to the same address. This contradicts the idea behind the nature of types in python.
Can anyone please explain me this?
Thanks in advance.
package main
import (
"fmt"
)
func main() {
num := 2
fmt.Println(&num)
num = 3
fmt.Println(&num) // address value of the num does not change
str := "2"
fmt.Println(&str)
str = "34"
fmt.Println(&str) // address value of the str does not change
}```
A number is immutable by nature. 7 is 7, and it won't be 8 tomorrow. That doesn't mean that which number is stored in a variable cannot change. Variables are variable. They're mutable containers for values which may be mutable or immutable.
A Go string is immutable by language design; the string type doesn't support any mutating operators (like appending or replacing a character in the middle of the string). But, again, assignment can change which string a variable contains.
In Python (CPython at least), a number is implemented as a kind of object, with an address and fields like any other object. When you do tricks with id(), you're looking at the address of the object "behind" the variable, which may or may not change depending on what you do to it, and whether or not it was originally an interned small integer or something like that.
In Go, an integer is an integer. It's stored as an integer. The address of the variable is the address of the variable. The address of the variable might change if the garbage collector decides to move it (making the numeric value of the address more or less useless), but it doesn't reveal to you any tricks about the implementation of arithmetic operators, because there aren't any.
Strings are more complicated than integers; they are kind of object-ish internally, being a structure containing a pointer and a size. But taking the address of a string variable with &str doesn't tell you anything about that internal structure, and it doesn't tell you whether the Go compiler decided to use a de novo string value for an assignment, or to modify the old one in place (which it could, without breaking any rules, if it could prove that the old one would never be seen again by anything else). All it tells you is the address of str. If you wanted to find out whether that internal pointer changed you would have to use reflection... but there's hardly ever any practical reason to do so.
When you read about a string being immutable, it means you cannot modify it by index, ex:
x := "hello"
x[2] = 'r'
//will raise an error
As a comment says, when you modify the whole var(and not a part of it with an index), it's not related to being mutable or not, and you can do it
Static i as integer
What will i be before I assign a value.
It seems to be just zero (0) but I wanted to confirm that.
Variables of all VB data types receive their respective default value when the procedure starts.
This includes initializing all numbers to zero, and all the other data types to their flavour of zero (vbNullString for strings, not exactly the same as an empty string "", False for booleans, Empty for variants, and Nothing for objects).
According to Microsoft
Normally in Visual Basic, when a static variable is declared inside a Function or Sub procedure, it gets initialized to 0 (numeric data type) or an empty string, "" (string data type), by default.
So yeah, you can be sure it's default value is zero.
Hope this helps
I have this parameter as an array. The array is big, 100 cells. It is a parameter that can be initiated in omnet.ini file. The cells with even numbers should get value A and odd numbers should get value B. How can I do this in an automated manner?
Is there a way besides having all odd and even indices initiated one by one manually?
Wildcards can be useful but I do not know how to use them to separate odd and even indices.
Thanks.
You can access the actual module index with the index operator. Combining this with the conditional operator ?: you can easily define the value:
**.myModule[*].myParameter = index % 2 == 0 ? "A" : "B"
I'm not aware of any feature like this. There are a number of work-arounds you could use:
Provide two parameters and select the correct one in code
Use the volatile keyword (probably not appropriate here)
Put the entire thing in your .ini file
I'd personally implement the first approach, that way you can use the wildcard to pass both parameters ([*].myNode.parameterEven and [*].myNode.parameterUneven) and then set the correct values in your array in a for loop.
However, you could also use the volatile keyword in your NED file, see the manual for more details. However, this approach mostly works well if you have different parameters depending on which node you are assigning it to. For this case I think the first approach is better.
The last alternative is just putting the entire thing in your .ini file, which may be useful if you want to parameterize the array later.
Is it possible in Visual Foxpro to have 2 variables that point to the same address in memory. Such that if the value of one of the variables is changed then the other is also changed. I understand that when passing arguments to functions they can be passed by value or reference but I want to know if this is possible in straight code. I think in other languages such as C this is called a pointer but I don't believe VFP has pointers. So if one writes the following code it will output the number 4.
a=4
b=a
a=6
? b && answer 4
But could one write code such as the following where the answer could be 6?
a=4
b=*a && note the inclusion of the asterisk (pointer?) here which won't compile in VFP
a=6
? b
No. There are no pointers or references in Foxpro; as you note, the closest thing to it is passing parameters by reference to functions. You might be able to try to kludge something together (as Jerry mentions) with objects using Access/Assign methods, but even then, all that gets passed to the Assign method is the value being assigned - nothing about whether it was originally another variable, a literal value, an object's property, etc.
You could simulate it by using an array or a table. The variables would contain only the array index or record number (or other index) as a reference, and you'd have to get the actual value from the array or table.
Take a look at the Visual Foxpro Access and Assign Methods. These methods can be used to execute code when querying a property or trying to change the value of a property. Below is a link that shows an example:
Access and Assign Example
You could do something like this:
a=4
b='a'
a=6
?&b
Given code for an incomplete server like:
enum class Command : uint32_t {
LOGIN,
MESSAGE,
JOIN_CHANNEL,
PART_CHANNEL,
INVALID
};
Can I expect that converting Command::LOGIN to an integer will always give the same value?
Across compilers?
Across compiler versions?
If I add another enumeration?
If I remove an enumeration?
Converting Command::LOGIN would look something like this:
uint32_t number = static_cast<uint32_t>(Command::LOGIN);
Some extra information on what I am doing here. This enumeration is fed onto the wire by converting it to an integer sending it along to the server/client. I do not really particularly care what the number is, as long as it will always stay the same. If it will not stay the same, then obviously I will have to provide my own numbers through the usual way.
Now my sneaking suspicion is that it will change depending on what compiler was used to compile the code, but I would like to know for sure.
Bonus question: How does the compiler/language determine what number to use for Command::LOGIN?
Before submitting this question, I have noticed some changes from say 3137527848 to 0 and back, so it is obviously not valid to rely on it not changing. I am still curious about how this number is determined, and how or why that number is changing.
From the C++11 Standard (or rather, n3485):
[dcl.enum]/2
If the first enumerator has no initializer, the value of the corresponding constant is zero. An enumerator-definition without an initializer gives the enumerator the value obtained by increasing the value of the previous enumerator by one.
Additionally, [expr.static.cast]/9
A value of a scoped enumeration type can be explicitly converted to an integral type. The value is unchanged if the original value can be represented by the specified type.
I think it's obvious that the values of the enumerators can be represented by uint32_t; if they weren't, [dcl.enum]/5 says "if the initializing value of an enumerator cannot be represented by the underlying type, the program is ill-formed."
So as long as you use the underlying type for conversion (either explicitly or via std::underlying_type<Command>::type), the value of those enumerators are fixed as long as you don't add any enumerators before them (in the same enumeration) or alter their order.
As Nicolas Louis Guillemo pointed out, be aware of possible different endianness when transferring the value.
If you assign explicit integer values to your enum constants then you are guaranteed to always have the same value when converting to the integer type.
Just do something like the following:
enum class Command : uint32_t {
LOGIN = 12,
MESSAGE = 46,
JOIN_CHANNEL = 5,
PART_CHANNEL = 0,
INVALID = 42
};
If you don't specify any values explicitly, the values are set implicitly, starting from zero and increasing by one with each move down the list.
Quoting from draft n3485:
[dcl.enum] paragraph 2
The enumeration type declared with an enum-key of only enum is an
unscoped enumeration, and its enumerators are unscoped enumerators.
The enum-keys enum class and enum struct are semantically equivalent;
an enumeration type declared with one of these is a scoped
enumeration, and its enumerators are scoped enumerators. [...] The
identifiers in an enumerator-list are declared as constants, and can
appear wherever constants are required. An enumerator-definition with
= gives the associated enumerator the value indicated by the constant-expression. If the first enumerator has no initializer, the
value of the corresponding constant is zero. An
enumerator-definition without an initializer gives the enumerator the
value obtained by increasing the value of the previous enumerator by
one.
The drawback of relying on this, is that if the list order somehow changes in the future, then your code might silently break, so I would advise you be explicit.
Command::LOGIN will always be 0 as long as it's the first enum in the list. Just be careful with the rest of the enums, because they will have different binary representations based on if the computer is using big endian or little endian.