- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If only
Type extension (not polymorphic)
Procedure pointers
ABSTRACT INTERFACE
PASS and NOPASS attributes
had been implemented, the oop code will still not be program.
Will it has other oop capacities in this release? (because it seems that gfortran now has much more oop capacities than ivf and I always think that ivf is better.)
Type extension (not polymorphic)
Procedure pointers
ABSTRACT INTERFACE
PASS and NOPASS attributes
had been implemented, the oop code will still not be program.
Will it has other oop capacities in this release? (because it seems that gfortran now has much more oop capacities than ivf and I always think that ivf is better.)
Link Copied
5 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We're working on the remaining features, but what you see in the release notes now is what will be there in 11.0. gfortran has some features we don't, we have some it doesn't.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks.
The oop capacity may be the most charming features for the Fortran complier users rather than others. It is why more Fortran users switch to c++ which has a oop capacity but a low speed.
I love Fortran and interest in oop.
The oop capacity may be the most charming features for the Fortran complier users rather than others. It is why more Fortran users switch to c++ which has a oop capacity but a low speed.
I love Fortran and interest in oop.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We have not seen that big an interest in the OOP features until very recently. Indeed, many customers told us they had no interest in OOP at all. Even today, we have more people asking us for F2008 draft features such as coarrays and submodules than OOP. OOP should be the next big chunk of F2003 you'll see from us after 11.0.
Please understand that the more decisions you defer to run-time, the slower your code will get as the compiler has less information it can use to optimize. Run-time type selection is going to slow you down a lot. As Robert Heinlein once famously wrote, There Ain't No Such Thing As A Free Lunch.
Please understand that the more decisions you defer to run-time, the slower your code will get as the compiler has less information it can use to optimize. Run-time type selection is going to slow you down a lot. As Robert Heinlein once famously wrote, There Ain't No Such Thing As A Free Lunch.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve,
I haven't read the F2008 or F2003 draft for that matter so this question may be answered in those specification. I hope I can convey my question clearly
A module can have a CONTAINS section at the bottom where subroutines and functions can be declared and which appear to run in the scope of the module.
Is there any thought to having a CONTAINS section at the bottom of a SUBROUTINE or FUNCTION such that they run within the scope of the subroutine or function?
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
That already is supported, but a procedure can have only one level of CONTAINed routines under it. That's a F90 feature.

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page