Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
A

alunw

@alunw
About
Posts
3
Topics
1
Shares
0
Groups
0
Followers
0
Following
0

Posts

Recent Best Controversial

  • Trouble linking with particular libs
    A alunw

    I'm not familiar with the particular libraries or DLLs are using, so I apologise if my comments below are obvious or not helpful. I think the @12 means your function is being compiled as a __stdcall function. If the function does not have a calling convention specified (e.g. __fastcall or __cdecl) or some equivalent macro (e.g. WINAPI) then your compile options may be selecting a different calling convention from the one intended. (Check for /Gz compile option and try using /Gr instead). I'd also check such things as your predefined macros (e.g. WIN32 _MSC_VER etc) and other -D options. If the code you are compiling is intended for multiple platforms things like calling conventions are likely to be very sensitive to this, because the code will be trying to cope with different compilers. Another possible cause of confusion is the method used to build the import library. You can get quite different results depending on whether you have a .DEF file or not, and whether you make use of the .EXP file or not. If you don't have a .DEF file, the linker will usually use your functions actual signature for the .LIB file, but if you have a .DEF file you may be able to remove the decoration. Personally I always use a .DEF file, and put NONAMES everywhere. It might be an idea to try to locate a makefile for the Khronos version.

    C / C++ / MFC csharp visual-studio help question announcement

  • Error C2264
    A alunw

    It is correct for this message to be an error, because C++ has much more strict rules for pointer compatibility than C. If my code is compiled as C you get warnings C4090 and C4024 instead of errors. But in this particular case I cannot see what qualifier is being lost. Have you got any other examples where this error is produced for no good reason? I too use const heavily - whenever I pass pointers or references I make them const unless they really need not to be, and I make this * const in methods as well whenever possible. I can't ever recall seeing the compiler objecting to passing a non-const something to something expecting a const something anywhere else.

    C / C++ / MFC c++ help question

  • Error C2264
    A alunw

    Microsoft C++ compilers throw the following error test.cpp test.cpp(14) : error C2664: 'fred' : cannot convert parameter 1 from 'char ** ' to 'const char ** ' Conversion loses qualifiers on the program below.

    int fred(const char ** arg)
    {
    return 0;
    }

    int fred1(const char * arg)
    {
    return 0;
    }

    int main(int argc,char **argv)
    {
    fred1(*argv);
    return fred(argv);
    }

    I am baffled by this error. As I would expect, the compiler is happy for me to pass a char * to something expecting a const char * (fred1) so what is its problem with passing a char ** to something expecting a const char **? I would understand if it complained when I pass a const char ** to something expecting a char **, but this way round should surely work. There is no problem if fred() expects char const * const *, or even char * const * I'd be interested to know what other compilers think of this code. What qualifier does it think is being lost? :confused:

    C / C++ / MFC c++ help question
  • Login

  • Don't have an account? Register

  • Login or register to search.
  • First post
    Last post
0
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups