decNumber library - compile issues - c++

I am having issues compiling the decNumber http://speleotrove.com/decimal/, source is here http://download.icu-project.org/files/decNumber/decNumber-icu-368.zip (includes examples etc. that need to be deleted)
Has anyone compiled this successfully? Your comments will be much appreciated!!
The compiler issues an error as a result of the following directives:
#if !defined(QUAD)
#error decBasic.c must be included after decCommon.c
#endif
(This is a small section of code from decCommon.c and decBasic.c is another source file)
The author of the code states in comments that these 2 source files are shared. There are no corresponding .h files.
I am on Windows 7 64 bit, compiling with Visual Studio 2010 32 bit.
Thank you in advance for your help.

decBasic.c and decCommon.c are #included at the BOTTOM of the specific implementation files (such as decDouble.c). So - you shouldn't compile decBasic.c or decCommon.c, but treat them like header files.
If you look at the MAKE file included, you can see what the compilation targets are: decBasic and decCommon are missing.
If you are using Visual Studio, you can add decBasic.c and decCommon.c as headers, so they appear in the project but will not be compiled.

decNumber is not in a compilable state in its original form as it requires some source code modifications to include standard integer types.
QDecimal library handles this issue by using slightly modified version of decNumber.
Please see QDecimal project for details:
http://code.google.com/p/qdecimal/
http://code.google.com/p/qdecimal/source/browse/doc/INSTALL.txt

When compiling with Visual Studio 2010 do not include decBasic.c and decCommmon.c to the project. These files are include-only and should not be compiled separately. In my case I am using decDouble module only and my project is setup as follows:
Header Files
decContext.h
decDouble.h
decDPD.h
decnumberlocal.h
decQuad.h
Source Files
decContext.c
decDouble.c
decQuad.c
Additionally files decBasic.c and decCommon.c are in the same directory where decQuad.c is located.

Related

Why external include directory compiles multiple times?

When I am making changes to my code, the external files are compiled multiple times. I am using math library glm, and Visual Studio seem to be compiling exactly same glm/vec3.hpp file multiple times. I have included glm header multiple time, and it seems that it doesn't use previously compiled code, but recompiles it again.
For example, in my math.h I have included.
#ifndef MATH_HH
#define MATH_HH
#include <glm/glm.hpp>
#include <glm/gtx/quaternion.hpp>
...
And when I am compiling after changes to code, I see that Visual Studio compiles glm/vec3.hpp multiples times. Basically it compiles it each time that it compiles one of my edited files.
For example, the Visual Studio output looks like this:
1>C:\test\external\glm\glm\detail\type_vec3.hpp(50,1): warning C4201: nonstandard extension used: nameless struct/union
...
10>own_file.cc
11>C:\test\external\glm\glm\detail\type_vec3.hpp(50,1): warning C4201: nonstandard extension used: nameless struct/union
...
Is there a way to prevent this? Or do I need to compile them each time some cpp file uses them? Or am I just confused of Visual Studio's style warnings?
Basically it compiles it each time that it compiles one of my edited files.
That's how C++ works. It compiles source files. Including a header file is just taking the text in that file and dumping it into your source file. Therefore, if you include a header file in 3 source files, the text of that header will be compiled 3 times.
There are precompiled headers (a compiler-specific tool), and the C++20 modules feature, that can avoid this. But outside of those, there's nothing you can do.

Why does the executable binary file contain paths of included header files?

Why does the compiled and linked executable file contain paths of header files included in my source code? I am using the wxWidgets library and compile with Visual Studio 2013 and gcc. What are these header files used for? If it is a compiler option, how can I disable it to avoid this?
Build configuration: release, static linking.
There may be several explanations for such strings to appear in the executable file:
You may have debugging information bundled in the executable for the debugger to use. Use strip to remove that, or do not use the -g compile option. You should also compile with NDEBUG defined to disable debugging code and assertions. It is usually the case for the Release mode, but you may want to double check.
Some functions may use __FILE__ for tracing or logging purposes. __FILE__ expands to the source file name at the point of macro expansion, which may be a source or a header file. One such function is assert(): it is actually a macro that expands to a test and some error reporting code that includes the current filename.
Some sources may have static source ids in the form of static char arrays to keep track of source code versions. This approach is quite obsolete, but many old sources still have them.
Look for such things in the source files or header files whose name appear in the executable and fix the problems.
wxwidgets has many asserts in its header files (e.g. in wx/string.h as you noticed), all using the wxASSERT macro defined in wx/debug.h
In order to disable these, you can #define wxDEBUG_LEVEL 0 prior to including any wxwidget headers.

About stdafx.h missing in my compiler(mingw32 on windows)

I just have a quick question. I've noticed that I don't have stdafx.h in my compiler(mingw32 on windows)
Am I supposed to have it? Or maybe is there a way to get around it?
Thanks for reading
EDIT: ok here is my current build log once I took out ALL of the includes of stdafx.h
http://pastebin.com/bczLr8xY
Read this wikipedia article. The paragraph I linked and the paragraph below it (mingw32 uses GCC).
http://en.wikipedia.org/wiki/Precompiled_header#stdafx.h
Since stdafx.h contains the most common headers I would remove every instance of #include stdafx.h and try to compile. If you get compile errors that a certain function is missing, add the appropriate header. Rinse and repeat.
No. Stdafx.h is created with MSVC++. It usually contains most common headers files. And Stdafx.h is included in every .cpp file in the beginning. It's precompiled header (if you've chosen so in the settings) created by MSVC++.
To all:
Using the pre compiled header file stdafx.h in the visual C++ always creates one or the other problem n case u have created a "Windows Console App" from Visual C++.
The Solution to it is that, just create "Empty Project", rather than the pre-compiled windows console application. After creating the Empty project, create the source File. Write the business logic and add all the required resource and header files. Keep the external dependency files in the same directory in which your source code is: e.g., C:\Users\John\Documents\Visual Studio 2010\Projects\xyz.cpp\xyz.cpp.
Finally add the source file to the global scope, that is add it to the "Empty Project" created already. It can be done by Clicking "File" on Visual Studio prompt and select the option of adding the source file to the project.
Thanks and Regards:
Rouf Khan

what does #include <crtdll/stddef.h> mean?

I am trying to compile the Scintilla control with MSVC++ 2010 Express Edition, and it's quite painful getting it to work right because I need a bunch of files. When compiling SString.h, I noticed this:
#include <crtdll/stddef.h>
I am no C++ programmer, but I do understand what
#include <xxx.h>
means, but what does the the that include mean? I get the following error with it:
Error 1 error C1083: Cannot open include file: 'crtdll/stddef.h': No such file or directory f\scintilla\lexers\sstring.h 44
Any help on how I could fix it would be appreciated.
If I am not mistaken, that is just a relative path. In other words, Visual Studio will look for stddef.h in the crtdll subdirectory of, probably, the root directory of the project.
By using the preceding function, you are summoning, and subsequently inserting a header file into your current source code.
In the case of #include <crtdll/stddef.h> you will be inserting the stddef.h header file from the crtdll directory (which should be a child folder defined in your compiler as the holding pen for header files) during the compilation and linking of your program.
By inserting the stddef.h header file into your source you are giving your program the capability to wield NULL pointer constants, which are exceedingly useful in some of the more advanced programs you may or may not have come across.
Good luck with your program!
I am no C++ programmer, but I do understand what
are you sure?
include with <> searches the include paths for the specified file and copies the content the content of that file in your .cpp.
So you are just missing the crtdll/stddef.h file, however stddef.h actually belongs to the C standardlibrary so you might replace it with #include in C or #include in C++
The easiest way would be to check your include directories. crtdll is the C standard library provided by msvc, so maybe you have to add the parent folder of your standard library include directory
This means that stddef.h needs to be included from the crtdll folder.
You need to check your include directories for Visual C++ projects to see that which are the default directories from where Visual Studio looks up for header files.
To fix this error, see that at which path have you installed the Scintilla control. The crtdll folder will be there most probably. And then, add this folder to your visual studio include directories.
You can set it in the following project properties dialog:
Here http://i56.tinypic.com/2zo9guh.jpg

Specify the name of compiled binary (*.exe) within source code in Visual Studio 2008

From this thread
http://www.codeguru.com/forum/showthread.php?p=1863547
It seems this cannot be done with:
#pragma comment(linker, "/out:mycool.exe")
Is there some simple way this can be done without having to use project settings, make files etc?
Added:
Why do I want to do this.
Well this gets into another subject which is probably my next question - working with the IDE.
I have to provide many examples in one project. They are simple single files that demonstrate different ways of doing things and each one should really be a different executable EXample1.exe, Example2.exe.
I only want to paste the source code or hand someone a SINGLE file with everything needed to make the example executable (on a web forum for example. I do not want to attach a 3.6MB project folder just to get a different executable name!
Compiling transcends source code. Source code only exists, and something has to take it and make something of it. Anything you do in source code is really just going to be a directive to the compiler. You might as well use project settings. This stuff isn't standard, because the standard only covers behavior and definitions of source code, not compilers.
g++ takes the output file as a parameter: g++ -o myexe.exe main.cpp. What should it do if it comes across a "output should be this!" directive in the source code?
Same with cl (Visual Studio), it passes the output setting into the command line.
Not to say it's impossible, but I doubt it's worth it to try and come up with a way to do it, let alone make it standard.
To use the linker pragma comment, the output file must NOT be specified in the linker section of the project properties:
project -> properties -> Linker -> General -> Output File
Delete the entry: $(OutDir)\$(ProjectName).exe
then the prama statement will work:
pragma comment(linker, "/out:mycool.exe")
Thanks to JC for the walkthrough
Specifying a complete path is not possible
http://social.msdn.microsoft.com/forums/en-US/vcgeneral/thread/11a06ecd-dcca-4d81-8626-ba0c5a1835c1/
but the work around is:
What I do is have a header file loacated somewhere near the library file, this header will include the pragma line.
pragma comment(lib, FILE "../libs/mylibary.lib")
if FILE is "C:\Project\SharedLibs\Xvid\latest.h"
then the pragma will include
"C:\Project\SharedLibs\Xvid\libs/mylibary.lib" once it has normalized the uri to remove the ..'s
this will always cause the pragma to include the library with an absolute path created from the path of the accompanying header.
I use this system to include a single header in a project and regardless of the relative paths between the lib and project the lib will always be included cleanly.
Added:
The full path can be specified as long as it is 8.3 format. This can present problems for a path like:
C:\Program Files\Abyss Web Server\htdocs\
Program files is commonly Progra~1
but a folder name with a space is more tricky. In this case it becomes AbyssW~1
The \ must be escaped resulting in \ producing a working pragma of:
#pragma comment(linker, "/out:C:\\Progra~1\\AbyssW~1\\htdocs\\MyApp.exe")
as kibibu showed:
#pragma comment(linker, "/out:\"C:\\Program Files\\Abyss Web Server\\htdocs\\MyApp.exe\"")
also works
If you don't want to stray too far from a stock Visual C++ installation, you should consider using NMake. It can integrate with the IDE using project files, but it can also simply be run from the command-line very easily. It's also far more lightweight than project files for generating an arbitrary number of simple and similar executables.