|
V. wrote:
If speed is primary you should use arrays.
According to Stroustrup, vectors are as efficient as arrays. (See his web site.) So it must be a question of poor usage.
Kevin
|
|
|
|
|
well, I think that if speed is important, you should go back and figure out why your application is leaking memory ... if using VC++ compile in debug mode, and use the DEBUG_NEW define macro to help you find where exactly is the leak; and/or use BoundChecker or some other 3rd party software helper to find te leaks.
you found ( from you other post ) that you copy a lot of arrays, maybe that's where you are leaking memory ...
remember that for each new there should be a delete and for each new [] there should be a delete []
Maximilien Lincourt
Your Head A Splode - Strong Bad
|
|
|
|
|
thanks everyone for your suggestions, what I've done is build the release version and it 'appears' to be fast enough for our needs. I'm currently in the process of verifying this through the code.
Andy,
|
|
|
|
|
According to Stroustrup, vectors are as efficient as arrays. (See his web site.) So it must be a question of poor usage.
Kevin
|
|
|
|
|
Hi,
I want to read a line of text from file.
Therefore I use following code:
<br />
do{<br />
fscanf(readfile, "%s", line);<br />
text += " ";<br />
text += line;<br />
}<br />
while(line.Find("\n") < 0);<br />
if I debug I can see that line will contain text until the next whitespace. So far so good, but it seems that text += line; doesn't add this value to text.
Does anybody know why?
tnx!
"If I don't see you in this world, I'll see you in the next one... and don't be late." ~ Jimi Hendrix
|
|
|
|
|
Ignore my response below; I didn't see the CString title!
The first thing that comes to mind why it would not visually append would be that line is not null terminated.
Also I think the debug watch window only displays string values up to a certain length, then its truncated. I know that this was so for VS6, not sure for VS.7
[EDIT]
That is because
text += " "cannot be used on string variables.
I am assuming that text is a character buffer. If this is the case try:
..
_tcscat(text,_T(" "));
_tcscat(text,line);
..
[/EDIT]
I Dream of Absolute Zero
|
|
|
|
|
RChin wrote:
text += " " cannot be used on string variables.
  
I didn't know that, it worked fine for me, I use it all the time?
line and text are both CStrings, the " " is appended, but the line variable isn't. I suppose this has something to do with the fscanf function, but nonetheless it seems very strange to me.
tnx for the reply though.
PS: I've tried text = text + line; and text.Append(line); too, but nothing... 
"If I don't see you in this world, I'll see you in the next one... and don't be late." ~ Jimi Hendrix
|
|
|
|
|
V. wrote:
fscanf(readfile, "%s", line);
...
while(line.Find("\n") < 0);
If line is a CString object, it cannot be used as the third parameter to fscanf().
Assuming you are wanting to read lines from the file, there are at least two methods that make more sense. The first is to use "%[^\n]" instead of "%s". This will read everything up to the '\n' character. The second is to create a CStdioFile object and use its ReadString() method.
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
tnx, this seems to work fine now 
"If I don't see you in this world, I'll see you in the next one... and don't be late." ~ Jimi Hendrix
|
|
|
|
|
The problem lies in
fscanf(readfile, "%s", line);
You cannot pass a CString variable as the parameter to fscanf. In this case it needs a char *
You will have to use a char array, or perhaps line.GetBufferSerLength(?) (see MSDN)
In either case you'll have to have some idea of the expected line length and cope with the possibility of buffer overflow. Think about a complete redesign.
The opinions expressed in this communication do not necessarily represent those of the author (especially if you find them impolite, discourteous or inflammatory).
|
|
|
|
|
Hi,
I have a problem to find a good pattern for Initializing some data once on demand, in a thread-safe manner.
My first (not thread-safe) stab at it would be:
void GetSomething(int index)
{
static CSomethingTable table;
return table[index];
}
I can ry to put a critsect around the table intialization, but I regulary end up with the same problem.
Any takers?
we are here to help each other get through this thing, whatever it is Vonnegut jr.
sighist Fold With Us! || Agile Programming | doxygen
|
|
|
|
|
What's wrong about wrapping the thing with a critical section. AFAIK this should work:
static CRITICAL_SECTION cs;
static bool initialize_cs()
{
InitializeCriticalSection(&cs);
return true;
}
static bool cs_initialized=initialize_cs();
...
void GetSomething(int index){
EnterCriticalSection(&cs);
static CSomethingTable table;
LeaveCriticalSection(&cs);
return table[index];
}You might want to embellish it by using RAII and stuff, but IMHO this is correct (modulo well known problems with the order of initialization of translation units.)
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
Want a Boost forum in Code Project? Vote here[^]!
|
|
|
|
|
The frequent scenario I have is the SomethingTable being thread safe itself, only the initializaiton is not.
This works if I make the critical section global static (i.e. I don't care in which order CS'es are initialized, they are initialized before the function is called).
However, I have a CS initialized for every Singleton, even If I never use it. I hoped for something better, but maybe I am desiring to much 
we are here to help each other get through this thing, whatever it is Vonnegut jr.
sighist Fold With Us! || Agile Programming | doxygen
|
|
|
|
|
|
ringle looks good - the sample code even has th destruciton in it
Now I only need a "Mutex" with zero-cost-initializaiton :-/
(I wanted to avoid the "init Critical Section even if we never need the singleton" implementaiton - see also my reply above)
we are here to help each other get through this thing, whatever it is Vonnegut jr.
sighist Fold With Us! || Agile Programming | doxygen
|
|
|
|
|
Peter, before you go and adopt the double check solution, please be aware that this idiom, appealing as it looks, is fundamentally broken. The most thorough exposition of the problem is given in Bacon et al. paper The "Double-Checked Locking is Broken" Declaration[^]. This issue has been devoted literally thousands of posts on comp.lang.c++ and comp.lang.c++.moderated, with threading experts rejecting its validity and lots of enthusiastics proposing seemingly correct formulations: one could call this problem the Fermat's Last Theorem of multithreaded programming, if you know what I mean (except that the theorem is true )
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
Want a Boost forum in Code Project? Vote here[^]!
|
|
|
|
|
Interesting post Joaquín, thanks. I quickly scanned the referenced article. Out of interest do you have any references to techniques that do work correctly?
Neville Franks, Author of ED for Windows www.getsoft.com and Surfulater www.surfulater.com "Save what you Surf"
|
|
|
|
|
I don't have a copy-and-paste snippet (I wish I did), sorry; seems you have to look for "memory barriers", which ensure the logical ordering of read/writes th DCL pattern relies on. These memory barriers are not portable 
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
Want a Boost forum in Code Project? Vote here[^]!
|
|
|
|
|
No problem, I don't actually need code for this (yet). I would have thought that the InterlockedIncrement() et.all. functions would come it to play here.
Neville Franks, Author of ED for Windows www.getsoft.com and Surfulater www.surfulater.com "Save what you Surf"
|
|
|
|
|
I know, it needs an memory barrier, or a volatile, or... something similar. I was looking for somethng reusable, platform specific, and efficient for larger libraries. I just wanted to check with you guys before following the ideas of my own (which don't work without a dreaded while(cond) Sleep(1)
The solutions I see don't scale well - especially the perfect ones bring in just to much code for a small library, and the acceptable ones are simply not "good enough".
we are here to help each other get through this thing, whatever it is Vonnegut jr.
sighist Fold With Us! || Agile Programming | doxygen
|
|
|
|
|
In "Modern C++ Design" Alexandrescu says that Double-Checked Locking will work on most processors with most compilers, but you need to check!
Chapter 6 is all about Singletons and worth a read.
I tried to avoid Sleep() except for the real thing.;)
Neville Franks, Author of ED for Windows www.getsoft.com and Surfulater www.surfulater.com "Save what you Surf"
|
|
|
|
|
ringle looks good - the sample code even has destruction in it, which I didn't dare to ask 
Now I only need a "Mutex" with zero-cost-initialization :-/
(That was my initial motivation. I want to avoid the "init Critical Section even if we never need the singleton" implementaiton - see also my reply above)
we are here to help each other get through this thing, whatever it is Vonnegut jr.
sighist Fold With Us! || Agile Programming | doxygen
|
|
|
|
|
Hi!, i hope you guys can help me out.
1.- to get the size of a file (i dont use mfc), i use something like:
HANDLE hfile=CreateFile("myfile.txt", GENERIC_READ, FILE_SHARE_READ, NULL, 0, NULL);
if(hfile)
{
DWORD fsize=GetFileSize(hfile, NULL);
CloseHandle(hfile);
}
is there a better way? like one that doesnt require using W32 API calls? (to keep the code portable)
2.- i now want to read from a file, using ifstream class, but the ifstream::read()function takes an int as the ammount of data to read! what if i want to read say 20MB of data? wont it overflow? . and also (ok ok its 3 questions), is there a better way to read binary (not text) data from a file? i could use the W32 APIs like ReadFile(), ReadFileEx(), etc. but i would like to keep my code as portable and object oriented as possible
thanks!
|
|
|
|
|
1. To get the size of a file, take a look at the _stat function, and the st_size member of the structure it populates.
2. Will an integer overflow? Depends on the compiler. The ANSI standard basically says that an integer can be whatever size the compiler manufacturer wants it to be. In early versions of Visual C++, targetting Windows 3, it was 16 bits. In a specialist compiler for an embedded system, it might only be 8 bits. In Visual C++ 6, its 32 bits. So provided you are using a modern version of Visual C++, you shouldn't have a problem.
3. Not a huge expert on non-Windows C++ development, but I would imagine that anything that uses the STL would be portable.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
