|
** Also, when you see something like
if(sizeof(T)<=sizeof(T*)){
} else {
}
I'm aware that a T* is almost always going to be 4 bytes long, but I felt the need to place things this way. I'm also aware that most of my code is lacking heavily in comments. This is because I usually work on my own, and make code that seems self explanatory to me.
|
|
|
|
|
Since you are new, you may not be aware of the following points to keep in mind:
1. Nobody is going to download your code from a link in order to look at it
2. You need to have a very specific question, and post a very short snippet of the relevant code
3. Your request of "debug/organize my code" is far to broad and general for a forum such as this
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Oh, okay. My apologies!
class Range{
private:
int mStart,mSize,myID;
public:
Range(int aStart,int aSize):mStart(aStart),mSize(aSize){}
Range(Range& r):mStart(r.mStart),mSize(r.mSize){}
Range(const Range& r):mStart(r.mStart),mSize(r.mSize){} bool operator () (int x){
return x>=0? (x<mSize || mSize==0):(-x <= mSize || mSize==0);
}
int operator [] ( int x ) {
if(!operator()(x)) throw std::range_error("Range throwing exception; invalid indice number.");
return x + mStart;
}
int Size( ){ return mSize; }
int Size( int aSize ){ return mSize = aSize; }
int Start( ) { return mStart; }
int Start( int aStart ){ return mStart = aStart; }
};
Inside Vector<> Class:
Range All( int size = -1 ) {
if(size==-1) size = arraySize;
const Range ret(0,size);
return ret;
}
And the problematic code:
T& Add(const T& nElement, int indice = -1){
Allocate();
++arraySize;
Range ran = All();
indice = ran[indice];
if ( indice < 0 ) indice = arraySize + indice;
if(sizeof(T)<=sizeof(T*)){
if(static_cast<unsigned int>(indice+1)!=arraySize) memcpy(&(((T*)tElements)[indice+1]),&(((T*)tElements)[indice]),sizeof(T)*(arraySize-indice-1));
memcpy(&(((T*)tElements)[indice]),&nElement,sizeof(T));
return (((T*)tElements)[indice]);
} else {
memcpy( &(tElements[indice+1]),&(tElements[indice]),sizeof(T*)*(arraySize-indice));
if(construct) return *(tElements[indice] = new T(nElement));
else{
T* nPtr = (T*)new char[sizeof(T)];
memcpy(nPtr,&nElement,sizeof(T));
return *(tElements[indice] = nPtr);
}
}
}
More problematic code is:
vString& vString::Insert(char* str,Range& ran){
if(!str) throw std::runtime_error("vString::Insert(const char*,Range&) - Invalid first argument.");
int end = (ran.Size())?ran.Size():strlen(str)+1;
Allocate( end );
if(arraySize == 0 ) memcpy(&(((char*)tElements)[0]),str,arraySize = end);
else memcpy()
for(int i=0;i<end;i++,str++) Vector<char>::Add(*str,ran.Start());
arraySize--;
return *this;
}
vString& vString::Insert(const char* str,Range& ran){
if(!str) throw std::runtime_error("vString::Insert(const char*,Range&) - Invalid first argument.");
int end = (ran.Size())?ran.Size():strlen(str)+1;
Allocate( end );
if(arraySize == 0 ) memcpy(&(((char*)tElements)[0]),str,arraySize = end);
else{
Range& all = All();
int indice = ran.Start();
indice = all[indice];
if(indice<0)indice+=arraySize;
if(indice<0)indice=0;
memcpy(&(((char*)tElements)[indice+end-1]),&(((char*)tElements)[indice]),end-1)
}
arraySize--;
return *this;
}
Specific issues:
Not sure if I should rely on my Vector<>::Add() method to handle everything, or if I should make the vString::Insert() method take care of things.
I am also getting trouble getting my Prepend() method to perform expected results. It passes it's first argument as-is, then the second argument as a Range(0,0) ( 0 size = indefinite size, 0 start = first element ). Append() seems to work alright, but Prepend() seems to 'erase' the old string, and replace with only one character of the new string. ( I only test with the 'const char*' and const T& functions -- the char* overload was included to show you what the function used to look like )
The roof's on fire,
but keeps out the rain,
so clench your fists,
and enjoy the pain.
|
|
|
|
|
I'm going to be straight, this code is a mess, and as you've already noticed, error prone. Why not use std::vector<> and a couple of iterators? Problem solved.
?
|
|
|
|
|
Well, I would BUT there are some problems I've found with std::vector<>:
1) Deep copies -- Every time I resize the vector, a constructor is called, or an operator = () is called. I can't remember which. Either way, if an object in an std::vector<> requires deep copies to be made, lots of time is just wasted allocating, releasing, and assigning memory.
2) For instance, take my vString class. If I had used std::vector<char> for it's base type, things might be a little more complicated, and time consuming. ( With #1 in mind )
The roof's on fire,
but it keeps out the rain.
So clench your fists,
and enjoy the pain.
|
|
|
|
|
Sorry for the late reply, but are you using an old compiler? If not, implement move semantics in your classes. It will take care of things for you.
|
|
|
|
|
|
Tyler Elric wrote: Is this what your'e referring to as "Move semantics" ?
Yes it is.
|
|
|
|
|
Hi All,
My C++ console application is crashing randomly. I heard about a Visual Studio 2010(Ultimate) version's feature "IntelliTrace". But, sad part is that IntelliTrace in VS2010 is not available for debugging C++ applications. Does anybody know about any debugger which has similar feature? Or any suggestions about how to approach to solve this kind of random crash problems?
Ramana G
|
|
|
|
|
Typically I don't rely on debuggers, they aren't helping me much (for small programs there is no need, and for large complex ones they just aren't good enough).
This is what I do:
1. include good old-fashioned logging to a file, i.e. append one line of text telling what piece of code is executing, what the value is of some key variables, etc, all with a timestamp and a thread ID.
2. run the program a number of times; if it doesn't fail frequently enough, try and force it to fail more often by either stressing the system (less free RAM, more CPU load, whatever is relevant) or by increasing its activity (e.g. lowering its timer's periods or feeding it more input).
3. then compare all the logs, looking for a pattern at the moments of the crashes.
It is essential to have the latest information in the log file, therefore I open-append-close it for each and every line; and it may need locking for thread synchronization (although I typically try it without, as that is less intrusive).
All this (and anything you might do) may alter the timing a bit (and change thread synchronization, and cause more or fewer deadlocks), but most often it is adequate to pinpoint the problem. Of course, when the log file isn't detailed enough, I keep adding log statements. It all may sound antiquated, in my experience it works great, and all it takes is intimate knowledge about your app, and some energy; no need to get familiar with debugger idiosyncrasies.
Note: Having only one author for all the code is a big help; having lots of programmers, third party products, etc. all contributing to the crashing app may make it almost unsolvable.
|
|
|
|
|
If you tell the debugger to stop on exceptions (except for a few that might be expected in your application), the debugger will stop about half of the time exactly where the problem occurs.
If you are developing native C++ application and use STL then using checked iterators will also find most misuse although if will run much more slowly in that case. Generally the performance of C++ application is more affected by debugging than C# application (or safe C++/CLI).
Very often, it is possible to just put a breakpoint at the appropriate location and find the problem really fast. You just have to learn to use the debugger. Most of the time, simply inspecting a few variable give an hint on the problem. Well, maybe with some habit...
"Edit and continue" is also very powerful as you can often correct the code as soon as the error is detected (and maybe execute the code again after ensuring it won't cause undesirable side-effect).
It is possible to compile your C++ code as managed and then see if you can use Intellitrace. In Visaul Studio 11 Ultimate Preview, it works for safe C++/CLI code... I haven't tried other options.
Adding a lot of check in code (assertions) and tracing some information also help find problems.
In my case, most of the time, assertion and validation done in libraries (STL, .NET) and the use of a debugger let me find problems relatively quickly...
Well, maybe doing .NET development and using C# for more than half my code probably do help also...
Philippe Mori
|
|
|
|
|
Get windbg off the net'o'sphere and attach it to your exe. Set up the symbols, paths etc, and when it gacks up, do a (possibly) break and then !analyze -v and windbg will tell you exactly where it went wrong.
Great tool windbg, truly greatr. Massive, complex, quirky, but a hell of a good debugger.
==============================
Nothing to say.
|
|
|
|
|
I may be wrong but my understanding is that the information IntelliTrace assembles requires Reflection, managed code, or both. So, most likely, there are no tools with similar functionality for C++. I'm quite sure if it were possible, MS would provide it already.
With regard to random crashs, IME they are caused most of the time by inproper memory access, i. e. writing to or reading from memory areas that don't belong to you or the like. Your best bet is to look for tools that find memory problems. I'm using Insure++ for this purpose, which comes with the added advantage that it finds many problems before you even start the program. It is very slow though and requires a lot of additional memory, so it might be a good idea to look around for competitive products and see which suits your needs best.
|
|
|
|
|
Hi,
Console Application? the old adage is: "When in Doubt, Print more Out". The Macro's
__LINE__ and
__FILE__ are realy handy there. Write a Dump Function, and do something like:
Dump(__FILE__,__LINE__,"Still Alive")
That is how you narrow down problems. You know your code, because you wrote it. It is hard to see how an Intellitrace debugger can have a better idea about what you wanted to write in the first place than that you can have. (It could work well in those highly structured Wizzard ridden area's such as Web Matrix. There the Author has no notion of what was written on his behalf, the only thing known to him there is what he wanted to achieve.
Commandline Programs? Not very likely Candidates for that technology.
When it trashes, you can narrow down where it happens. Also, occasional trashing tends to happen in retail code. Not much code is tested long enough in debug mode to catch an occasional trashing.
Even MS Word trashes occasionally, and that is also not always a software issue of your making.
Anyway, Debuggers don't work very well with retail code. LogFiles Do! Also, You Don't need to log in Text, You can create your own logging format, plus a (windows) app that can read and display the info.
If your code is perfect, but on occasion Windows trashes it anyways, there is little you can do (apart from re-writing Windows)
However, What are the Consequences of trashing. Did the User loose their input(inconvenience) or was an entire network or database crashed(Unmitigated Disaster). The former, Let it Go, if it is infrequent. The Latter: write your software mindfull of this, and be aware of the transaction technology you implement or wrote.
Hope this is Helpful,
Bram van Kampen
|
|
|
|
|
please send me topics or data
that are related to loops&functions.i am waiting for your reply.....
|
|
|
|
|
You can find lots of information on this by a simple Google search or by picking up a C++ reference guide, or even by reading some of the fine articles here on the CodeProject website.
|
|
|
|
|
What do you want to know? That's a really vague question... if you don't have a specific question, you're better off going to Google[^].
|
|
|
|
|
maheen zahra wrote: please send me topics
Financial markets.
maheen zahra wrote: <layer> or data
Get it off CNBC.
maheen zahra wrote: that are related to loops&functions
while(stillstupid || stilllazy)
{
buybook(*dollars);
readbook(*brain);
understand(*hardwork);
)
makemoney(*moredollars);
How is that?
==============================
Nothing to say.
|
|
|
|
|
What about in assembly? 
|
|
|
|
|
move edi edi
pop ebp esi
pop ebp+4 esx
pop ebp+8 edx
cmp esx edx
jne life + 32
push *dollars
call buybook
etc etc etc
(actually, thats a load of crap, but I dont write assembly, I just have to understand it )
==============================
Nothing to say.
|
|
|
|
|
|
thank you about infomations
|
|
|
|
|
Great answer! 5+
I'm not really sure that the read function call will work though. I have this feeling the parameter will cause a null pointer exception.
"With sufficient thrust, pigs fly just fine."
Ross Callon, The Twelve Networking Truths, RFC1925
|
|
|
|
|
Even better answer 5! 
==============================
Nothing to say.
|
|
|
|
|
Hi,
I Replied. What were you going to do if I didn't??( Or of nobody Did?)
Shoot all those that did not reply?? This community is not one of little slaves kept locked up until you issue a demand for information!
Please read the Posting notes before you ask a question on this forum!
Bram van Kampen
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
