I'm encountering the following schematic problem:
A base class (defined as a regular type), let's call it base_a that defines a generic function
A derived type, let's call it class_a that inherits from base_a and implements that generic function
And generic class, let's call it class_b (see schematic code below)
My code saves the class base_a as a "type(base_a), pointer".
I want to send this specific type to the generic class (class_b) and "save" it as a pointer component of base_a --- because in the future I will have other classes inheriting from base_a and i will want to pass them also to class_b, or pass them to class_b instead of class_a.
In other languages its suppose to be straightforward because class_a is base_a and base_a is saved in class_b, therefore i can create a function in class_b that recieves. But in Fortran I can't seem to pass class_a as a pointer, I may be confused because all of the 'type' and 'class' and 'pointer' definitions. It does work if I remove the pointer from Set_class function (below).
Can i even achieve this behavior in Modern Fortran? Is it even something i want? maybe i don't need pointers...
I will note, that i want to avoid making class_b familiar with class_a as much as possible (because once i keep adding types like class_a it will be pain to include them in class_b)
type, public :: base_a
contains
procedure, public :: Write1
...
type, public, extends(base_a) :: class_a
contains
procedure, public :: Write1 => Write_a
...
type, public :: class_b
type(base_a), pointer :: really_class_a
contains
procedure, public :: Set_class
...
subroutine Set_class(this, some_class)
type(class_b), intent(inout) :: this
type(base_a) , pointer(inout) :: some_class
this%really_class_a => some_class
end subroutine Set_class
... somewhere in main
type(class_a), pointer :: class_a
type(class_b), pointer :: class_b
...
call this%class_b%Set_class(class_a)
Using intel oneAPI
I tried setting the following code but it didn't compile, it fails when i try and class the function Set_class, if i change the argument to be without a pointer it works.,
I managed to find the problem.
In the function Set_class, the recieving object should not be defined as pointer, but as a target. In addition, really_class_a should be defined as class() and not type(). After these changes it work!
Related
To my surprise this block
type Object *struct{
X int
}
compiles in golang. However, I don't know how to create an instance of the underlying struct.
Functionally, what I wanted to achieve is to remove all the stars from all type signatures without hacks (redefining the type and other tricks). This would make the type/structs very much like Java classes.
The question is - is this construction supported in golang? Or should I stick to putting stars everywhere?
If you don't want to pass pointers around everywhere, you don't have to. You could just pass your structs around by value.
E.g.
Define your struct as:
type Object struct{
X int
}
And then define your functions as:
func DoStuffToObject(obj Object) {
// Do things with obj here
}
There's nothing wrong with passing around objects by value if that's what you wish to do.
I know it's possible to defer the definition of procedures from an abstract type to its derived types. Is it possible to include 'deferred' data in an abstract type, i.e., data whose type and value is only defined in derived classes?
The closest question I found on stackoverflow was here. It does not address my needs.
If clarification is needed, please ask. Many thanks.
There's no straightforward way to defer the definition of a data component of an (abstract) derived type as there is for procedure components, so no declaration such as
type(magic), deferred :: element
which can be overridden by a concrete declaration in an extended type. I think the easy (?) workaround would be to use class in the declaration. For ultimate flexibility you could use an unlimited polymorphic component, eg
type :: stype
class(*), allocatable :: element
end type style
What you can't then do is specify the type in a concrete extended type with a (re-)declaration something like
type, extends(stype) :: mstype
integer :: element
end type mstype
Instead, if you want to define an extended type which has an integer element you would create the type and write a constructor for it that ensures its element is allocated with type integer.
If your requirements are more modest the 2003 feature of parameterised derived types might satisfy you, but as far as I know only the Cray and IBM XL compilers implement that yet.
In the following piece of code, an abstract type with a private variables (name) and an access function to this variable, which is supposed to be defined by all derived types, is defined in a module:
module baseTypeModule
type, abstract :: baseType
private
character(len=maxLengthCompLabel) :: Name = "" ! Component name
contains
procedure, non_overridable :: getName ! Access functio to Name (read only)
end type baseType
contains
character(len=100) function getName(this)
implicit none
class(baseType), intent(in) :: this
getName = this % Name
end function getName
end module baseTypeModule
As there are many other variables and functions in each derived type, I would like to define each derived types in a different module.
Is there a way in Fortran to tell the compiler that I want that only derived types of baseType would be able to change the variable Name?
No. Accessibility of component names uses the same "by module" model as for other module entities. If the other derived types are in different modules, then they cannot access the Name component.
Bear in mind that derived types don't actually contain procedures - they contain bindings for procedures. Consequently a derived type can't really "do" anything. Also a single procedure could be bound to multiple types.
In fortran 2003, is it possible to define a derived type which has a component of an abstract type? For example, as below, I want to define a type Sup having a component o_Abst of Abst type.
TYPE, ABSTRACT :: Abst
CONTAINS
PROCEDURE(some_proc), deferred, pass :: some_proc
..
END TYPE Abst
TYPE :: Sup
PRIVATE
CLASS(Abst) :: o_Abst
..
CONTAINS
PROCEDURE :: another_proc
END TYPE Sup
One problem I have already encountered is in writing a constructor for a Sup type object. I can not assign a value to the component o_Abst by intrinsic assignment with = (Intel compiler says, "In an intrinsic assignment statement, variable shall not be polymorphic."). Or can't I write a constructor for a Abst type object because a deferred type-bound procedure can not be properly overridden if an argument other than the passed object dummy argument is of abstract type, as far as I understand.
I would also be happy to hear about a work around that avoids the use of a type like Sup. If it is tempting to define a type with a component of an abstract type, what are alternative strategies in general?
A derived type may have an polymorphic component with abstract declared type. The component must have either the pointer attribute or the allocatable attribute.
Intrinsic assignment to a polymorphic object was not permitted in F2003 (it is permitted in F2008 if the object being assigned to has the allocatable attribute, but ifort 12.1 does not support that). In F2003 an ALLOCATE statement with a SOURCE specifier can be used to achieve more or less the same result.
You can construct objects that have a type that is a non-abstract extension of Abst (it does not make sense for the dynamic type of an object to be abstract, hence no structure constructor exists for Abst itself). There is no restriction on procedures that are bound to a type taking one or more arguments of abstract type.
class A
constructor: ->
method: ->
In the above example, method is not bound to the class and neither is constructor.
class B
constructor: ->
method: =>
In this case, method is bound to the class. It behaves as you expect a normal object method to behave and has access to all of class B's fields. But the constructor is not bound? That seems strange. So i tried the following.
class C
constructor: =>
method: =>
This doesn't compile. I would expect the syntax to be the same on all methods that are bound to a class.
I would like to regard the -> operator as a static operator and the => operator as a dynamic operator. But it doesn't seem like you can. If you could, a method with the -> operator could not be called with super. But, in actuality, you can. Why does this make sense for the syntax of an object oriented language? This seems to not agree with most object oriented languages inheritance rules.
Try looking at how the code compiles. When you use =>, the methods are bound inside the constructor. Thus, it doesn't make any sense to use => for a constructor - when would it be bound?
I'm not sure about your issue with static vs. dynamic operators, but you can definitely call methods defined with the -> operator with super. The only thing -> vs => affects is that the => ensures that this is the object in question regardless of how it is called.
Summary of comments:
Calling the difference between -> and => analogous to static vs. dynamic (or virtual) does not quite convey what those operators do. They are used to get different behavior from javascript's this variable. For example, look at the following code:
class C
constructor: ->
method1: ->
console.log this
method2: =>
console.log this
c = new C()
c.method1() //prints c
f = c.method1;f() //prints window
c.method2() //prints c
f = c.method2;f() //prints c
The difference is in the second way we call each method: if the method is not "bound" to the object, its this is set by looking at what precedes the method call (separated by a .). In the first case, this is c, but in the second f isn't being called on an object, so this is set to window. method2 doesn't have this problem because it is bound to the object.
Normally, you can think of the the constructor function automatically being bound to the object that it is constructing (thus, you can't bind it with =>). However, its worth noting that this isn't quite what's happening, because if a constructor returns an object, that will be the return value of the construction, rather than the this during the constructor.
I think you're massively confused as to the meaning of the '=>', or fat arrow.
First off though, your examples aren't actually valid coffeescript, are they? There is no -> after the class declaration. Adding one is a compiler error.
Back to the fat arrow, there's no mapping to the terms static and dynamic that I can think of, that would apply here. Instead the fat arrow is a convenient syntactic sugar for wrapping a function with a closure that contains the reference to the object you're calling the function on.
The C++ analog is to possibly to say that the fat arrow is a method for automatically creating a functor: it lets you give the function as a callback to a third party who can call it without knowing your object, but where the code invoked inside will have access to your object as the this pointer. It serves no other purpose, and has no bearing on whether a function can be overloaded, or whether it can have access to super.