|
|
 Up |
|
|
  |
Author: Gerry FordGerry Ford Date: Feb 16, 2008 19:11
I'd like to continue this elsethread discussion.
I'd like to match the following c++ syntax to fortran:
#include
#include
#include
#include
#include
int main() {
std::vector four_vector;
for (double i=0.0; i<4.0; i++)
four_vector.push_back(sqrt(i));
std::cout.precision(16);
std::copy(four_vector.begin(), four_vector.end(),
std::ostream_iterator(std::cout, "\n"));
return 0;
}
// g++ -o vector2 vector2.cpp
// vector2 >text55.txt 2>text56.txt
|
| Show full article (2.55Kb) |
|
| | 14 Comments |
|
|
|
|
|
Author: utabutab Date: Feb 19, 2008 04:16
> Tim Prince thought that utab's subroutine went
> out of its way tomake something hard. I saw no source posting after this
> serious criticism.
I could not get this point, could you be a bit more specific on that?
Rgds,
|
| |
| no comments |
|
|
Author: Craig PowersCraig Powers Date: Feb 19, 2008 11:23
Gerry Ford wrote:
> I'd like to continue this elsethread discussion.
>
> I'd like to match the following c++ syntax to fortran:
>
> #include
> #include
> #include
> #include
> #include
>
> int main() {
> std::vector four_vector;
>
> for (double i=0.0; i<4.0; i++)
> four_vector.push_back(sqrt(i));
>
>
> std::cout.precision(16);
> std::copy(four_vector.begin(), four_vector.end(), ...
|
| Show full article (2.62Kb) |
| no comments |
|
|
Author: Gerry FordGerry Ford Date: Feb 19, 2008 18:39
>
>> Tim Prince thought that utab's subroutine went
>> out of its way tomake something hard. I saw no source posting after
>> this
>> serious criticism.
>
> I could not get this point, could you be a bit more specific on that?
>
utab,
I never saw an update of your source that would reflect any of the forum
criticisms.
This is the latest version of my c++ program to match:
// vector3.cpp contributor: Jim Langston
#include
#include
#include
#include
|
| Show full article (6.02Kb) |
| no comments |
|
|
Author: FXFX Date: Feb 20, 2008 02:31
> From here forward, I'm not clear on what you want. Once we got utab's
> code into agreement, the only point of complication that arose was when
> I/O was introduced into the fortran side; when that happens, if you
> don't like the program with gfortran, you have to make sure you link
> against the appropriate libraries (i.e. libgfortran and libgfortranbegin).
I'm also unclear what is the goal here. I think I have already (and Craig
as well) explained in detail what needs to be done to compile and link
mixed-code programs. For example, mixed C and Fortran (with C main) is:
$ cat a.f90
real(8) function prod (x, y, n)
real(8), intent(in) :: x(n), y(n)
integer, intent(in) :: n
prod = dot_product (x,y)
end function prod
$ cat b.c
#include
#include
|
| Show full article (2.61Kb) |
| no comments |
|
|
Author: Gerry FordGerry Ford Date: Feb 21, 2008 16:00
"FX" alussinan.org> wrote in message
news:fpgvio$135i$1@nef.ens.fr...
>
> PS: these code examples don't use ISO_C_BINDING but the old-school
> mixed-language programming style, which is not as portable and requires
> knowledge of your Fortran compiler calling conventions.
>
Thanks, FX, for your generous post.
Of the many variations that present themselves for mixed code with this
example, I chose to have main in fortran, and simply call the c++ function
we've written for dot product.
The fortran is:
program vector3
implicit none
real(kind=8), external :: dot_product_from_cplusplus
integer index, i
integer, parameter :: some_kind_number = selected_real_kind (p=16)
real (kind = some_kind_number), dimension(4):: vec_a, vec_b
real (kind = some_kind_number) :: res
|
| Show full article (2.95Kb) |
| no comments |
|
|
Author: FXFX Date: Feb 22, 2008 00:29
> gfortran2 -o vector3 b.o vector3.f95
>
> Grateful for any tips.
Please read posts twice before asking again. I quote myself:
>> (b) use the second kind of linking command, ie with "g++ [...]
>> [-lgfortranbegin] -lgfortran -lm" instead of "gfortran [...]"
So, that's:
g++ -c b.cpp
gfortran -c vector3.f95
g++ -o vector b.o vector3.o -lgfortranbegin -lgfortran -lm
However, that won't work and will give:
/ usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: Undefined symbols:
_dot_product_from_cplusplus_
I don't know C++ (never written a single line of it) but it seems that
the name of your dot_product_from_cplusplus is mangled into something
awful (__Z26dot_product_from_cplusplusRKSt6vectorIdSaIdEES3_), to encode
its type and the type of its arguments. So, you need to find a C++ expert
to ask him how to do that.
Final point, I'm not sure your prototype:
|
| Show full article (1.23Kb) |
| no comments |
|
|
Author: Jan VorbrüggenJan Vorbrüggen Date: Feb 22, 2008 00:34
> I don't know C++ (never written a single line of it) but it seems that
> the name of your dot_product_from_cplusplus is mangled into something
> awful (__Z26dot_product_from_cplusplusRKSt6vectorIdSaIdEES3_), to encode
> its type and the type of its arguments.
The C++ code needs to be wrapped in an "extern C" scope to turn off name
mangling.
Jan
|
| |
| no comments |
|
|
|
|
|
Author: Craig PowersCraig Powers Date: Feb 22, 2008 08:32
Gerry Ford wrote:
>
> double dot_product_from_cplusplus (const std::vector& vec_a, const
> std::vector& vec_b)
As I told utab, you are highly unlikely to be able to interface between
a Fortran array and a C++ std::vector.
The correct signature for this function if you want to be able to call
it from Fortran is:
extern "C" double dot_product_from_cplusplus(double const * a,
double const * b)
The 'extern "C"' is necessary to disable C++ name mangling, which is
used to make symbols that distinguish by arguments for overloading
purposes (Fortran accomplishes the same thing by using a generic
interface to tie external symbols with different names together).
|
| |
| no comments |
|
|
|
|
