Bernd, do you think we still need to care about 10.4 for the graphics app?
As to my experience Windows and Mac users do care more about graphics than e.g. Linux users. Apart from that, a couple of the Macs running 10.4 are here in the AEI. IIRC the presentation iMacs I once set up are still running 10.4 (I can't say that these can't be upgraded, but that would require extra work that someone has to do).
So I would be ok with dropping 10.4 support for "optional", new graphics Apps, but in general I would want to continue to support 10.4.
This doesn't necessarily mean that all new graphics apps need to be built to run on 10.4. The PPC Apps we're still shipping with a graphics App built ~4y ago that still runs on 10.3.
BTW: I'm not sure how the Windows cross-build would work with a different version of SDL.
Ah, well ..... then I will look toward my path settings, but noting that the mingw builds of SDL, Freetype2 and libxml2 are fine.
After some research it seems that a probable single cause ( ie. if there is only one cause ) is that CMAKE_CXX_COMPILER has not been set, or is otherwise invalid eg. where is g++ ?
SDL, Freetype2 and libxml2 builds do not involve CMake ......
.... indeed a distclean then rebuild with --win32 then gives :
Quote:
Building OGLFT...
-- The C compiler identification is GNU
-- The CXX compiler identification is unknown
-- Check for working C compiler: /home/mike/projects/E@HSS/windows_build/graphicsframework/install/bin/i586-pc-mingw32-gcc
-- Check for working C compiler: /home/mike/projects/E@HSS/windows_build/graphicsframework/install/bin/i586-pc-mingw32-gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: i586-pc-mingw32-g++
CMake Error: your CXX compiler: "i586-pc-mingw32-g++" was not found. Please set CMAKE_CXX_COMPILER to a valid compiler path or name.
CMake Error: Internal CMake error, TryCompile configure of cmake failed
-- Check for working CXX compiler: i586-pc-mingw32-g++ -- broken
so then a search of $ROOT/install and subdirectories finds :
i586-pc-mingw32-gcc
but not
i586-pc-mingw32-g++
... suggesting a failure of the x86-mingw32-build.sh script to be configured to do so, ie. the ( patched version of ) x86-mingw32-build.sh.conf is not honoring the line :
option GCC_LANGUAGE_OPTIONS c++
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Ah, well I've just discovered that Oliver is listed as an OGLFT author/developer.
I am indeed, but just as a normal contributor. I don't wanna take undue credit...
Quote:
[ hence your earlier comment about sending changes upstream. Which either (a) I misinterpreted as meaning me, not you or (b) you are recruiting ..... ;-} :-0. ]
Certainly b), it's OSS after all.
Quote:
- is the CMake warning about this CMakeLists.txt file relevant to the subsequent 'No such file or directory' errors ?
I don't think so. I think it's related to some improper MinGW environment settings. I can compile our screensaver without a problem on Debian squeeze (stable) using CMake 2.8.2 and that part of the code shouldn't differ with yours. I'll try to build your branch on that very system of ours.
Quote:
- is it CMake ( 'cos I don't see a gcc/g++ command line in the build.log, but it still might be from them coming back out via CMake ) the tool reporting those 'No such file or directory' errors ?
No, it's the underlying compiler. CMake simply hides the command line clutter and forwards only warnings and errors.
Quote:
- if not the above, then I will look toward my path settings, but noting that the mingw builds of SDL, Freetype2 and libxml2 are fine.
Hm, strange. What Linux flavor and CMake version do you use?
never arrives with either unattended download, or by running the script x86-mingw32-build.sh with interactive prompts in a terminal session ( requesting latest downloads and selecting c++ as an extra ).
However if I get it manually, say from here then you get an expected mingw build with i586-pc-mingw32-g++ in $ROOT/install/bin !!!
Then the win32 build completes through build_oglft_mingw() ..... :-)
[ I still await the build_boinc_mingw() completion .... stay tuned ]
Lessons ? For me, I'd say :
#1. This section in the mingw build script ( x86-mingw32-build.sh ) probably says it all :
[pre]# Check that all required packages are either available locally,
# or can be downloaded from a source repository identified on set-up.
#
echo "
$script: checking package availability ..."
setbuilddir $PACKAGE_DIR .
for FILE in $DOWNLOAD
do
prompt " $FILE ... "
if test -f $FILE
then
echo ok
elif isyes $ALLOW_DOWNLOADS
then
echo downloading ...
#
# This kludgy download hack is required to defend against bizarre
# behaviour of SourceForge's mirror selection mechanism, which allows
# `wget' to apparently succeed, when it should fail; when this occurs,
# it actually downloads complete garbage, with an odd and unexpected
# name, bearing no resemblance to the file requested.
#
( manifest=`echo *`
$RUN wget $DOWNLOAD_HOST/$FILE$DOWNLOAD_OPTIONS && \
{ test -f $FILE || \
{ for file in `echo *`
do
for keep in $FILE $manifest
do
test "x$file" = "x$keep" && { file="."; break; }
done
test "x$file" = "x." || rm "./$file"
done; false
}
}
) || die $? "$script: $FILE: download failed"
else
die 2 "missing ...
$script: unable to continue"
fi
done[/pre]
since I didn't get any of the error messages in this section of script with reference to gcc-g++-3.4.5-20060117-2-src.tar.gz, then I'd assume that gcc-g++-3.4.5-20060117-2-src.tar.gz actually wasn't listed for download ( ie. one of $DOWNLOAD ). Go figure ......
and store them safely outside of the build tree ( ie. not anywhere in/under $ROOT )
#3 After --distclean, do a --win32 build until it/if complains about lack of packages. Copy the above packages into $ROOT/3rdparty/mingw/packages and try --win32 again !!
Cheers, Mike.
( edit ) BTW : I found out about gcc-g++-3.4.5-20060117-2-src.tar.gz as it was listed in the obsolete instructions package list.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Honestly, I recommend dropping the GCC 3 based MinGW for good. Rebase your branch to (or merge) our master and use a "proper" GCC 4 based MinGW, actively maintained by a trustworthy Linux distribution of your choice (I'd go for Debian). I don't remember exactly why but at some point I had to switch to GCC 4, hence my decision to use Debian's stock MinGW instead of the then incompatible xscripts-approach. Safe yourself a lot of unproductive time...
Honestly, I recommend dropping the GCC 3 based MinGW for good. Rebase your branch to (or merge) our master and use a "proper" GCC 4 based MinGW, actively maintained by a trustworthy Linux distribution of your choice (I'd go for Debian). I don't remember exactly why but at some point I had to switch to GCC 4, hence my decision to use Debian's stock MinGW instead of the then incompatible xscripts-approach. Safe yourself a lot of unproductive time...
Good advice, life's too short ! :-)
Will do ....
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
- checked that the --linux build was unaffected. OK.
- entirely --win32 compiled SDL, Freetype2, libxml2, OGLFT, BOINC libs then solarsystem framework, orc and finally my application. Your latest build script only required a quick edit to substitute/mutatis-mutandis solarsystem for starsphere, and worked beautifully without any extra attention. Neat ! :-)
[ mild trouble with mingw's greed for virtual memory when the C++ STL is involved, but sorted that .... ]
Now I just need to fix a linker path issue and we'll get an executable.
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Well guys, this cross platform build just doesn't want to lie down .... :-) :-)
The 'linker path issue' I mentioned is rather more significant, and is not a path problem. This is not trouble with the E@H framework per se, but my choice of code with respect to Windows. It will still be of importance regardless. Read on ....
#1 The linker errors are all one of these flavours :
[pre]undefined reference to `_glBindBuffer@8'
undefined reference to `_glBufferData@16'
undefined reference to `_glMapBuffer@8'
undefined reference to `_glUnmapBuffer@4'
undefined reference to `_glDeleteBuffers@8'
undefined reference to `_glGenBuffers@8'[/pre]
being compiler mangled versions of sought after, but denied, references to :
There are no other linker errors. So the build is otherwise perfect right up until this point.
#2 Those above six functions are a suspiciously related subset of all the OpenGL calls in my code. In fact they are the only ones from OpenGL version 1.5 and above.
#3 MS Windows has not supported OpenGL for quite some time, as v1.1 was released circa 1996. I cannot think of any direct reason for this eXceptional business practice .... :-) ;-) :-}
#4 At runtime, opengl32.dll does not export any function names above those in the v1.1 standard. Thus the 'standard' OpenGL win32 headers - the ones without 'ext' in their name, or derivations thereof that don't engage GL_GLEXT_PROTOTYPES - are oblivious to all but those known in v1.1 ....
[ BTW the makefile.mingw needs :
[pre]CPPFLAGS += -DGL_GLEXT_PROTOTYPES[/pre]
for my code. ]
.... all other OpenGL functions ( ie. invented post ~1996 ) are considered as 'extensions' and are handled by the Windows Installable Client Driver ( ICD ) for a given installed video card on the day, and that is generally written by the card vendors. The ICD is the Windows way of saying 'the vendor handles that stuff'. The upshot is that statically one cannot obtain addresses of these post v1.1 functions in the usual way for a linker to resolve. Hence the build difficulty as above.
#5 However, at runtime the ICD can be queried to (a) determine if a given functionality is supported ( whether OpenGL standard or not ) and (b) obtain the actual address(es) of said function(s) in order to perform a call(s) from the application code. For instance there is a mildly complex but still eminently do-able procedure involving arcane looking function pointers and a Windows API call
that returns either a NULL or the address of said function from the OpenGL context at the time the call was made. BTW this just begs to use typedef's.
Assuming that my analysis is correct so far, then I can think of several alternative solutions :
#1 Don't use any post v1.1 OpenGL functionality eg. Starsphere for --win32 builds. For me that is Sad Panda.
#2 As mentioned, use wglGetProcAddress sprinkled throughout the code to disclose, at runtime, the needed call targets and preferably after using glGetString(GL_EXTENSIONS) to validate the desired ability at all, plus check for NULL pointer returns etc. Hide this OS dependency behind some class interface, combined with conditional compilation using #ifdef and _WIN32_ et al. Notably this has to be enacted for each distinct OpenGL context, so in our case repeated with every resize event at least.
#3 Same as #2 but via SDL's SDL_GL_GetProcAddress(). SDL automagically includes the wgl header(s) and uses wglGetProcAddress under it's hood anyway.
#4 Incorporate the GL Extension Wrangler into the build. This is an entire library that fundamentally wraps all this 'extension' stuff away out of sight, behind yet another interface. However to be included in our current screensaver framework would require non-trivial re-working - ordering of includes, dependencies etc - and I'm not sure at all whether SDL would be happy co-habiting. This would not benefit existing Linux and Mac build strategies, perhaps detrimental. If there's one thing I've learned recently it is to beware of fiddling with a working build system .... aye, there be dragons !!! :-) :-)
For my money I'd be happiest to go with solution number 3, I can think of a number of suitable variants on that theme to test. Most importantly I wouldn't want to prejudice any current success with non-windows builds.
??? Views ???
Cheers, Mike.
( edit ) Oh, and I can't imagine any video card made in the last ten years not supporting those six desired post v1.1 functions. Also main() could check the OpenGL version string first up on program load - didn't it used to ? - and fail out if at least v1.5 not offered.
( edit ) wglGetProcAddress() and SDL_GL_GetProcAddress() effectively return type-less void's but you'll never be allowed to use them unless you cast according to the right function signature.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
For those of you wondering 'what the heck is a function pointer?' :
- data elements, whether in a object oriented language or not, are 'typed' to some degree. This means that an area of memory, which we would casually call a 'variable', with a base address and a size/extent, has a meaning attached to it's contents. This frequently also includes a set of allowable operations upon said contents. In C++ this is conveyed in the class concept which is a centralised specification for such variables, and a wrapping mechanism to hide internal detail from external form.
- now a function can also be considered as 'an area of memory', this time with 'executable' semantics. So the question arises as to what is the 'type' of a function, to which the answer is 'functional' meaning what you put in vs. what you get out. In exact terms this means a specification of the number, ordering and type of elements presented to it, and the number, order and type of elements returned from it. A black box viewpoint if you like, generically called the function's signature.
- now a pointer to a data element is an address 'labelled' with a type and hence all the semantics that flow on a per-type basis.
- a pointer to a function is 'same but different' meaning the function's address with the understanding of a particular signature. That's because when you call the function, and what is the point of having a function if you don't call it, the compiler needs to know the signature to setup the call and process it's returns.
- for either data or functions the type void ( as opposed to the keyword 'void' which may have other language uses ) means 'I have no idea of the semantics of the area of memory' or 'I have no idea what this executable area of memory does, or how to correctly execute'. It's the type with maximum semantic ignorance. This is generally a Bad Thing and if used at all should only be used in contexts where that void status is abundantly clear, and where any usage of the memory area comes after it is typed.
For me the hardest part of function pointers is their less-than-self-evident syntax and hence my suggestion regarding typdefs. They simplifying writing your code by introducing hopefully simpler or more meaningful symbols to represent potentially very complex function signatures.
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
RE: Bernd, do you think we
)
As to my experience Windows and Mac users do care more about graphics than e.g. Linux users. Apart from that, a couple of the Macs running 10.4 are here in the AEI. IIRC the presentation iMacs I once set up are still running 10.4 (I can't say that these can't be upgraded, but that would require extra work that someone has to do).
So I would be ok with dropping 10.4 support for "optional", new graphics Apps, but in general I would want to continue to support 10.4.
This doesn't necessarily mean that all new graphics apps need to be built to run on 10.4. The PPC Apps we're still shipping with a graphics App built ~4y ago that still runs on 10.3.
BTW: I'm not sure how the Windows cross-build would work with a different version of SDL.
BM
BM
RE: Ah, well ..... then I
)
After some research it seems that a probable single cause ( ie. if there is only one cause ) is that CMAKE_CXX_COMPILER has not been set, or is otherwise invalid eg. where is g++ ?
SDL, Freetype2 and libxml2 builds do not involve CMake ......
.... indeed a distclean then rebuild with --win32 then gives :
so then a search of $ROOT/install and subdirectories finds :
i586-pc-mingw32-gcc
but not
i586-pc-mingw32-g++
... suggesting a failure of the x86-mingw32-build.sh script to be configured to do so, ie. the ( patched version of ) x86-mingw32-build.sh.conf is not honoring the line :
option GCC_LANGUAGE_OPTIONS c++
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
RE: Ah, well I've just
)
I am indeed, but just as a normal contributor. I don't wanna take undue credit...
Certainly b), it's OSS after all.
I don't think so. I think it's related to some improper MinGW environment settings. I can compile our screensaver without a problem on Debian squeeze (stable) using CMake 2.8.2 and that part of the code shouldn't differ with yours. I'll try to build your branch on that very system of ours.
No, it's the underlying compiler. CMake simply hides the command line clutter and forwards only warnings and errors.
Hm, strange. What Linux flavor and CMake version do you use?
Cheers,
Oliver
Einstein@Home Project
OK, for me this guy
)
OK, for me this guy
gcc-g++-3.4.5-20060117-2-src.tar.gz
never arrives with either unattended download, or by running the script x86-mingw32-build.sh with interactive prompts in a terminal session ( requesting latest downloads and selecting c++ as an extra ).
However if I get it manually, say from here then you get an expected mingw build with i586-pc-mingw32-g++ in $ROOT/install/bin !!!
Then the win32 build completes through build_oglft_mingw() ..... :-)
[ I still await the build_boinc_mingw() completion .... stay tuned ]
Lessons ? For me, I'd say :
#1. This section in the mingw build script ( x86-mingw32-build.sh ) probably says it all :
[pre]# Check that all required packages are either available locally,
# or can be downloaded from a source repository identified on set-up.
#
echo "
$script: checking package availability ..."
setbuilddir $PACKAGE_DIR .
for FILE in $DOWNLOAD
do
prompt " $FILE ... "
if test -f $FILE
then
echo ok
elif isyes $ALLOW_DOWNLOADS
then
echo downloading ...
#
# This kludgy download hack is required to defend against bizarre
# behaviour of SourceForge's mirror selection mechanism, which allows
# `wget' to apparently succeed, when it should fail; when this occurs,
# it actually downloads complete garbage, with an odd and unexpected
# name, bearing no resemblance to the file requested.
#
( manifest=`echo *`
$RUN wget $DOWNLOAD_HOST/$FILE$DOWNLOAD_OPTIONS && \
{ test -f $FILE || \
{ for file in `echo *`
do
for keep in $FILE $manifest
do
test "x$file" = "x$keep" && { file="."; break; }
done
test "x$file" = "x." || rm "./$file"
done; false
}
}
) || die $? "$script: $FILE: download failed"
else
die 2 "missing ...
$script: unable to continue"
fi
done[/pre]
since I didn't get any of the error messages in this section of script with reference to gcc-g++-3.4.5-20060117-2-src.tar.gz, then I'd assume that gcc-g++-3.4.5-20060117-2-src.tar.gz actually wasn't listed for download ( ie. one of $DOWNLOAD ). Go figure ......
#2 Get these packages by manual download :
binutils-2.20.1-src.tar.gz
gcc-core-3.4.5-20060117-2-src.tar.gz
gcc-g++-3.4.5-20060117-2-src.tar.gz
mingwrt-3.18-mingw32-src.tar.gz
w32api-3.14-mingw32-src.tar.gz
and store them safely outside of the build tree ( ie. not anywhere in/under $ROOT )
#3 After --distclean, do a --win32 build until it/if complains about lack of packages. Copy the above packages into $ROOT/3rdparty/mingw/packages and try --win32 again !!
Cheers, Mike.
( edit ) BTW : I found out about gcc-g++-3.4.5-20060117-2-src.tar.gz as it was listed in the obsolete instructions package list.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Honestly, I recommend
)
Honestly, I recommend dropping the GCC 3 based MinGW for good. Rebase your branch to (or merge) our master and use a "proper" GCC 4 based MinGW, actively maintained by a trustworthy Linux distribution of your choice (I'd go for Debian). I don't remember exactly why but at some point I had to switch to GCC 4, hence my decision to use Debian's stock MinGW instead of the then incompatible xscripts-approach. Safe yourself a lot of unproductive time...
Best,
Oliver
Einstein@Home Project
RE: Honestly, I recommend
)
Good advice, life's too short ! :-)
Will do ....
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Progress : - merged the
)
Progress :
- merged the latest head of E@H's master to my solarsystem branch. Easy.
- installed Debian's gcc 4+ inspired mingw package. Fine.
- checked that the --linux build was unaffected. OK.
- entirely --win32 compiled SDL, Freetype2, libxml2, OGLFT, BOINC libs then solarsystem framework, orc and finally my application. Your latest build script only required a quick edit to substitute/mutatis-mutandis solarsystem for starsphere, and worked beautifully without any extra attention. Neat ! :-)
[ mild trouble with mingw's greed for virtual memory when the C++ STL is involved, but sorted that .... ]
Now I just need to fix a linker path issue and we'll get an executable.
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Sounds good!
)
Sounds good!
Einstein@Home Project
Well guys, this cross
)
Well guys, this cross platform build just doesn't want to lie down .... :-) :-)
The 'linker path issue' I mentioned is rather more significant, and is not a path problem. This is not trouble with the E@H framework per se, but my choice of code with respect to Windows. It will still be of importance regardless. Read on ....
#1 The linker errors are all one of these flavours :
[pre]undefined reference to `_glBindBuffer@8'
undefined reference to `_glBufferData@16'
undefined reference to `_glMapBuffer@8'
undefined reference to `_glUnmapBuffer@4'
undefined reference to `_glDeleteBuffers@8'
undefined reference to `_glGenBuffers@8'[/pre]
being compiler mangled versions of sought after, but denied, references to :
glBindBuffer()
glBufferData()
glMapBuffer()
glUnmapBuffer()
glDeleteBuffers()
glGenBuffers()
There are no other linker errors. So the build is otherwise perfect right up until this point.
#2 Those above six functions are a suspiciously related subset of all the OpenGL calls in my code. In fact they are the only ones from OpenGL version 1.5 and above.
#3 MS Windows has not supported OpenGL for quite some time, as v1.1 was released circa 1996. I cannot think of any direct reason for this eXceptional business practice .... :-) ;-) :-}
#4 At runtime, opengl32.dll does not export any function names above those in the v1.1 standard. Thus the 'standard' OpenGL win32 headers - the ones without 'ext' in their name, or derivations thereof that don't engage GL_GLEXT_PROTOTYPES - are oblivious to all but those known in v1.1 ....
[ BTW the makefile.mingw needs :
[pre]CPPFLAGS += -DGL_GLEXT_PROTOTYPES[/pre]
for my code. ]
.... all other OpenGL functions ( ie. invented post ~1996 ) are considered as 'extensions' and are handled by the Windows Installable Client Driver ( ICD ) for a given installed video card on the day, and that is generally written by the card vendors. The ICD is the Windows way of saying 'the vendor handles that stuff'. The upshot is that statically one cannot obtain addresses of these post v1.1 functions in the usual way for a linker to resolve. Hence the build difficulty as above.
#5 However, at runtime the ICD can be queried to (a) determine if a given functionality is supported ( whether OpenGL standard or not ) and (b) obtain the actual address(es) of said function(s) in order to perform a call(s) from the application code. For instance there is a mildly complex but still eminently do-able procedure involving arcane looking function pointers and a Windows API call
WEIRD_LOOKING_FUNCTION_SPECIFIC_POINTER wglGetProcAddress(the_desired_function_name_in_a_Cstring_format)
that returns either a NULL or the address of said function from the OpenGL context at the time the call was made. BTW this just begs to use typedef's.
Assuming that my analysis is correct so far, then I can think of several alternative solutions :
#1 Don't use any post v1.1 OpenGL functionality eg. Starsphere for --win32 builds. For me that is Sad Panda.
#2 As mentioned, use wglGetProcAddress sprinkled throughout the code to disclose, at runtime, the needed call targets and preferably after using glGetString(GL_EXTENSIONS) to validate the desired ability at all, plus check for NULL pointer returns etc. Hide this OS dependency behind some class interface, combined with conditional compilation using #ifdef and _WIN32_ et al. Notably this has to be enacted for each distinct OpenGL context, so in our case repeated with every resize event at least.
#3 Same as #2 but via SDL's SDL_GL_GetProcAddress(). SDL automagically includes the wgl header(s) and uses wglGetProcAddress under it's hood anyway.
#4 Incorporate the GL Extension Wrangler into the build. This is an entire library that fundamentally wraps all this 'extension' stuff away out of sight, behind yet another interface. However to be included in our current screensaver framework would require non-trivial re-working - ordering of includes, dependencies etc - and I'm not sure at all whether SDL would be happy co-habiting. This would not benefit existing Linux and Mac build strategies, perhaps detrimental. If there's one thing I've learned recently it is to beware of fiddling with a working build system .... aye, there be dragons !!! :-) :-)
For my money I'd be happiest to go with solution number 3, I can think of a number of suitable variants on that theme to test. Most importantly I wouldn't want to prejudice any current success with non-windows builds.
??? Views ???
Cheers, Mike.
( edit ) Oh, and I can't imagine any video card made in the last ten years not supporting those six desired post v1.1 functions. Also main() could check the OpenGL version string first up on program load - didn't it used to ? - and fail out if at least v1.5 not offered.
( edit ) wglGetProcAddress() and SDL_GL_GetProcAddress() effectively return type-less void's but you'll never be allowed to use them unless you cast according to the right function signature.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
For those of you wondering
)
For those of you wondering 'what the heck is a function pointer?' :
- data elements, whether in a object oriented language or not, are 'typed' to some degree. This means that an area of memory, which we would casually call a 'variable', with a base address and a size/extent, has a meaning attached to it's contents. This frequently also includes a set of allowable operations upon said contents. In C++ this is conveyed in the class concept which is a centralised specification for such variables, and a wrapping mechanism to hide internal detail from external form.
- now a function can also be considered as 'an area of memory', this time with 'executable' semantics. So the question arises as to what is the 'type' of a function, to which the answer is 'functional' meaning what you put in vs. what you get out. In exact terms this means a specification of the number, ordering and type of elements presented to it, and the number, order and type of elements returned from it. A black box viewpoint if you like, generically called the function's signature.
- now a pointer to a data element is an address 'labelled' with a type and hence all the semantics that flow on a per-type basis.
- a pointer to a function is 'same but different' meaning the function's address with the understanding of a particular signature. That's because when you call the function, and what is the point of having a function if you don't call it, the compiler needs to know the signature to setup the call and process it's returns.
- for either data or functions the type void ( as opposed to the keyword 'void' which may have other language uses ) means 'I have no idea of the semantics of the area of memory' or 'I have no idea what this executable area of memory does, or how to correctly execute'. It's the type with maximum semantic ignorance. This is generally a Bad Thing and if used at all should only be used in contexts where that void status is abundantly clear, and where any usage of the memory area comes after it is typed.
For me the hardest part of function pointers is their less-than-self-evident syntax and hence my suggestion regarding typdefs. They simplifying writing your code by introducing hopefully simpler or more meaningful symbols to represent potentially very complex function signatures.
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal