Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 14 years ago.
Improve this question
G'day everyone
I'm a newbie to C++ and even more so to Borland Turbo C++ Explorer. I've just encountered this compile error. Any clues as to how to fix it?
[C++ Error] comsvcs.h(3209): E2015 Ambiguity between 'ITransaction' and 'Oledb::ITransaction'
[C++ Error] comsvcs.h(3275): E2015 Ambiguity between 'ITransaction' and 'Oledb::ITransaction'
[C++ Error] comsvcs.h(16197): E2015 Ambiguity between 'ITransaction' and 'Oledb::ITransaction'
[C++ Error] comsvcs.h(16293): E2015 Ambiguity between 'ITransaction' and 'Oledb::ITransaction'
The code where the first one occurs is
EXTERN_C const IID IID_ICreateWithTransactionEx;
#if defined(__cplusplus) && !defined(CINTERFACE)
MIDL_INTERFACE("455ACF57-5345-11d2-99CF-00C04F797BC9")
ICreateWithTransactionEx : public IUnknown
{
public:
virtual /* [helpstring][helpcontext] */ HRESULT STDMETHODCALLTYPE CreateInstance(
/* [in] */ ITransaction *pTransaction,
/* [in] */ REFCLSID rclsid,
/* [in] */ REFIID riid,
/* [iid_is][retval][out] */ void **pObject) = 0;
};
A couple of suggestions from another source:
As the error message of the compiler tells there are 2 declarations of the ITransaction datatype in scope of the compilation unit.
It seems the the ITransaction definition comes from Microsoft's comsvcs.h and that the OleDB::ITransaction is a implementation of the ITransaction interface from Borland. So you could try 2 things:
eliminate the OleDB::ITransaction definition (don't know Turbo C++, but there may be a component dealing with oleDB. Try to get rid of this. Or it may be included by using another #include. Search for the text oledb::ITransaction in your include directory and you will hopefully find the relevant file. Modify the include path so it is not included any more).
you could try to define CINTERFACE because the code resulting in the compile error will not be included if this is defined. But that may cause other problems...
Does anyone have any other suggestions?
Kind regards,
Bruce.
I have no clue how to do COM or what your ITransaction is, but it seems to me like your scope contains two ITransaction types. Can you be more explicit in your function prototype? Can you scope the ITransaction you want to use? Say "::ITransaction" (to use global namespace) or "some_other_namespace::ITransaction"?
Okay, we need to close this question somehow. After updating Turbo C++ Explorer with the latest patches the problem went away.
Thanks to all who offered suggestions along the way.
Related
I need to turn off DPI scaling in my Win32 application. The recommended way to do this programmatically is via the call:
SetProcessDpiAwarenessContext()
I am using the mingw windows environment. I verified that mingw headers don't have the call, but then several newer calls are missing from the mingw headers. Its a lot of work to update those, I am sure.
I created a local definition of that:
#define DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2 3
extern BOOL SetProcessDpiAwarenessContext(int value);
int main()
{
SetProcessDpiAwarenessContext(DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2);
}
I still get:
C:\projects\petit_ami>gcc -g3 -Iinclude -Ilibc -static tests/widget_test.c -Wl,--whole-archive bin/petit_ami_graph.a -Wl,--no-whole-archive -lwinmm -lgdi32 -lcomdlg32 -lwsock32 -luser32 -o bin/widget_test
c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: bin/petit_ami_graph.a(graphics.o): in function `pa_init_graph':
C:\projects\petit_ami/windows/graphics.c:15662: undefined reference to `SetProcessDpiAwarenessContext'
collect2.exe: error: ld returned 1 exit status
The best documentation I can find says it is in user32.dll.
This is using Windows 10 and recently updated, build: 19042.1052
Thanks for any help.
Scott Franco
San Jose, CA
Almost there. I did:
typedef BOOL (WINAPI *PGNSI)(int);
pGNSI = (PGNSI) GetProcAddress(GetModuleHandle(TEXT("user32.dll")),
"SetProcessDpiAwarenessContext");
if(NULL != pGNSI) {
dbg_printf(dlinfo, "Procedure found\n");
r = pGNSI(2);
dbg_printf(dlinfo, "r: %d\n", r);
if (!r) winerr();
}
And got:
C:\projects\petit_ami>graphics_test
windows/graphics.c:pa_init_graph():15686: Procedure found
windows/graphics.c:pa_init_graph():15688: r: 0
Error: Graph: Windows error: The parameter is incorrect.
The description of the parameter is here:
https://learn.microsoft.com/en-us/windows/win32/hidpi/dpi-awareness-context
I saw elsewhere that 2 was a valid value, but clearly that may not be correct. The suggestion by Simon to get the Visual studio environment may be operative just to get the proper value. Apologies to Simon, I can't at the moment take the rest of your suggestion. There is a long list of reasons I don't want to bore people with here.
Continued:
I installed and ran the visual studio with sample code. It works, now I am trying to figure out what DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2 is, it is not a simple integer.
Anyways, its late. I try to find the final answer tomorrow.
Continued:
The working code is:
/* function call for direct to dll */
typedef BOOL (WINAPI *PGNSI)(int);
/* select for highest DPI */
#define DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2 0xfffffffc
...
/* turn off scaling. The following call gets around the lack of a
declaration in mingw */
pGNSI = (PGNSI) GetProcAddress(GetModuleHandle(TEXT("user32.dll")),
"SetProcessDpiAwarenessContext");
if (NULL != pGNSI) {
r = pGNSI(DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2);
if (!r) winerr();
}
As you could probably guess, I am going to tie this to a user option. Now I just need to research what the effect of this new mode is on widgets and other OS features.
Thanks for all the help.
GetProcAddress works and is the recommended method when you cannot be certain if the user's OS will have the function.
If you want to resolve the symbol at link time, you need to ensure that (1) the import library has the symbol, and (2) that the calling convention and name decoration and mangling are correct.
I'm not very familiar with mingw, but I believe it comes with import libraries for some version of common Windows DLLs. Since this is a newer function, it might not be in the import library. There are tools to scan an existing DLL and create a corresponding import library, so perhaps you need to build a fresh one.
The calling convention for Win32 is __stdcall. If your compiler is using a different calling convention by default, you'll have to set it explicitly on your forward declaration of the function. Also, if you're compiling in C++ mode, you'll need to wrap the forward declaration in an extern "C" to prevent name mangling. If either of these are wrong, you'll get an "undefined reference" diagnostic from the linker because the symbol will be "decorated" differently.
I'm using mac os 10.9, I have a C++ program that uses freeglut library. When I try to make the project. It gives an error which I don't know if it's my fault or not. This is the message:
In file included from /usr/X11/include/GL/freeglut.h:18:
/usr/X11/include/GL/freeglut_ext.h:177:27: error: functions that differ only in their return type cannot be overloaded
FGAPI GLUTproc FGAPIENTRY glutGetProcAddress( const char *procName );
More information: I used CMake (version 2.8.12) to generate the Makefile, and installed the latest version of Xcode and XQuartz.
Any help is appreciated. Thank you.
In glut.h and freeglut_ext.h files:
In glut.h:
#if (GLUT_API_VERSION >= 5)
extern void * APIENTRY glutGetProcAddress(const char *procName) OPENGL_DEPRECATED(10_3, 10_9);
#endif
In freeglut_ext.h:
/*
* Extension functions, see freeglut_ext.c
*/
typedef void (*GLUTproc)();
FGAPI GLUTproc FGAPIENTRY glutGetProcAddress( const char *procName );
One of the declarations returns a function type GLUTproc (specifying a function that takes no arguments), and the other declaration returns a pointer (void*). Both functions take the same arguments (a single const char*). What the compiler says is true.
You're only seeing a complaint about "overloading" because it's C++. In C++, if a compiler thinks it's seen two different functions with the same name then each one needs to have different arguments (e.g. a different number of arguments, or distinct types).
In this case, I doubt the functions are meant to be different; they're meant to be the same, and at some point the API evolved and changed the declaration.
You need to find some way to prevent the compiler from seeing both declarations at the same time (perhaps by setting GLUT_API_VERSION). If you have to, you can #include just one of the files and see if you really need the other file (and if you did, you may have to manually declare some things to avoid a 2nd #include).
This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 9 years ago.
Having referenced this question: Can an enum class be converted to the underlying type?.
In my code I have effectively:
enum class STATE : short
{
EMPTY,
PRESENT,
PARTIAL,
};
volatile STATE state;
Then I write a typedef and a static_assert:
typedef volatile std::underlying_type<STATE> state_type;
static_assert (sizeof (state_type) == sizeof (short), "Error - unsafe for use with InterlockedCompareExchange16");
Finally I attempt to set the state with InterlockedCompareExchange16:
if (InterlockedCompareExchange16 (static_cast<state_type *>(&state), STATE::PRESENT, STATE::EMPTY) == STATE::EMPTY)
{
}
I am getting the following errors from VS2012:
My static_assert fails complaining that state_type is not the same size as short
The static_cast complains that it cannot cast from volatile STATE * to state_type *
Please can anyone give me any pointers for how to best fix my code?
From std::underlying_type:
Defines a member typedef type of type that is the underlying type for the enumeration T.
Change to:
typedef typename std::underlying_type<STATE>::type state_type;
//^^^^
A motivation for the strongly typed enum class was to prevent conversion to int, so attempting to cast to the underlying type conflicts with the intended use of the enums (see Strongly Typed Enums (revision 3)).
Instead of using OS specific threading mechanisms use std::atomic<> template that was added to c++11:
std::atomic<STATE> state(STATE::EMPTY);
STATE expected(STATE::EMPTY);
if (state.compare_exchange_strong(expected, STATE::PRESENT))
{
// 'state' set to 'PRESENT'.
}
This removes the requirement for static_assert and does not require any casting.
Hi i'm trying to call the CreateFileA win32 function from a pyx file (cython file)(windows.h is already included from the pxd file), but it doesn't work ... does anyone ever tried to do so... needs help please
More informations:
i got no errors when compiling with Mingw, but at the execution i get -1 as return value..
illustration :
myfile.pxd
cdef extern from "ftd2xx.h":
stuff....
# CreateFileA declaration
HANDLE **CreateFileA***(LPCSTR lpFileName, DWORD dwDesiredAccess,
DWORD dwShareMode, LPSECURITY_ATTRIBUTES lpSecurityAttributes,
DWORD dwCreationDisposition, DWORD dwFlagsAndAttributes,
HANDLE hTemplateFile)*
myfile.pyx
cimport myfile.pxd
def somefuction()
HANDLE a = myfile.**CreateFileA**(......)
at the execution i get -1
Negative 1 (-1 return) means there were multiple errors. It's possible that you are including from the wrong place.
Anyway, my python experience tells me that you can use win32all, from Mark Hammond, to call the win32api. That should solve all your problems.
If it doesn't:
I snooped around Stack Overflow and found lots of people had similar problems. Here are some things you can try:
mingw_setup_args={'options': {'build_ext': {'compiler': 'mingw32'}}}
import pyximport; pyximport.install(setup_args=mingw_setup_args)
Browse to: c:\Python2x\Lib\distutils\distutils.cfg:
[build]
compiler = mingw32
[build_ext]
compiler = mingw32
I encourage you to branch out. If you notice the right sidebar, "related" div on this page, you'll see that there are many people who have asked similar questions. I hope it gets you started. Alternatively, I recommend you look for a better compiler--something that will give you a full error report. Post the error report here. Try to be as precise as possible if there's anything you want to exclude, so that you remove as little helpful data as possible. You can definitely find a solution if one exists, provided you find a complete error message.
I'm almost certain that a full error report exists somewhere, and you just don't know where to look. I found out very early in my programming career that this is always the case when it seems there's "no error" to a programmer: they're looking in the wrong place. So, you should figure out where to look for a complete error report.
I'm trying to build a shared library (DLL) on Windows, using MSVC 6 (retro!) and I have a peculiar link issue I need to resolve. My shared library must access some global state, controlled by the loading application.
Broadly, what I have is this:
application.c:
static int g_private_value;
int use_private_value() {
/* do something with g_private_value */
}
int main (...) {
return shared_library_method ();
}
shared_library.c:
__declspec(dllexport) int __stdcall shared_library_method() {
use_private_value();
}
(Updated - I forgot the __declspec(dllexport) int __stdcall portion, but it's there in the real code)
How do I set up shared_library.dll so that it exports shared_library_method and imports use_private_value?
Please remember that A) I'm a unix programmer, generally, and B) that I'm doing this without Visual Studio; our automated build infrastructure drives MSVC with makefiles. If I'm omitting something that will make it easier to answer the question, please comment and I'll update it ASAP.
This is actually going to be pretty difficult to get working. On Unix/Linux you can have shared objects and applications import symbols from each other, but on Windows you can't have a DLL import symbols from the application that loads it: the Windows PE executable format just doesn't support that idiom.
I know that the Cygwin project have some sort of work-around to address this problem, but I don't believe that it's trivial. Unless you want to do lots of PE-related hacking you probably don't want to go there.
An easier solution might be to just have some sort of initializer method exported from the DLL:
typedef int (*func_ptr)();
void init_library(func_ptr func);
The application must call this at start-up, passing in the address of the function you want to share. Not exactly elegant, but it should work okay.
I'll start with half of the answer.
In shared_library.c:
__declspec(dllexport) int __stdcall shared_library_method(void)
{
}
The MSDN article about exporting function from DLL:s.
For the second half you need to export the functions from your application.c.
You can do this in the linker with:
/export:use_private_value#0
This should get you a lib-file that you build with your DLL.
The option to link the lib-file is to use GetProcAddress().
As DavidK noted if you only have a few functions it is probably easier to pass the function pointers in an init function. It is however possible to do what you are asking for.