|
__int64 is 64-bits long. I assumed you had simply typed gibberish indicating you needed a long number. If, however, the number you typed earlier (123123425364347456758696679) actually needs to be stored, __int64 isn't long enough.
LARGE_INTEGER is a Win32 thing, but it may be defined by other headers.
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
you could also use LARGE_INTEGER
|
|
|
|
|
Which also has the same 263 limitation as __int64.
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"We will be known forever by the tracks we leave." - Native American Proverb
|
|
|
|
|
Thanks for pointing that out Mr Crow. Though might I say, it has taken you two replies to say that those of us who are trying to help the OP are wrong. But you have yet to suggest an answer yourself.
|
|
|
|
|
waldermort wrote: But you have yet to suggest an answer yourself.
To suggest a way not to do something is in itself an answer. On a similar note, by eliminating all the wrong/incorrect ways of doing something, what we should be left with is the correct way. This was a philosophy used by Thomas Edison.
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"We will be known forever by the tracks we leave." - Native American Proverb
|
|
|
|
|
waldermort wrote: Though might I say, it has taken you two replies to say that those of us who are trying to help the OP are wrong. But you have yet to suggest an answer yourself.
childish...
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
You'll need to use something like the DECIMAL data type, which supports 296. If that is not an option, the only other thing I can think of is to store it as a string. I created a class once that did this, and it had basic math operations (+, -, /, *, !) so you could add, subtract, divide, etc very large numbers.
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"We will be known forever by the tracks we leave." - Native American Proverb
|
|
|
|
|
The bigger question would be "what are you trying to accomplish?" In other words, do you need to simply store the digits or mathematically manipulate them? If the latter, do you really need a number this big?
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
The reason is if i were to create a program that reqiures a digit password. But the password would be huge number (harder to figure out).
Or is this a bad way to make a password number?
Thanks for the answers everybody!!!
"If you try to talk sense to a fool, he'll think your foolish"
-- modified at 14:33 Wednesday 26th April, 2006
|
|
|
|
|
My gut feeling is that it's a terrible idea. Beyond that, an __int64 would be sufficient or simply a random string.
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
|
If you need a large numeric password then the better way to do it is store it as a string a restrict its contents to characters from '0' to '9'. This password can be arbitrarily long if stored as a string.
You would only need it to be represented as an integer if you needed arithmetic or mathematical manipulations. Note that checking if the password is correct does not need mathematics, a simple strcmp() will do the trick.
Anyway, if you needed to represent as an integer that fits in 64 bits, then I would sugest _int64 instead of LARGE_INTEGER. The _int64 is a compiler feature, and LARGE_INTEGER is a Windows feature. I would always prefer the compiler feature, for the implementation to be as platform independent as possible. If you need manipulation as an integer and it it larger than 64 bits, then I would sugest you created a class for that.
Rilhas
|
|
|
|
|
You will need a specialized library for that kind of integer precision. If the LGPL license is not a problem, then go ahead and try gmp[^]. I've used it, and I found it to be quite powerful.
|
|
|
|
|
I have developed a set of classes spread across several header and source files. Now heres the thing, I want to be able to #include just a single header file and not have to add all the files to the project. Obviously, when the source files are not added to the project the linker complains. Is there a workaround? I know a lib file could be created but I don't really want to do that if I can help it.
|
|
|
|
|
the linker can get the compiled code from a .LIB, it can get it from .OBJs as part of the project, or it can get it from .OBJs compiled outside the project.
Cleek | Image Toolkits | Thumbnail maker
|
|
|
|
|
Can't you create a header file and include all of your spread out classes in that header, then just include that consolidated header into your project?
Why is common sense not common?
Never argue with an idiot. They will drag you down to their level where they are an expert.
|
|
|
|
|
I have that same problem very often, since I always generate lib files, which sometimes come from various libs and sources from the start. So I frequently need to merge ".h" files together, in order to get a single ".lib"+".h" pair.
The solution is very simple. The DOS command "copy" can be used to copy multiple files together. The line "copy a.h+b.h+c.h d.h" will copy "a, "b", and "c" into "d". You can automate the copy process by typing it in the "Post-build step" (or post build event in VC8). If you do that, then everytime you build your project the files will be merged automatically.
That works fine if the files you are merging include only system files. If they include specific files then you must remove the inclusion statements. I created a program to do text replacements inside text files, so I add it to the post build step to replace #include " by //#include " (I use the " to diferentiate from #include <, which should not be removed). Putting the replace application in the path makes it easy to do this in all my projects.
Rilhas
|
|
|
|
|
I am writting a DLL, and want to provide a function so that Client can query
DLL version by calling this function.
As you already know, the version number is in the resource file,
I tries LoadString() API call, but failed. Can anyone give some advice??
There are many articles on how to query DLL version given an exe or dll file,
my POINT is , how can I do it inside the dll it self ???
Thanks alot!
|
|
|
|
|
|
jinzhecheng wrote: There are many articles on how to query DLL version given an exe or dll file,
my POINT is , how can I do it inside the dll it self ???
Are you saying that GetFileVersionInfo() cannot be used in a DLL where the DLL's name is used as the first argument?
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"We will be known forever by the tracks we leave." - Native American Proverb
|
|
|
|
|
Thanks Dave,
I thought this string is same as other string in resource file
This is a special case, instead of load string, use getfileversioninfo().
\
Thank you again!~
|
|
|
|
|
Hello,
I want to know wich library do you utilize to make wire framed 3D grapics with Visual C++ .NET.
I know that we can choose OpenGL. I want to know if someone utilize HOOPS or HEIDI.
Thanks,
Claude
|
|
|
|
|
I want to setup VC++ (using 2005, but that doesn't really matter) so that it makes it easy to do modular development. By that, I mean I want to create generic modules like CString, CPath which I can then use in all my projects. One way to do it would be develop all classes as single header files. These could then be put in a single folder called "Modules", with the path to this folder added to the INCLUDE search path of VC++. Each project could then just #include the modules header in each source file that used it.
A slight difference would be to create classes as a .c and .h file, and then just add these to each project that needed the module. Again, each project could then just #include the modules header in each source file that used it.
Another way, would be to compile the modules into .lib files which would then placed in a "Modules" folder along with the corresponding header file, with the path to this folder added to the LIB and INCLUDE search paths of VC++. This method has the advantage that complex modules can be developed consisting of multiple source files, which then compile to a single .lib file with a corresponding single interface header file.
Maybe a combination of the above methods, each depending on the complexity of the module being developed, would be the best way to go.
I'd be interested in hearing other people's opinions on the best/most efficient way to set up the development environment (IDE, folder structure, etc.) for this kind of modular development, including advantages and disadvantages of certain methods.
|
|
|
|
|
I put the CPP and H files into a separate folder called 'Common' or 'Shared'.
I add the path to this folder to the resource and general includes tabs for each project using one of the shared files.
Now, the reason I don't make them into libs, is that there are different project settings galore these days - debug, release, debug multi-threaded, release-multithreaded, unicode, mbcs, straight ASCII, etc. and a scad of optimizations.
So, you would need MANY different potential LIBS to be used in different projects.
So, I just find it easier for each project to just include the 'source' for each module it needs.
The disadvantage is that if you use something like serialization and one executable module (writing) is out of synch with another (reading), for example, you could end up with some strange run-time issues. But then, serialization should be performed in a DLL which they both share, to avoid such an issue in the first place.
People that start writing code immediately are programmers (or hackers), people that ask questions first are Software Engineers - Graham Shanks
|
|
|
|
|
I've been using a modular structure for years, at home and at work, based on LIB+HPP pairs.
This has various advantages. The first is that many projects take about 4 to 5 minutes to compile in the source form, and about 15 seconds using libs. That on a P4@4.2GHz.
Another advantage is that a module may be composed of various strange and hard to setup items. For example, I have a module for speech recognition that relies on SCANSOFT and LOQUENDO libraries, and some of my own wrappings. To use this as source would be difficult, since SCANSOFT and LOQUENDO's software has to be installed in the machine that compiles the module. On the other hand, pre compiling it and using it as a lib does not need LOQUENDO and SCANSOT to be installed (my libs include all other extarnal libs automatically).
My modules always have 3 files: "module_x.hpp", "module_x.lib", and "module_x_release.lib". The "hpp" file does not include any other external files or classes. This is hidden in the HPP, since all my classes have hidden internal data. For example, the HPP for a module could be as follows:
module_recognition.hpp
class Rilhas_Recognize {
protected:
struct Rilhas_Recognize_Data_Struct* itsData;
public:
Rilhas_Recognize();
~Rilhas_Recognize();
char* DoSomething();
};
This HPP does not need any inclusions, since it compiles without the exact definition of Rilhas_Recognize_Data_Struct. The CPP (which originates the libs) will be something like:
module_recognition.cpp
#include <stdio.h>
#include "this_file.h"
#include "that_file.h"
#include "loquendo.h"
#include "scansoft.h"
typdef struct Rilhas_Recognize_Data_Struct {
Rilhas_Recognize* object;
Loquendo_Handle handle;
char buffer[1000];
Scansoft_Handler asr;
} Rilhas_Recognize_Data;
Rilhas_Recognize::Rilhas_Recognize() {
itsData=new Rilhas_Recognize_Data;
itsData->object=this;
sprintf(itsData->buffer, "Hello world!");
}
Rilhas_Recognize::~Rilhas_Recognize() {
delete itsData;
}
char* Rilhas_Recognize::DoSomething() {
sprintf(itsData->buffer, "Hello again world!");
return itsData->buffer;
}
As you can see, the CPP can include many specific files. All internal operation data is hidden to the HPP and the HPP user, which makes it easy to distribute it. I use VC6, but for VC8 the setup should be easy as well. I simply create a workspace, named Module_X in its own directory. Inside it I create a "Source" directory where I will store the HPP and the source files used to produce the LIB, and where the compiled libs will be copied to. I also create a "Tools" folder where I store everything else the module needs (like LOQUENDO and SCANSOT stuff).
Then I create a project named Module_X_Con inside Module_X. This is a console project which I use for development. It includes the sources, and a simple "main.cpp" (which I create in the "Tools" folder). During development the CON project is used for debugging everything.
Then I create a Module_X_Lib which will take all the sources (except the "main.cpp" in the CON project). Note that I include external lib files to the lib project. The linker will add any external libs to the lib you are generating, so the lib becomes self-contained. In the post build step I add a command to copy the LIBs to the Source directory. Sometimes I also add a console project named "Module_X_Lib_Tester" that includes the libs and confirms everything is ok. It can use the same "main.cpp" file as the CON project.
Some projects require me to build a DLL. For that I create a "Module_X_DLL" project, and in the post build step I copy the LIB and DLL to the source directory, with the names "module_x_dll.lib" and "module_x_dll.dll" respectively. The release version takes the the names "module_x_dll_release.lib" and "module_x_dll_release.dll" (the Link name must be fixed for the release configuration). I sometimes add a console project named "Module_X_DLL_Tester" which takes the DLL libs from the Source and tests the DLL with the same "main.cpp" as before. Typically I add a pre-link step to the DLL tester to copy the DLL's from the source to the local directory.
This setup is very practical. You should note that I don't have dependent projects Y access the Source directory to take the libs or dlls directory. This is important, since I may be making changes which do not compile yet, and in the middle of the process I need to change and compile project Y. Or I may make a new version which is backward incompatible with project Y. For these situations not to be a problem, each dependent project Y has it's own "Tools" directory to where I copy frozen snapshots of everything it will need (hpp, libs, or dlls).
This project Y is then self-suficient and self-contained, and can even be passed on to another person. I still compiles perfectly even if it is 10 years old and module X has gone through several revisions, or if X has become incompatible with Y. When I need or want to update the X module in project Y I just go to the module X directory and bring fresh copies of the HPP, LIB, or DLL files to the dependent project's Y "Tools" directory.
As a final note, the multithreaded/singlethreaded version variations are usually not a problem. I used mixed versions in any project. When setting up a new project you may have to go to the link tab and ignore standard libraries like "libc", "libcd", "libcmt", and "licmtd". This is not difficult, since the linker detects the variation colision and sugests which library should be removed. I just go to the link tab and remove it, it is a very safe operation.
In the end the directory named Module_X will contain everything needed to build and test module X, including LIB's and DLL's. In the source directory I always find the CPP (which I do not use outside module X) and the distributables "module_x.hpp", "module_x.lib", and "module_x_release.lib". Eventually, for DLL projects, I also find "module_x_dll.lib", "module_x_dll.dll", module_x_dll_release.dll" and "module_x_dll_release.lib".
I hope this helps. It is nice to know that someone else recognizes the importance of adequate setup for modularity and code reusability.
Rilhas
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
