There is probably a rather elegant solution to this, but for the life of me I am unable to find any form of trig functions in gbdk – with the "math.h" library not included (probably missing something). Any help would be greatly appreciated.
I've tried including the standard "math.h" library (not included) and wasn't able to find any documentation from their website
Related
I have OVS source code and CMPH source code. Each of it has its own MakeFile. My intuition is somehow I need to include CMPH information in OVS make file and build OVS so that I can use CMPH inside OVS.
I need to use CMPH library for perfect hashing in OVS, but I am new to the C and MAKE world. I tried googling out the process but so far have not got any concrete help. It would be great if anyone can provide how to work towards the problem. I only need some initial steps on how to start tackling this problem. Any pointers would be appreciated.
I am currently trying to use some BLAS functions. I see the documentation and know what I want to use, but the described functions are nowhere in the actual source code in BLAS. I just don't get it.
I am trying to find blas_xmax_val. This is mentioned in the documentation on page 42. However, I do not see the function anywhere in the source folder.
If anyone has used BLAS before, please can you tell me what's going on here? Where am I supposed to look for it? It's not even mentioned in cblas.h.
This is not the only function with this problem. I see many functions mentioned in the documentation, but not in the source folder.
Please help!
I think this is the report of a technical forum that's recommending changes for BLAS that were just never adopted.
The only BLAS maximum functions I'm aware of are the IxAMAX() (x in {S,D,C,Z}) family, which return the index of the first occurrence of the maximum value.
The paper you point to is documentation for a code library created by its authors, and not a standard part of the C language. You have to get the code from them and install it, or find someone who has already done that. The code is freely available at http://netlib.org/blas/
A better-known library for doing this sort of thing is GSL, which might be easier to find an install (it's already installed on many Unix-like systems). http://www.gnu.org/software/gsl/
My program is written in C. I want to use library winnt.h, but I don't use Windows anymore.
Seems like a strange question; you should probably clarify which function(s) you actually need from winnt.h so that you can learn the Linux equivalent. winnt.h isn't really a general purpose "library", it's just an interface to built in Windows-specific functions.
With that as a major caveat, you may get some degree of what you want by attempting to run your app with the help of Wine. See http://www.winehq.org/ If you're just trying to run an existing app, that's may be a reasonable solution. If you're trying to make a Linux version of your app, though, that won't help you very much.
No, well you could but it's not going to do any good - the.h file just declares functions that are defined in libs that are only on windows
No. You can't.
winnt.h contains lots of macros that depend on a Windows environment and a lot of function declarations that only exist in Windows-specific libraries. So, it's not really useful (or possible) to use winnt.h on Linux.
That said, you can use Winelib, which includes most of the functionality exposed by those Windows-specific headers, and you can get those features by linking your program with Winelib. In general, this is probably not a good idea, because Winelib is relatively unstable (the functionality of a given API function may be absent, incomplete, buggy, or incompatible compared to the native Windows version). It is a much better idea to look for a Linux-native alternative to what you need.
What parts of winnt.h do you want to use? Of course, if you need some nice macroses or type definitions from it, you can freely copy it to your own header file (of course, with dependencies). But if you include all winnt.h file to your program in linux environment, you will get tons of error messages. One of the reasons for it is pronounced by Martin Beckett in his reply.
I'm finding myself doing more C/C++ code against Win32 lately, and coming from a C# background I've developed an obsession with "clean code" that is completely consistent, so moving away from the beautiful System.* namespace back to the mishmash of #defines that make up the Win32 API header files is a bit of a culture shock.
After reading through MSDN's alphabetical list of core Win32 functions I realised how simple Win32's API design actually is, and it's unfortunate that it's shrouded with all the cruft from the past 25 years, including many references to 16-bit programming that are completely irrelevant in today's 64-bit world.
I'm due to start a new C/C++ project soon, and I was thinking about how I could recreate Win32's headers on an as-needed basis. I could design it to be beautiful, and yet it would maintain 100% binary (and source) compatibility with existing programs (because the #defines ultimately resolve the same thing).
I was wondering if anyone had attempted this in the past (Google turned up nothing), or if anyone wanted to dissuade me from it.
Another thing I thought of, was how with a cleaner C Win32 API, it becomes possible to design a cleaner and easier to use C++ Win32 API wrapper on top, as there wouldn't be any namespace pollution from the old C Win32 items.
EDIT:
Just to clarify, I'm not doing this to improve compilation performance or for any kind of optimisation, I'm fully aware the compiler does away with everything that isn't used. My quest here is to have a Win32 header library that's a pleasure to work with (because I won't need to depress Caps-lock every time I use a function).
Don't do this.
It may be possible, but it will take a long time and will probably lead to subtle bugs.
However, and more importantly, it will make your program utterly impossible for anyone other than you to maintain.
There's no point in doing this. Just because there's additional cruft doesn't mean it's compiled into the binary (anything unused will be optimized out). Furthermore, on the EXTREME off-chance that anything DOES change (I dunno, maybe WM_INPUT's number changes) it's just a lot easier to use the system headers. Furthermore, what's more intuitive? I think #include <windows.h> is a lot easier to understand than #include "a-windows-of-my-own.h".
Also, honestly you never should need to even look at the contents of windows.h. Yeah I've read it, yeah it's ugly as sin, but it does what I need it to and I don't need to maintain it.
Probably the ONLY downside of using the real windows.h is that it MAY slow down compilation by a few milliseconds.
No. What's the point? Just include <windows.h>, and define a few macros like WIN32_LEAN_AND_MEAN, VC_EXTRALEAN, NOGDI, NOMINMAX, etc. to prune out the things you don't want/need to speed up your compile times.
Although the Win32 headers might be considered "messy", you pretty much never have to (or want to) look inside them. All you need to know is documented in the Win32 SDK. The exact contents of the header files are an implementation detail.
There is a ton of stuff in there that would be time-consuming and unnecessarily finicky to replicate, particularly relating to different versions of the Win32 SDK.
I recommend:
#include <windows.h>
In my opinion, this is bad practice. Tidiness and brevity is achieved by keeping to the standard practice as much as possible, and leveraging as much as possible from the platform. You need to assume Microsoft to have the ultimate expertise in their own platform, with some aspects going beyond what you know right now. In simple words, it's their product and they know best.
By rolling your own:
... you branch off from Microsoft's API, so Microsoft could no longer deliver updates to you through their standard channels
... you may introduce bugs due to your own hubris, feeling you've figured something out while you haven't
... you'd be wasting a lot of time for no tangible benefit (as the C headers don't carry any overhead into the compiled binary)
... you'd eventually create a project that's less elegant
The most elegant code is one that carries more LOC of actual program logic and as little as possible LOC for "housekeeping" (i.e. code not directly related to the task at hand). Don't fail to leverage the Platform SDK headers to make your project more elegant.
This has been attempted in the past.
In its include directory, MinGW contains its own version of windows.h. Presumably this exists to make the headers work with gcc. I don't know if it will work with a Microsoft compiler.
I'm looking for a tool that, given a bit of C, will tell you what symbols (types, precompiler definitions, functions, etc) are used from a given header file. I'm doing a port of a large driver from Solaris to Windows and figuring out where things are coming from is getting to be difficult, so this would be a huge help. Any ideas?
Edit: Not an absolute requirement, but tools that work on Windows would be a plus.
Edit #2: To clarify what I'm trying to do, I have a codebase I'm trying to port, which brings in a large number of headers. What I'd like is a tool that, given foo.c, will tell me which symbols it uses from bar.h.
I like KScope, which copes with very large projects.
KScope http://img110.imageshack.us/img110/4605/99101zd3.png
I use on both Linux and Windows :
gvim + ctags + cscope.
Same environment will work on solaris as well, but this is of course force you to use vim as editor, i pretty sure that emacs can work with both ctags and cscope as well.
You might want give a try to vim, it's a bit hard at first, but soon you can't work another way. The most efficient editor (IMHO).
Comment replay:
Look into the cscope man:
...
Find functions called by this function:
Find functions calling this function:
...
I think it's exactly what are you looking for ... Please clarify if not.
Comment replay 2:
ok, now i understand you. The tools i suggested can help you understand code flow, and find there certain symbol is defined, but not what are you looking for.
Not what you asking for but since we are talking i have some experience with porting and drivers (feel free to ignore)
It seems like compiler is good enough for your task. You just starting with original file and let compiler find what missing part, it will be a lot of empty stubs and you will get you code compiled.
At least for beginning i suggest you to create a lot of stubs and modifying original code as less as possible, later on once you get it working you can optimize.
It's might be more complex depending on the type of driver your are porting (I'm assuming kernel driver), the Windows and Solaris subsystems are not so alike. We do have a driver working on both solaris and windows, but it was designed to be multi platform from the beginning.
emacs and etags.
And I leverage make to run the tag indexing for me---that way I can index a large project with one command. I've been thinking about building a master index and separate module indecies, but haven't gotten around to implementing this yet...
#Ilya: Would pistols at dawn be acceptable?
Try doxygen, it can produce graphs and/or HTML and highly customizable