On Jul 23, 1:50 pm, Jaco Naude <[EMAIL PROTECTED]> wrote:
> On Jul 23, 1:10 pm, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>
>
>
> > Jaco Naude wrote:
> > > What Visual C++ is doing is that it is looking for mangled names since
> > > it does not know the DLL contains C functions. I've managed to work
> > > around this by declaring the Python functions as follows before using
> > > them in the C++ application side:
>
> > > extern "C"
> > > {
> > > void Py_Initialize(void);
> > > }
>
> > > This seems to work and the C++ application side is not looking for
> > > mangled names any more. Is this the right way of doing it? It seems
> > > unnecessary to have to declare each Python function you want to use
> > > using the extern "C" way as shown above.
>
> > Eh, are you saying that you're not including the Python.h file? Because
> > it does exactly that, for each and every public function in the C API.
>
> > > It is probably more of a C++ question it turns out, but I would think
> > > that someone in the Python group would use the Python DLL in C++. The
> > > documentation also suggest that there is no extra work needed when
> > > using C++ rather than C.
>
> > Oh, but I do that all the time, without doing any extra work. Both
> > embedding Python in C++ programs and existing it with C++ extensions.
> > And I'm definitely not alone.
>
> > Here's an actual session, using the version of Visual Studio I happen to
> > have on this machine (2003, I think) from the command line:
>
> > > more test.cc
>
> > #include "Python.h"
> > #include <iostream>
>
> > main()
> > {
> > Py_Initialize();
> > PyRun_SimpleString("print 'hello'\n");
> > Py_Finalize();
>
> > std::cout << "world\n";
>
> > }
>
> > > cl cl -EHsc -MD -I \python25\include test.cc \python25\libs\python25.lib
> > Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077
> > for 80x86
> > Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
>
> > ...
>
> > > test
> > hello
> > world
>
> > If you cannot get the same console program to work in your compiler
> > setup, something's wrong with your configuration.
>
> > </F>
>
> Ok that's probably good news, although it points out that there is
> something wrong with my configuration since that does not work. I
> would rather sort out the problem that having to defined each function
> with a extern "C" command.
>
> That said, let me double check something which might be causing
> problems since you will be familiar with this. Which Python.h file do
> you include when including the DLL in your programs? The one in the
> source distribution of the one in the installation distribution? I've
> been including the one in the installation distribution all along.
> When I try to include the one in the source distribution it gets up to
> the point where it looks for the following include:
>
> #include "pyconfig.h"
>
> This file is not in the same directory as the Python.h file in the
> source distribution. Because of this I just used Python.h in the
> installation distribution.
>
> Thanks again,
> Jaco
I only saw your last message after posting my previous one. Ok, so the
problem is definitely with the include file Python.h. As I said in my
last post, I might be including the wrong one. I would appreciate it
if you can tell me which one it the correct one to use: The one in the
source distribution or the one in the release distribution
(installation done from the .msi file).
Thanks
Jaco
--
http://mail.python.org/mailman/listinfo/python-list
