|
Please read the guidelines on posting above. Then, post the section of your code that is failing and include a proper description of what is not working.
|
|
|
|
|
alonchap wrote: what is wrong in here?
Numerous things. For starters:
You need to check the value of prompt before trying to print it.
You are using command incorrectly (hint: it points to nothing valid).
The first argument to strtok() must be modifiable.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
hi i noe this may sound simple but im having problem in converting char to string.
string get_currenttime(){
time_t rawtime;
string s1,
stringstream ss;
struct tm * timeinfo;
char buffer [80];
time ( &rawtime );
timeinfo = localtime ( &rawtime );
strftime (buffer,80,"%c",timeinfo);
ss << buffer;
ss >> s1;
}
From the above code which i found online, i need to convert the data in buffer to string. i tried using stringstream but results are not complete. See above for example
|
|
|
|
|
You don't need the stringstream variable. Just use
s1 = buffer;
and it will create a string from the contents of buffer.
|
|
|
|
|
The difference in result that you see is because the >> operator will get characters only till a newline or space character. You could use the getline function to get the entire result. But the solution suggested by Richard MacCutchan is simple and the best.
|
|
|
|
|
We are using visual studio to build our applications. Our biggest concern is link time especially for debug target. I list bellow what we tried to minimized link time and what were the gain. If you have others suggestions, reply to my post.
Note that I post a suggestion on “Microsoft Connect” titled “Optimize link time in real developers environment”, feel free to vote for it at : https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=511300&wa=wsignin1.0
1 - Convert many statics libraries to DLLs. Important gain.
2 - Remove debug information for libraries who are rarely debugged (good gain).
3 - Delete PDB file in « Pre-Build Event » (strangely it give interesting gain ex: 2min44 instead of 3min34).
4 - Working with computer equiped with lot of RAM in order to maximize disk cache. The biggest gain. Same computer can link 20 times faster with 16GB instead of 2GB. More than 16GB change nothing.
5 - Big obj versus small obj. No difference.
6 - Use secret linker switch /expectedoutputsize:120000000. Small gain.
7 - Maximize Internal linkage vs External linkage. It's a good programming practice.
8 - IncrediLink (IncrediBuild give interesting gain for compilation but almost no gain for link).
9 - Explicit template instantiation to reduce code bloat. Small gain.
10 - Partial template specialization to decrease the number of symbols. Small gain.
11 - Change project options (/Ob1, /INCREMENTAL, Enable COMDAT folding, Embedding manifest, etc.). Some give interesting gain other not. We try to continuously maximize our settings.
12 - Separate software component as much as we can afford to minimize dependencies. You can then work in unit test that link fast. But we still have to integrate things together, we have legacy code and we worked with third party components.
Note that for all our experimentations, we meticulously measured link time to ensure repeatability.
Thanks
|
|
|
|
|
Very interesting topic. I'm working with a 1 MLOC application with only static libraries, and funny enough we also have issues with linker times in Visual Studio 
Our experience is this:
1) Incremental linker in debug-builds can give really fast link times (seconds compared to minutes). But if a change touches too many files, then it can actually cause the incremental linking to take twice the time of a full link.
2) Incremental linker doesn't work properly with static libraries by default. There is an option in VS2005 (and newer) called "Use Library Dependency Inputs" that will solve the issue by linking to all obj files in the library instead of the library itself. This is the same as Incredibuild IncrediLink (Aka. FastBuild).
3) Incremental linker doesn't work if using pragma comment to include the lib of a dll, and using relative path to the lib. The solution is to use the linker-option /LIBPATAH and not specifying path in the pragma comment.
4) Incremental linker can trip over its own feet and sometimes corrupt its incremental-helper-file (called .ilk). This can grow to a huge size (+200 MByte), and causes the incremental linker to fail or just take forever. Have implemented a pre-link step that checks that deletes the ilk-file if it looks corrupt.
5) Our datamodel objects inherits from a special template class, that implements a lot of type specific template methods. This cause a lot of implicit template instantiation all over the code. We got rid of that by declaring all methods on the template class as virtual.
6) Changing static libraries into DLLs really helps. But there is the issue about ensure code stability with versioning of DLLs so it matches properly (along with same compiler options). By compiling with Runtime CRT in a DLL, then it makes it easier to export classes, since it allows one to transfer objects over DLL boundary without needing to worry about which side should allocate/free the memory for the object.
7) Using Solid State Disks (SSD) for compiling and linking really helps performance. Good SSD disks are close to RAM in seek time and throughput (300 MByte/sec - SATA limit)
Some comments about the compiler/linker options you mentioned:
/Expectedoutputsize - There is a little documentation[^], but I never heard of it though. Will try it out.
/Ob1 - Inline function expansion should stay to default for debug-builds
/INCREMENTAL - Should only be used for debug-builds (never for release-buils). Can sometimes (As I have mentioned above) give longer linker times.
/Enable COMDAT folding - Should only be used for release builds as it slows the linker time (Can be considered for compiling debug-versions of dlls, as it will minimize the size of the debug-dll).
/Embedding manifest - If the incremental linker is working, then the embedding manifest is pretty much a no-op. If the incremental linker is having problems, then it can some times be a full link again. The manifest is kind of necessary now if wanting to mark your application as Vista/Win7 ready. You can consider leaving out the manifest for your own internal dlls, since it is the application manifest that controls everything.
It seems Microsoft have looked into pipelining the linker-process using threads in VS2010 (Coming marts 2010). This should improve linker times with 10%.
modified on Wednesday, December 9, 2009 12:06 PM
|
|
|
|
|
Thanks for your shared experiences. Note that incremental linking works well for most of our project but it doesn't work for our biggest applications. In fact, as soon as the ILK reach a given size it's always slower... For example, we have an ILK of 280 MB for one of our projects. I tried « Use Library Dependency » option but it does not resolve the problem.
As they asked me on microsoft connect, I will try to send them code that reproduce the problem (I cannot send our code). Maybe they will fix the bug or it is already fixed in Visual Studio 2010. We will try Visual Studio 2010 in January, I hope it will accelerate link time. If it does, we will switch ASAP to this release...
Do you have any suggestions for SSD drive ? Do you have one that give you interesting results ?
|
|
|
|
|
Think I will put my money in the convert-to-dlls-bucket. Instead of hoping that VS2010 will solve all our problems.
The "Use Library Dependency Input" option only ensures that incremental linking works for static-libraries. It doesn't handle the situation where the static library is so big that it breaks incremental linking.
About the SSD drive, then I just witnessed one of my co-workers seeing more consistent fast linker times, instead of the sometimes fast and sometimes slow linker times. Also Visual Studio remained responsive even when having loaded lots of project with thousands of files.
|
|
|
|
|
I have just tested the VS2010 BETA 2 with our source code, and after fighting with duplicate typenames between boost and TR1, then I was able to compile everything.
The compile and linker times are the same as VS2005 (if not worse).
The new VS2010 intellisense should be a lot better, but it doesn't feel faster than VS2005 SP1 (with intellisense patch). Also the results from the Intellisense is just as bad as in VS2005. People who are using Visual Assist, will continue to do so in VS2010.
The new VS2010 GUI in WPF is a little slower than VS2005, but the promise of it being easier to create addins makes it an overall improvement.
I guess when we start to use the new things then we will it enjoy VS2010 more:
- C++0x auto keyword when using templates
- C++0x Lambda expressions, that makes boost bind seem clumsy
- Easier deployment using xcopy
Overall VS2010 is not the new VC6 when it comes to c++, but I think the big thing in VS2010 is .NET 4.0 and the improved WPF designer. When developing new applications then it will be easier to implement these using .NET.
|
|
|
|
|
We tried VS 2010 this week (the official release). Our link time is cut by 50%, that's enough for us to switch to 2010. We hope microsoft will continue to imporve link time because it is still slow for our projects...
Note that incremental linking is working on our biggest project with 2010. The problem is that it failed when static library are modified (even if "Link Library Dependency" and "Use Library Dependancy Input" are set). We make a lot of developement in static library... Fast solution build solved this problem for VS 2003 but there is no version for 2010.
So for us 2010 is better than 2005 even if we had expected a better improvement. The only problem with 2010 is IncrediBuild: there is no version available yet...
Frédéric
|
|
|
|
|
Thank you for the update
Glad to hear that VS2010 have improved the linker times. Still using VS2005 in our main production.
Our developers are now getting quad core machines with hyper threading (Shown as 8 cores in the Task Manager)
When using the /MP compiler option, then the compile on a single computer is pretty much the same as if using Incredibuild.
Also the developers NOT using Incredibuild experience that incremental linking is actually working more often than normal.
|
|
|
|
|
hi all,
i am actually trying to load a readonly file into my application.
i am using CFileStatus's Getstatus method to find out the value of dwFileAttributes value.
i am getting the value as 33..
my doubt is, do we get this value as 33 for all readonly files?? but in msdn, its been given as 1 for readonly file..
thanks,
rakesh.
|
|
|
|
|
The status is a flag value, what means every bit that is set has his own meaning.
In your case 33 equals 0x21 (hex) equals 100001b (binary), what means the first and the sixth
bits are set.
Now if you look at th attributes:
enum Attribute {
normal = 0x00,
readOnly = 0x01,
hidden = 0x02,
system = 0x04,
volume = 0x08,
directory = 0x10,
archive = 0x20
};
You will see the 33 (0x21) means it is a readOnly and an archived file (0x01 + 0x20 == 0x21).
Greetings
Covean
|
|
|
|
|
Rakesh5 wrote: my doubt is, do we get this value as 33 for all readonly files??
Nope, according to ducomentation 33 means 'archive' AND 'read-only'.
You should test the least significative bit of the m_attribute byte, in order to get the read-only property, for instance
bool isReadOnly = (status.m_attribute & CFileStatus::Attribute.readOnly) == CFileStatus::Attribute.readOnly;
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
I am facing a tedious task of converting whole application(which have hundreds of solution files) from visual studio 2005 to visual studio 2008.
Please help in minizing the work of opening every solution file in 2008 and converting and saving.
Also please help me in chaging the project settings for all these files at once and building all the solutions.
|
|
|
|
|
Ouch. Please let me know if you learn how to update these automatically via the command line.
For the project settings, I have all of my projects using .vsprops files for project settings.
You also might be able to modify the .vcproj files, but back them up first just in case.
|
|
|
|
|
make a backup of the 2005 files and than convert a simple project and compare the differences. So sometimes you only have to change a version string. 
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
Thanks for the reply. Yeah I know using the command promt to convert the files to vs2008. But again it will open up the wizard to convert. I am expecting a tool/shortcut methos to convert a series of .sln files located in a folder at one shot. Is it possible to do that?
|
|
|
|
|
I don't know of an automated tool. I do know that the VS 2008 converter sometimes makes mistakes, the most notorious of which is failing to bring over the /O2 optimize setting in release builds.
|
|
|
|
|
Seems you can run VS 2008 with command line parameter "/convert". Hope this[^] article helps.
-Suhredayan
|
|
|
|
|
Hi,
Recently I attempted a interview. There they ask me one question,
" You have a file with employee records, with fields empno, emp name and salary. Now you have to retrieve employee information based on the employee name"
For this what I answered is, I will write a vector and based on the emp no I will search the records.
For this he again ask me what happens when that particular file is in terabytes of memory records.
Please can any one knows the approach for retrieve a emprecord from a big file based on the number....
Thanx in advance........
sampath-padamatinti
|
|
|
|
|
One solution is to build an index to the records in the file.
|
|
|
|
|
Hasnt the application which had written such file, an API too solve such tasks 
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
He may have raised the terabyte issue only because you mentioned about vector. Maybe he was expecting something else - like it is may not be a good idea to search employee information based on name, since there may be duplicates.
-Suhredayan
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
