Home > Archive > Fortran > February 2008 > using dot_product from c++
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
using dot_product from c++
|
|
|
| Dear all,
I tried to write a very simple subroutine where two vector are dot
producted.
Compiles and links fine but, then which a bad_alloc exception in from c
++ side.
Could someone comment on this?
gfortran -c vecpro.f90
g++ -c vecprod.cc
g++ -o test vecpro.o vecprod.o -lg2c
nm vecpro.o
results in
vectorproduct_
and execution results in
../test
terminate called after throwing an instance of 'std::bad_alloc'
what(): St9bad_alloc
Aborted
Codes:
subroutine vectorProduct(res,vec1,vec2,n)
implicit none
integer ::n ! dimension of the
vector
real, dimension(:) ::vec1,vec2 ! dimension of the vectors are
real res ! result of the
operation
res=dot_product(vec1,vec2) ! dot_product is used to compute the
! result
end subroutine vectorProduct
#include <iostream>
#include <vector>
#include <string>
using namespace std;
extern "C" {
void vectorproduct_(double &,std::vector<double> &,
std::vector<double> &, int &);
}
int main(){
int sz;
vector<double> a(5),b(5);
sz=a.size();
int i=1,j=4;
double result;
for(;i!=sz+1;++i){
a.push_back(i);
++i;
}
for(;j!=sz+1;++j){
b.push_back(j);
++j;
}
vectorproduct_(result,a,b,sz);
std::cout << result << std::endl;
return 0;
}
I know that vectors are aligned in memort continuously, but could not
figure the problem out, I guess it is sth related to the memory since
I am getting an error related to bad_alloc.
Best regards,
| |
|
| On Feb 12, 6:04 pm, utab <umut.ta...@gmail.com> wrote:
> Dear all,
>
> I tried to write a very simple subroutine where two vector are dot
> producted.
>
> Compiles and links fine but, then which a bad_alloc exception in from c
> ++ side.
>
> Could someone comment on this?
>
> gfortran -c vecpro.f90
> g++ -c vecprod.cc
> g++ -o test vecpro.o vecprod.o -lg2c
>
> nm vecpro.o
>
> results in
>
> vectorproduct_
>
> and execution results in
>
> ./test
>
> terminate called after throwing an instance of 'std::bad_alloc'
> what(): St9bad_alloc
> Aborted
>
> Codes:
>
> subroutine vectorProduct(res,vec1,vec2,n)
> implicit none
> integer ::n ! dimension of the
> vector
> real, dimension(:) ::vec1,vec2 ! dimension of the vectors are
> real res ! result of the
> operation
> res=dot_product(vec1,vec2) ! dot_product is used to compute the
> ! result
> end subroutine vectorProduct
> #include <iostream>
> #include <vector>
> #include <string>
>
> using namespace std;
>
> extern "C" {
> void vectorproduct_(double &,std::vector<double> &,
> std::vector<double> &, int &);
>
> }
>
> int main(){
>
> int sz;
> vector<double> a(5),b(5);
>
> sz=a.size();
> int i=1,j=4;
> double result;
>
> for(;i!=sz+1;++i){
> a.push_back(i);
> ++i;
> }
> for(;j!=sz+1;++j){
> b.push_back(j);
> ++j;
> }
> vectorproduct_(result,a,b,sz);
>
> std::cout << result << std::endl;
> return 0;
>
> }
>
> I know that vectors are aligned in memort continuously, but could not
> figure the problem out, I guess it is sth related to the memory since
> I am getting an error related to bad_alloc.
>
> Best regards,
Sorry that I did not check this thoroughly, I had some problems in the
index of the vectors in C++ codes, time to sleep I guess :-),
| |
| Steven G. Kargl 2008-02-12, 7:22 pm |
| In article <0f36f2f7-e037-45c6-a6ac-d1b485a497b7@1g2000hsl.googlegroups.com>,
utab <umut.tabak@gmail.com> writes:
>
> Could someone comment on this?
>
> gfortran -c vecpro.f90
> g++ -c vecprod.cc
> g++ -o test vecpro.o vecprod.o -lg2c
>
Why are you adding -lg2c to the command line?
--
Steve
| |
|
| On Feb 12, 6:23 pm, ka...@troutmask.apl.washington.edu (Steven G.
Kargl) wrote:
> In article <0f36f2f7-e037-45c6-a6ac-d1b485a49...@1g2000hsl.googlegroups.com>,
> utab <umut.ta...@gmail.com> writes:
>
>
>
>
>
> Why are you adding -lg2c to the command line?
>
> --
> Steve
to link the fortran runtime library libg2c.
| |
| Steven G. Kargl 2008-02-12, 7:22 pm |
| In article <dc9601ce-ea27-4aec-97d4-1005290e68c5@e25g2000prg.googlegroups.com>,
utab <umut.tabak@gmail.com> writes:
> On Feb 12, 6:23 pm, ka...@troutmask.apl.washington.edu (Steven G.
> Kargl) wrote:
>
> to link the fortran runtime library libg2c.
>
Again, why?
libg2c is *not* the runtime library for gfortran
(unless someone renamed gfortran's runtime library)!
--
Steve
| |
|
| On Feb 12, 6:44 pm, ka...@troutmask.apl.washington.edu (Steven G.
Kargl) wrote:
> In article <dc9601ce-ea27-4aec-97d4-1005290e6...@e25g2000prg.googlegroups.com>,
> utab <umut.ta...@gmail.com> writes:
>
>
>
>
>
>
>
>
> Again, why?
>
> libg2c is *not* the runtime library for gfortran
> (unless someone renamed gfortran's runtime library)!
>
> --
> Steve
Yes this showed that my knowledge is shallow, and I did not provide
enough information. I was using F77 with C++ before so this was my 1st
try with F90 and I used the same style without knowing about the run
time libraries of F90. This is the main reason to use that.
Thanks,
I am trying to link the F90 code above with the C++ one, where I
wanted to product two vectors using F90.
| |
| Ken.Fairfield@gmail.com 2008-02-12, 7:22 pm |
| On Feb 12, 9:04 am, utab <umut.ta...@gmail.com> wrote:
[...]
> Codes:
>
> subroutine vectorProduct(res,vec1,vec2,n)
> implicit none
> integer ::n ! dimension of the
> vector
> real, dimension(:) ::vec1,vec2 ! dimension of the vectors are
Here, in the declaration of vec1 & vec2, you're using F90-style
assumed *shape* to declare the arrays (vectors). Your c++
code doesn't pass, and doesn't know how to pass, the
information required by F90 to make this work, so it doesn't.
Since you're passing the dimension of the vectors anyway,
use it in the declaration, as you would have in plain F77:
real, dimension(n) :: vec1, vec2
> real res ! result of the
> operation
> res=dot_product(vec1,vec2) ! dot_product is used to compute the
> ! result
> end subroutine vectorProduct
[...]
-Ken
| |
| Craig Powers 2008-02-12, 7:22 pm |
| utab wrote:
> Dear all,
>
> I tried to write a very simple subroutine where two vector are dot
> producted.
>
> Compiles and links fine but, then which a bad_alloc exception in from c
> ++ side.
>
> Could someone comment on this?
>
> gfortran -c vecpro.f90
> g++ -c vecprod.cc
> g++ -o test vecpro.o vecprod.o -lg2c
>
> nm vecpro.o
>
> results in
>
> vectorproduct_
>
> and execution results in
>
> ./test
>
> terminate called after throwing an instance of 'std::bad_alloc'
> what(): St9bad_alloc
> Aborted
>
> Codes:
>
> subroutine vectorProduct(res,vec1,vec2,n)
> implicit none
> integer ::n ! dimension of the
> vector
> real, dimension(:) ::vec1,vec2 ! dimension of the vectors are
Assumed shape arrays are incompatible with mixed language use unless you
code explicitly for the descriptor on the other side, which will be
highly nonportable (even from one version of a compiler to another, let
alone from one compiler to another).
The correct declaration would be:
REAL, DIMENSION(n) :: vec1, vec2
(as it is, you're not using n at all.)
> real res ! result of the
> operation
> res=dot_product(vec1,vec2) ! dot_product is used to compute the
> ! result
> end subroutine vectorProduct
> #include <iostream>
> #include <vector>
> #include <string>
>
> using namespace std;
>
> extern "C" {
> void vectorproduct_(double &,std::vector<double> &,
> std::vector<double> &, int &);
> }
A Fortran array is *highly* unlikely to be compatible with a C++
std::vector. Furthermore, Fortran parameters are much more likely to be
compatible with C/C++ pointers than with C references. The correct
prototype would be:
extern "C" void vectorproduct_(double*, double*, double*, int*);
> int main(){
>
> int sz;
> vector<double> a(5),b(5);
>
> sz=a.size();
> int i=1,j=4;
> double result;
>
> for(;i!=sz+1;++i){
> a.push_back(i);
> ++i;
> }
> for(;j!=sz+1;++j){
> b.push_back(j);
> ++j;
> }
This code is not doing what I believe you think it's doing. At the end
of it, a and b are both length 10, containing;
0 0 0 0 0 1 2 3 4 5
while the value of sz is still 5.
You should either not initialize the vectors (leaving them in the
default size of 0) or you should not use push_back but instead reference
the location you wish to access directly. (Or, in the third
alternative, there may be a standard algorithm that will allow you to
perform the initialization on declaration, but a) it will ultimately
just reduce to the loop structure, and b) it will be much more opaque to
the unfamiliar reader.)
Don't set sz until you're done modifying the size of a and b.
> vectorproduct_(result,a,b,sz);
Then, the correct call is:
vectorproduct_(&result, &a[0], &b[0], &sz);
> std::cout << result << std::endl;
> return 0;
> }
>
> I know that vectors are aligned in memort continuously, but could not
> figure the problem out, I guess it is sth related to the memory since
> I am getting an error related to bad_alloc.
The bad_alloc is a little surprising, I would have expected a simple
segfault. I guess maybe it arises because the misunderstandings between
the codes multiply to put the memory manager out of whack.
| |
| James Giles 2008-02-12, 7:22 pm |
| Ken.Fairfield@gmail.com wrote:
.....
> Since you're passing the dimension of the vectors anyway,
> use it in the declaration, as you would have in plain F77:
>
> real, dimension(n) :: vec1, vec2
Except that F77 doesn't support the form that involves the
DIMENSION keyword. This form is often much less legible
and I believe that the DIMENSION keyword should be removed
from the language entirely.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| Ken.Fairfield@gmail.com 2008-02-12, 7:22 pm |
| On Feb 12, 10:51 am, "James Giles" <jamesgi...@worldnet.att.net>
wrote:
> Ken.Fairfi...@gmail.com wrote:
>
> ....
>
>
>
> Except that F77 doesn't support the form that involves the
> DIMENSION keyword. This form is often much less legible
> and I believe that the DIMENSION keyword should be removed
> from the language entirely.
Oh yes, agreed. A little brain *&^%$ there. :-} I should
either have left off the phrase about plain F77 altogether,
or written it in F77 style as,
REAL vec1(n), vec2(n)
(with or without the F90 "::").
-Ken
| |
| Gerry Ford 2008-02-12, 7:22 pm |
|
"utab" <umut.tabak@gmail.com> wrote in message
news:94f7fcfd-1992-4335-8355-0a06bdabab43@s12g2000prg.googlegroups.com...[color=darkred]
> On Feb 12, 6:04 pm, utab <umut.ta...@gmail.com> wrote:
I'm not all that clear on what and why you're doing this. Since fortran has
dot_product as in intrinsic, I would have to think you're doing this mixed
language just for the sake of doing something familiar probably as a
precursor to doing something for which you would *need* two syntaxes.
I thought that I would take this as an opportunity to study gfortran's
compiler options. In gfortran's documentation, they only look at the
command line options that are unique to gfortran, so you have to go to gcc's
documentation to find these:
-c Compile or assemble the source files, but do not link. The linking stage
simply
is not done. The ultimate output is in the form of an object file for each
source
file.
By default, the object file name for a source file is made by replacing the
suffix
'.c', '.i', '.s', etc., with '.o'.
Unrecognized input files, not requiring compilation or assembly, are
ignored.
-o file Place output in file file. This applies regardless to whatever sort
of output is
being produced, whether it be an executable file, an object file, an
assembler
file or preprocessed C code.
If '-o' is not specified, the default is to put an executable file in 'a.out',
the
object file for 'source.suffix' in 'source.o', its assembler file in
'source.s', a
precompiled header file in 'source.suffix.gch', and all preprocessed C
source
on standard output.
# end excerpt
It doesn't say anything about the usage for the object files getting
stitched together with lg2c into an executable. Am I looking in the wrong
place?
--
Gerry Ford
"The apple was really a peach."
-- Allison Dunn on the garden of eden
| |
| Tim Prince 2008-02-12, 10:26 pm |
| Gerry Ford wrote:
> "utab" <umut.tabak@gmail.com> wrote in message
> news:94f7fcfd-1992-4335-8355-0a06bdabab43@s12g2000prg.googlegroups.com...
>
> I'm not all that clear on what and why you're doing this. Since fortran has
> dot_product as in intrinsic, I would have to think you're doing this mixed
> language just for the sake of doing something familiar probably as a
> precursor to doing something for which you would *need* two syntaxes.
>
Likewise, C++ has inner_product() as a direct equivalent to Fortran
dot_product, in the case where the vectors have stride 1.
I don't think you'll get much sympathy in a Fortran group for writing C++
code with range violations, particularly when you have to go so far out of
your way to do it.
You've already been asked why you linked the g77 library when you used
gfortran.
It might be better to use the ISO C binding so as to specify your
interface explicitly. It seems contradictory to define a function as
extern "C" and then use C++ specific syntax in the interface.
| |
| James Van Buskirk 2008-02-13, 4:29 am |
| "James Giles" <jamesgiles@worldnet.att.net> wrote in message
news:yUlsj.590127$kj1.391549@bgtnsc04-news.ops.worldnet.att.net...
> Except that F77 doesn't support the form that involves the
> DIMENSION keyword. This form is often much less legible
> and I believe that the DIMENSION keyword should be removed
> from the language entirely.
Somebody's compiler couldn't hack statements like:
real :: arr(2*param1,3*param2) = reshape([(i,i=1,size(arr))],shape(arr))
so they whined to the committee and had it disallowed so that
you have to use the dimension keyword to make it work now.
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
| |
|
| On Feb 12, 7:43 pm, Craig Powers <eni...@hal-pc.org> wrote:
> utab wrote:
>
>
>
>
>
>
>
>
>
>
>
>
>
> Assumed shape arrays are incompatible with mixed language use unless you
> code explicitly for the descriptor on the other side, which will be
> highly nonportable (even from one version of a compiler to another, let
> alone from one compiler to another).
>
> The correct declaration would be:
> REAL, DIMENSION(n) :: vec1, vec2
>
> (as it is, you're not using n at all.)
>
>
>
>
> A Fortran array is *highly* unlikely to be compatible with a C++
> std::vector. Furthermore, Fortran parameters are much more likely to be
> compatible with C/C++ pointers than with C references. The correct
> prototype would be:
>
> extern "C" void vectorproduct_(double*, double*, double*, int*);
>
>
>
>
>
>
>
> This code is not doing what I believe you think it's doing. At the end
> of it, a and b are both length 10, containing;
> 0 0 0 0 0 1 2 3 4 5
>
> while the value of sz is still 5.
>
> You should either not initialize the vectors (leaving them in the
> default size of 0) or you should not use push_back but instead reference
> the location you wish to access directly. (Or, in the third
> alternative, there may be a standard algorithm that will allow you to
> perform the initialization on declaration, but a) it will ultimately
> just reduce to the loop structure, and b) it will be much more opaque to
> the unfamiliar reader.)
>
> Don't set sz until you're done modifying the size of a and b.
>
>
> Then, the correct call is:
> vectorproduct_(&result, &a[0], &b[0], &sz);
>
>
>
> The bad_alloc is a little surprising, I would have expected a simple
> segfault. I guess maybe it arises because the misunderstandings between
> the codes multiply to put the memory manager out of whack.
Thx for the detailed explanations and suggestions, I corrected my
code, yes since vector part was a mess that I missed but there is
still a problem. also used inner_product from the numeric header, I
knew that before that but my intention was to do some mixed exercises.
!real function vectorProduct(vec1,vec2,n)
subroutine vectorProduct(res,vec1,vec2,n)
implicit none
integer ::n ! dimension of the
vector
real, dimension(n) ::vec1,vec2 ! dimension of the vectors are
real :: res
!print*,vec1
!print*,vec2
!vectorProduct=dot_product(vec1,vec2) ! dot_product is used to
compute the
res=dot_product(vec1,vec2) ! result
!open(1,FILE='res.dat',STATUS='NEW')
!write(1,*) res
!close(1)
!end function vectorProduct
end subroutine vectorProduct
#include <iostream>
#include <vector>
#include <string>
#include <numeric>
using namespace std;
extern "C" {
double vectorproduct_(double *, double *, double *, int *);
}
int main(){
int sz;
vector<double> a,b;
double result;
a.push_back(1.4);a.push_back(3.4);
b.push_back(3.2);b.push_back(2.1);
vectorproduct_(&result,&a.front(),&b.front(),&sz);
double result1=inner_product(a.begin(),a.end(),b.begin(),0.0);
std::cout << result << std::endl;
std::cout << result1 << std::endl;
return 0;
}
The output for this is
0
11.62
+ Why do I get a 0 value from Fortran subroutine?
+ Second question(just curious about to give a try to file processing)
is that if I would like to write the result inside the fortran
subroutine, I am uncommenting the 3 lines related to file operation,
and compiling and linking fine but there is still a problem with the
IO differences between two programming languages I guess(not sure
though)
vecpro.o: In function `vectorproduct_':
vecpro.f90:(.text+0xcb): undefined reference to `_gfortran_st_open'
vecpro.f90:(.text+0x101): undefined reference to `_gfortran_st_write'
vecpro.f90:(.text+0x11e): undefined reference to
`_gfortran_transfer_real'
vecpro.f90:(.text+0x12c): undefined reference to
`_gfortran_st_write_done'
vecpro.f90:(.text+0x162): undefined reference to `_gfortran_st_close'
collect2: ld returned 1 exit status
I should still link some fortran related library I guess, but not so
sure, could you please direct me to right locations for the above
questions?
Thx and best regards,
| |
|
| On Feb 14, 12:33 am, "FX" <coud...@alussinan.org> wrote:
>
>
> Yes, libg2c shouldn't be need. Any code compiled with gfortran should be
> linked with libgfortran, and you also need libgfortranbegin if the main
> program is Fortran.
>
Thx, what if the main is on C++ side of the mixed application? I mean
if I would like to do some file processing as mentioned above, just to
write the value of the result in a file and use that file from the C++
side, that is again a curiosity:
g++ -o test vecpro.o vecprod.o -lgfortran -lgfortranbegin
results in undefined references for the file operation intrinsics:
vecpro.o: In function `vectorproduct_':
vecpro.f90:(.text+0x83): undefined reference to `for_open'
vecpro.f90:(.text+0xac): undefined reference to `for_write_seq_lis'
vecpro.f90:(.text+0xc9): undefined reference to `for_close'
collect2: ld returned 1 exit status
Many thanks for all the kind posters,
U.T.
Best Rgds,
| |
|
| > g++ -o test vecpro.o vecprod.o -lgfortran -lgfortranbegin
If the main program is not in Fortran, libgfortranbeing is not needed
(but it shouldn't hurt).
> vecpro.o: In function `vectorproduct_':
> vecpro.f90:(.text+0x83): undefined reference to `for_open'
> vecpro.f90:(.text+0xac): undefined reference to `for_write_seq_lis'
> vecpro.f90:(.text+0xc9): undefined reference to `for_close'
These are not related to gfortran. Are you sure you're not compiling
with, say, Intel? Or using another static library that has dependencies?
--
FX
| |
|
| On Feb 14, 12:25 pm, "FX" <coud...@alussinan.org> wrote:
>
> If the main program is not in Fortran, libgfortranbeing is not needed
> (but it shouldn't hurt).
>
>
> These are not related to gfortran. Are you sure you're not compiling
> with, say, Intel? Or using another static library that has dependencies?
You were right, there was an error when I did this the 1st but when I
checked my makefile, I saw that there was a confusion,
Thx for the help,
| |
|
| On Feb 14, 12:25 pm, "FX" <coud...@alussinan.org> wrote:
>
> If the main program is not in Fortran, libgfortranbeing is not needed
> (but it shouldn't hurt).
>
>
> These are not related to gfortran. Are you sure you're not compiling
> with, say, Intel? Or using another static library that has dependencies?
>
> --
> FX
One more thing, maybe this can help me on my future tries, How may I
check the necessary libraries? I mean when I do a mixed programming
case study. For the cases for calling C++ from fortran and vice versa,
Thx again.
| |
| Jan Vorbrüggen 2008-02-14, 7:14 pm |
| > One more thing, maybe this can help me on my future tries, How may I
> check the necessary libraries? I mean when I do a mixed programming
> case study. For the cases for calling C++ from fortran and vice versa,
Such things are a bit of hit-and-miss at best. One good first step is to
ask the compiler driver to output the detailed commands it is generating
for each of the languages, and paying particular attention to the link
step. Basically, you need to take the combined set of libraries from all
concerned languages to make it work. While FX says also taking the
startup component for gfortran doesn't hurt even if the main program is
not Fortran, there are other compilers and OSes where it does hurt, and
you really have to know what you are doing.
Jan
| |
|
| > One more thing, maybe this can help me on my future tries, How may I
> check the necessary libraries? I mean when I do a mixed programming
> case study.
One advice was already given: ask the compilers programs to show you how
they invoke the linker, and check the libraries they include. Another
possibility is to not link anything, try linking and note what's missing,
then grep your compiler libraries to see which ones contain the needed
symbols; iterate until no more symbol is missing.
Last: when everything else has failed, read the compiler documentation.
There should/might be a section on mixed languages. If your favourite
compiler doesn't have it, and is free software, you can contribute the
information you've found when you've done so, to help future users!
--
FX
| |
| James Van Buskirk 2008-02-14, 7:14 pm |
| "FX" <coudert@alussinan.org> wrote in message
news:fp1jfa$20sv$1@nef.ens.fr...
> Last: when everything else has failed, read the compiler documentation.
> There should/might be a section on mixed languages. If your favourite
> compiler doesn't have it, and is free software, you can contribute the
> information you've found when you've done so, to help future users!
I can think of one compiler at least that fits this description. How
are the folks out there in userland supposed to get information like
this? If all you want to do is compile a standalone gfortran console
program, the compilation system is well-adapted to the task. But
there are so many questions about other ways one could conceivably
use compiler output. In g95, if you have a procedure that is called
from another language, there is a subroutine that you are supposed to
call first, called g95_runtime_start(). Does gfortran have a similar
requirement?
What if the program you want to interface with just can't link with
ld.exe? Is it possible to link gfortran's output with link.exe or
with GoLink?
What do you do if you want to create a Windows (not console) program?
The is a ld option -subsystem -windows which doesn't seem to work
when passed to ld.exe from gfortran.exe; I forget the syntax for
doing this just now and it's hell to try to find something like that
in gfortran's documentation.
As it is, the only way I found that makes a Windows application that
doesn't want its own console window is to create a *.dll and then a
shortcut that starts up rundll32.exe, invoking the *.dll. There are
questions about *.dll files as generated by gfortran. I presume they
have a DllMain that does any library initialization that gfortran
needs?
That's my set of questions I am left with after reading gfortran's
documentation and trying to piece together enough information to
see how to get all the Windows stuff working. Well, there is the
question about how to invoke Win32 API functions under 32-bit
Windows (it works in 64-bit Windows) that in my opinion amounts
to fixing bugs in the compiler and better documentation. For
example, gfortran can mangle some names to STDCALL specifications
but fails for most. If the failures could be reduced, that would
allow to invoke many more functions. Also, does gfortran 'know'
what calling convention to use for a procedure from the data in
its *.mod file? Steve Lionel wrote once that ifort makes a wierd
choice that permits the caller to override the calling convention
used by the callee and inherited via its *.mod file. I can't
imagine a situation where this wouldn't simply be a bug, but they
even have a directive to override this behavior. I have seen a
proposal that gfortran use some of ifort's extensions to specify
calling convention, but such conventions require that calling
convention be part of the data passed around about a procedure
by *.mod files, sort of like the code needed to evaluate the
specification expression that gives the LEN or SHAPE of a
function result. Given that you need to pass that data around
anyhow, you could adopt the rule that the calling convention to
be used is the one given by compiler switches during the
compilation of the module procedure or longhand interface, and
pass that around. Maybe it gets a little tricky when a dummy
argument has a different calling convention than its procedure,
but this still could work if the interface for the dummy
procedure were an ABSTRACT INTERFACE in a separate module in a
separate file and the dummy were declared via a PROCEDURE
statement, sort of like Note 12.14 of N1601.pdf except that
the ABSTRACT INTERFACE for function REAL_FUNC would be in a
different file.
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
| |
| Craig Powers 2008-02-14, 7:14 pm |
| Gerry Ford wrote:
> How does one know
> what libraries one needs in a simple handoff of two vectors in a calculation
> that either syntax could pull off by itself?
The issue is not with the "simple handoff of two vectors", it's with the
prior poster's introduction of I/O inside the Fortran routine. Notice
that the linker issues only arose then. There's nothing simple about a
program that involves I/O (in any language), because that necessarily
involves the language's runtime libary.
| |
| Gerry Ford 2008-02-14, 7:14 pm |
|
"Craig Powers" <enigma@hal-pc.org> wrote in message
news:47b48843$0$29924$a726171b@news.hal-pc.org...
> Gerry Ford wrote:
>
> The issue is not with the "simple handoff of two vectors", it's with the
> prior poster's introduction of I/O inside the Fortran routine. Notice
> that the linker issues only arose then. There's nothing simple about a
> program that involves I/O (in any language), because that necessarily
> involves the language's runtime libary.
I couldn't say what OP's intent was here. Indeed, I'm not sure if he has
any results yet. I was thinking I might replicate the program, given that
I now have gcc, and therefore g++.exe I've never used a c++ development
tool other than MVC.
It seems to me that you need, for output, the runtime libraries for the
syntax begins the ultimate statement:
gfortran -c vecpro.f90
g++ -c vecprod.cc
g++ -o test vecpro.o vecprod.o -lg2c
Here, you would need c++'s input/output capability. Steve promises
enlightenment with these, but I'm falling short on the usage.
gcc -v
gfortran -v
g++ -v
Like this?
gfortran -c vecpro.f90
g++ -c vecprod.cc
g++ -o -v test vecpro.o vecprod.o
How would the -v switch be meaningful except on the command line that
creates the executable?
--
Gerry Ford
"The apple was really a peach."
-- Allison Dunn on the garden of eden
| |
| Gerry Ford 2008-02-14, 7:14 pm |
| utab,
Can you repost what you have for source now, and restate your ambition?
--
Gerry Ford
"The apple was really a peach."
-- Allison Dunn on the garden of eden
"utab" <umut.tabak@gmail.com> wrote in message
news:a1dc0ef2-f6cf-41ab-9f73-6b265b88bbd8@d21g2000prf.googlegroups.com...
> On Feb 14, 12:25 pm, "FX" <coud...@alussinan.org> wrote:
>
> You were right, there was an error when I did this the 1st but when I
> checked my makefile, I saw that there was a confusion,
> Thx for the help,
| |
| Jan Vorbrüggen 2008-02-15, 4:30 am |
| > It seems to me that you need, for output, the runtime libraries for the
> syntax begins the ultimate statement:
> gfortran -c vecpro.f90
> g++ -c vecprod.cc
> g++ -o test vecpro.o vecprod.o -lg2c
As noted previously, the g2c library is not the one - you need
-lgfortran. There is also James van Buskirk's question on whether a
startup routine for the gfortran RTL needs to be called, as is often the
case in similar situations.
> gcc -v
> gfortran -v
> g++ -v
My understanding is that the point of these commands is to find out what
version of the compilers are installed, as some details depend on that.
> How would the -v switch be meaningful except on the command line that
> creates the executable?
It's only meaningful when doing nothing 8-).
Jan
| |
| Gerry Ford 2008-02-23, 7:13 pm |
|
"Craig Powers" <enigma@hal-pc.org> wrote in message
news:47b1e8d5$0$29920$a726171b@news.hal-pc.org...
> utab wrote:
snip
> Assumed shape arrays are incompatible with mixed language use unless you
> code explicitly for the descriptor on the other side, which will be highly
> nonportable (even from one version of a compiler to another, let alone
> from one compiler to another).
>
> The correct declaration would be:
> REAL, DIMENSION(n) :: vec1, vec2
>
> (as it is, you're not using n at all.)
>
>
> A Fortran array is *highly* unlikely to be compatible with a C++
> std::vector. Furthermore, Fortran parameters are much more likely to be
> compatible with C/C++ pointers than with C references. The correct
> prototype would be:
>
> extern "C" void vectorproduct_(double*, double*, double*, int*);
>
>
> This code is not doing what I believe you think it's doing. At the end of
> it, a and b are both length 10, containing;
> 0 0 0 0 0 1 2 3 4 5
>
> while the value of sz is still 5.
>
> You should either not initialize the vectors (leaving them in the default
> size of 0) or you should not use push_back but instead reference the
> location you wish to access directly. (Or, in the third alternative,
> there may be a standard algorithm that will allow you to perform the
> initialization on declaration, but a) it will ultimately just reduce to
> the loop structure, and b) it will be much more opaque to the unfamiliar
> reader.)
>
> Don't set sz until you're done modifying the size of a and b.
>
>
> Then, the correct call is:
> vectorproduct_(&result, &a[0], &b[0], &sz);
>
This version has utab making main in c++. I intend, for today, to only call
an external c++ function to return the real dot product of two vectors I
pass from fortran.
[color=darkred]
> The correct declaration would be:
> REAL, DIMENSION(n) :: vec1, vec2
So we have, in fortran:
REAL(DP) :: vec1, vec2
We populate them and call dot_product_from_cplusplus:
extern "C" double dot_product_from_cplusplus(double const * a,
double const * b)
How do I express a and b in terms of, respectively, vec1 and vec2, *and* in
fortran? If it were C++, and if I remembered correctly, you'd declare a and
b as pointers to a double-width float and then equate them to the address of
the first element of the array. Something like a = &vec1.
[color=darkred]
Does this do anything useful?
--
Gerry Ford
"Er hat sich georgiert." Der Spiegel, 2008, sich auf Chimpy Eins komma null
beziehend.
|
|
|
|
|