I'm working with the MPI library, and while using a var type MPI_status, I tired to access the field count, but the compiler says it's not avaiable.
I found 2 different soucres - one claiming that the struct has a field named count, and the other claims that in has a field named size.
I've tried both, and both won't compile. any ideas?
Thanks.
http://www.netlib.org/utk/papers/mpi-book/node31.html
In C, status is a structure of type MPI_Status that contains three fields named MPI_SOURCE, MPI_TAG, and MPI_ERROR; the structure may contain additional fields.
use:
MPI_Get_count(MPI_Status *status, MPI_Datatype datatype, int *count)
Related
So, I have been doing the Elm track on Exercism.org and I just finished the exercise about the Maybe concept, but one thing is not clear to me yet. What is the purpose of the Just in the definition of Maybe?
type Maybe a = Nothing | Just a
For example, what's the difference between Int and Just Int and why an integer is not considered a Just Int if I don't add the Just word before?
More concretely, when I was trying to solve the RPG problem my first trying resulted in something like this:
type alias Player =
{ name : Maybe String
, level : Int
, health : Int
, mana : Maybe Int
}
revive : Player -> Maybe Player
revive player =
case player.health of
0 ->
if player.level >= 10 then
Player player.name player.level 100 100
else
Player player.name player.level 100 Nothing
_ ->
Nothing
Just to find out that my mistake was in the if statement, that should return Just Person, i.e.:
if player.level >= 10 then
Just (Player player.name player.level 100 (Just 100))
else
Just (Player player.name player.level 100 Nothing)
If you're coming from a background of dynamic typing like Python then it's easy to see it as pointless. In Python, if you have an argument and you want it to be either an integer or empty, you pass either an integer or None. And everyone just understands that None is the absence of an integer.
Even if you're coming from a poorly-done statically typed language, you may still see it as odd. In Java, every reference datatype is nullable, so String is really "eh, there may or may not be a String here" and MyCustomClass is really "eh, there may or may not really be an instance here". Everything can be null, which results in everyone constantly checking whether things are null at every turn.
There are, broadly speaking, two solutions to this problem: nullable types and optional types. In a language like Kotlin with nullable types, Int is the type of integers. Int can only contain integers. Not null, not a string, not anything else. However, if you want to allow null, you use the type Int?. The type Int? is either an integer or a null value, and you can't do anything integer-like with it (such as add it to another integer) unless you check for null first. This is the most straightforward solution to the null problem, for people coming from a language like Java. In that analogy, Int really is a subtype of Int?, so every integer is an instance of Int?. 3 is an instance of both Int and Int?, and it means both "this is an integer" and also "this is an integer which is optional but exists".
That approach works fine in languages with subtyping. If your language is built up from a typical OOP hierarchy, it's easy to say "well, T is clearly a subtype of T?" and move on. But Elm isn't built that way. There's no subtyping relationships in Elm (there's unification, which is a different thing). Elm is based on Haskell, which is built up from the Hindley-Milner model. In this model, every value has a unique type.
Whereas in Kotlin, 3 is an instance of Int, and also Int?, and also Number, and also Number?, and so on all the way up to Any? (the top type in Kotlin), there is no equivalent in Elm. There is no "top type" that everything inherits from, and there is no subtyping. So it's not meaningful to say that 3 is an instance of multiple types. In Elm, 3 is an instance of Int. End of story. That's it. If a function takes an argument of type Int, it must be an integer. And since 3 can't be an instance of some other type, we need another way to represent "an integer that may or may not be there".
type Maybe a = Nothing | Just a
Enter optional typing. 3 can't be an optional integer, since it's an Int and nothing else. But Just 3, on the other hand... Just 3 is an entirely different value and its type is Maybe Int. A Just 3 is only valid in situations where an optional integer is expected, since it's not an Int. Maybe a is what's called an optional type; it's a completely separate type which represents the type a, but optional. It serves the same purpose and T? in a language like Kotlin, but it's built up from different foundations.
Getting into which one is better would derail this post, and I don't think that's important here. I have my opinions, but others have theirs as well. Optional typing and nullable typing are two different approaches to dealing with values that may or may not exist. Elm (and Haskell-like languages) use one, and other languages might use the other. A well-rounded programmer should become comfortable with both.
Why an integer is not considered a Just Int if I don't add the Just word before?
Simply because without the constructor (Just), it's only an integer and not something else. There's no automatic type conversion, you have to be explicit about what you want. Would you also consider allow writing 100 if you meant the single-element list [100]? Soon, you would have no idea what it meant if someone wrote 100.
This is not specific to Maybe and its Just variant, this is the rule for all data types. There is no exception for Maybes, even if the language is confusing - an Int is just an Int, but not a Just Int.
Just in Elm is a tag but in this context you can think of it like a function that takes a value of type Int, and return something of the type Maybe Int.
type Maybe a = Nothing | Just a
---
Just 123 -- is a `Maybe Int`
Means Maybe is a type with an associated generic type a. Similar to C++'s T
template <class T>
class Maybe
using MaybeInt = Maybe<Int>
All Nothing and Just a are are functions (aka constructors) to make a Maybe. In Python it might look like:
def Nothing() -> Maybe:
return Maybe() # except in elm, it knows the returned Maybe came from a
# Nothing, so there's some machinery missing here
def Just(some_val) -> Maybe:
return Maybe(some_val)
So if a function returns a Maybe, the returned value has to be passed through one of the two Nothing or Just constructors.
The task I'm working on is to add support for the create_function interface to Crystal's SQLite binding: https://github.com/crystal-lang/crystal-sqlite3/issues/61
To access the parameters for a user-defined function, I need to access a C-style array (that is, a pointer to contiguous instances) of the sqlite3_value type, which if I'm not mistaken requires knowing the size of the type. But as far as I have found, there is no way to declare a Crystal type as an alias for a type defined in the C library.
Because it's a pointer, no, you don't necessarily need to know its layout. For opaque pointers this pattern is common in Crystal:
type Sqlite3Context = Void*
type Sqlite3Value = Void*
fun sqlite3_create_function(
[...]
xFunc : (Sqlite3Context, Int, Sqlite3Value*) ->,
[...]
)
I need to store some data of table type like a QTableWidget but without a GUI. Something along the line of the following code:
QMap<QString, QString, int, QString, int>
Is there a way of achieve this in Qt? My Qt version is 5.3.
You seem to be unclear on a few concepts.
A map (also known in some languages as a dictionary) is an associative array. It associates a key to a value, that's about it, there are no "fields" involved whatsoever, just a key and a value.
There is no data type in Qt to model a database table. For such tasks you usually directly use SQL, Qt supports SQL with various different database drivers.
If you don't want to use a database but instead want to have "native" C++ types, you can simply create an object with all the desired fields:
struct Entry {
QString s1, s2, s3;
int i1, i2;
};
And then put that into whatever container you want.
QList<Entry> entryList;
QVector<Entry> entryVec;
QSet<Entry> entrySet;
You can wrap the container in a QAbstractListModel, implement the key functions and roles and have that model be used for a table widget or a QML view.
NOTE: I am not asking about difference between pointer and reference, and for this question it is completely irrelevant.
One thing I couldn't find explicitly stated -- what model does Nim use?
Like C++ -- where you have values and with new you create pointers to data (in such case the variable could hold pointer to a pointer to a pointer to... to data)?
Or like C# -- where you have POD types as values, but user defined objects with referenced (implicitly)?
I spotted only dereferencing is automatic, like in Go.
Rephrase. You define your new type, let's say Student (with name, university, address). You write:
var student ...?
to make student hold actual data (of Student type/class)
to make student hold a pointer to the data
to make student hold a pointer to a pointer to the data
Or some from those points are impossible?
By default the model is of passing data by value. When you create a var of a specific type, the compiler will allocate on the stack the required space for the variable. Which is expected, as Nim compiles to C, and complex types are just structures. But like in C or C++, you can have pointers too. There is the ptr keyword to get an unsafe pointer, mostly for interfacing to C code, and there is a ref to get a garbage collected safe reference (both documented in the References and pointer types section of the Nim manual).
However, note that even when you specify a proc to pass a variable by value, the compiler is free to decide to pass it internally by reference if it considers it can speed execution and is safe at the same time. In practice the only time I've used references is when I was exporting Nim types to C and had to make sure both C and Nim pointed to the same memory. Remember that you can always check the generated C code in the nimcache directory. You will see then that a var parameter in a proc is just a pointer to its C structure.
Here is an example of a type with constructors to be created on the stack and passed in by value, and the corresponding pointer like version:
type
Person = object
age: int
name: string
proc initPerson(age: int, name: string): Person =
result.age = age
result.name = name
proc newPerson(age: int, name: string): ref Person =
new(result)
result.age = age
result.name = name
when isMainModule:
var
a = initPerson(3, "foo")
b = newPerson(4, "bar")
echo a.name & " " & $a.age
echo b.name & " " & $b.age
As you can see the code is essentially the same, but there are some differences:
The typical way to differentiate initialisation is to use init for value types, and new for reference types. Also, note that Nim's own standard library mistakes this convention, since some of the code predates it (eg. newStringOfCap does not return a reference to a string type).
Depending on what your constructors actually do, the ref version allows you to return a nil value, which you can treat as an error, while the value constructor forces you to raise an exception or change the constructor to use the var form mentioned below so you can return a bool indicating success. Failure tends to be treated in different ways.
In C-like languages theres is an explicit syntax to access either the memory value of a pointer or the memory value pointed by it (dereferencing). In Nim there is as well, and it is the empty subscript notation ([]). However, the compiler will attempt to automatically put those to avoid cluttering the code. Hence, the example doesn't use them. To prove this you can change the code to read:
echo b[].name & " " & $b[].age
Which will work and compile as expected. But the following change will yield a compiler error because you can't dereference a non reference type:
echo a[].name & " " & $a[].age
The current trend in the Nim community is to get rid of single letter prefixes to differentiate value vs reference types. In the old convention you would have a TPerson and an alias for the reference value as PPerson = ref TPerson. You can find a lot of code still using this convention.
Depending on what exactly your object and constructor need to do, instead of having a initPerson returning the value you could also have a init(x: var Person, ...). But the use of the implicit result variable allows the compiler to optimise this, so it is much more a taste preference or requirements of passing a bool to the caller.
It can be either.
type Student = object ...
is roughly equivalent to
typedef struct { ... } Student;
in C, while
type Student = ref object ...
or
type Student = ptr object ...
is roughly equivalent to
typedef struct { ... } *Student;
in C (with ref denoting a reference that is traced by the garbage collector, while ptr is not traced).
I want to know, How QVariant can internally stores, int, QMap, QList,...
I mean what is the internal data-structure/Implementation? What is the overhead of storing and retrieving types (int, float) in QVariant?
A quick look at the code reveals that a QVariant is basically a union of several primitive types (int, float etc'), a QObject pointer, and a void* pointer for anything else that is not a QObject and not a primitive. There is also a type data member that allows it to know what's actually currently stored there. The overhead appears to be not much more than storing to a member of a struct, checking that for type compatibility and possibly making a conversion (int to float for instance)