|
It is possible because C and C++ do not check array boundaries, this behavior make them fast at cost of security.
In such a small program, you see no consequences, but bigger program, you will see another variable suddenly changing of value when it is not supposed to.
int a[2];
int b;
b= 0;
a[3]=10;
cout<<a[3]<<endl;
cout<<b<<endl;
In this example, b may end up with 10 depending on compiler details
Patrice
“Everything should be made as simple as possible, but no simpler.” Albert Einstein
|
|
|
|
|
Actually the behaviour has nothing to do with speed, its a legacy of dereferenced pointers in C
p[i] is EXACTLY the same as writing *(p+i), most novice programmers will recognize the first form but not the second. The two codes are literally identical and will almost always produce the same code. The second however makes it clear that applying bound checking as a generic behaviour would break all dereferenced pointers. Some C compilers recognize the first form as a special case and will do bound checking and give a warning, but even they will not detect a bound error if the second form is used because p+i is just a pointer with an offset. That may well be, and often is intended behaviour.
So array bounds has always been and will always remain the responsibility of the C programmer. A pointer can exist to a memory that is non existent, invalid or has been previously released anyhow, so the array bound situation is no more dangerous than any of those all of which are the C programmers responsibility.
In vino veritas
|
|
|
|
|
I hate C++  it 's so difficult
|
|
|
|
|
And an easy language would be?
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
C#! 
|
|
|
|
|
Of course! nothing bad happens when you go out of range on an array in C#! 
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
Not sure if it's an agreement or not...
Let's say: no memory corruption occurs!
|
|
|
|
|
Hy,
i am using CFileStatus to get the date and time when the file was last modified.
By some files time is one hour earlier or later, but only by some files?
Does anybody have a clue why this happens?
cfile.GetStatus(m_filepaths[i], m_status);
Date=m_status.m_mtime.Format( "%d.%m.%Y %H:%M " );
|
|
|
|
|
I would guess "summertime".
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Do you have any idea how to fix this?
|
|
|
|
|
Not before you can confirm that it is broken; are the files that lack an hour created during the same period, or is it distributed randomly?
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
I have a little bit check files. Files that where modified round in period betwen November and April have time one hour later.
|
|
|
|
|
The m_mtime.Format method returns a time formatted according to the local timezone, so it may well be one hour out. You should use one of the alternative methods (see CTime Class[^]) to get the absolute time.
|
|
|
|
|
This can occur when files are stored on FAT file systems. NTFS stores all dates in UTC while FAT uses local times. The local time from FAT file systems is converted when getting the time. But this will return wrong values when the time stamp has been written by a system that uses a different time zone than the one used to read the time stamp.
See also File Times (Windows)[^].
|
|
|
|
|
|
Hi, I just need instructions to build my working source code in C++ into a dll that is compatible with Windows 7.
Thanks.
|
|
|
|
|
|
Assuming that your code has no linux OS calls in it and is just generic stuff you just define an interface for it and compile it like Jochen's answer.
If you have linux OS calls you will need to build windows replacements or use a framework.
In vino veritas
modified 29-Jun-16 13:29pm.
|
|
|
|
|
Hi, I need your help a bit in C++.
I am coding a dll but my source code has 2 errors.
Both issues stem from the same declaration in my header file.
void execute_assert(bool expr, std::string str);
When I do the function calls...
v_assert(s = MAX_ACL_DEPTH, "MAX_ACL_DEPTH too small");
and
v_assert(s < 1, "Illegal acl size (" + deb + ")");
I get the error message...
Error: too many arguments to function ‘void execute_assert(bool, std::string)’
On both counts, the parameter count is ok, so what's the problem?
Please help.
|
|
|
|
|
Does v_assert() call execute_assert() or vice-versa?
Member 12244972 wrote:
v_assert(s = MAX_ACL_DEPTH, "MAX_ACL_DEPTH too small");
Shouldn't this be:
v_assert(s == MAX_ACL_DEPTH, "MAX_ACL_DEPTH too small"); or maybe
v_assert((s == MAX_ACL_DEPTH), "MAX_ACL_DEPTH too small");
"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
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
I was making the wrong function call.
v_assert(s = MAX_ACL_DEPTH, "MAX_ACL_DEPTH too small");
should have been
execute_assert(s = MAX_ACL_DEPTH, "MAX_ACL_DEPTH too small");
Problem fixed.
Thanks all.
|
|
|
|
|
Where is the definition of v_assert, is is a macro?
|
|
|
|
|
I was making the wrong function call.
v_assert(s = MAX_ACL_DEPTH, "MAX_ACL_DEPTH too small");
should have been
<pre>execute_assert(s = MAX_ACL_DEPTH, "MAX_ACL_DEPTH too small");
Problem fixed.
Thanks all.
|
|
|
|
|
I am trying to output certain int variables to my logfile. But upon viewing the logfile these varuiables are shown in hex. any idea why this happens?
ofstream logfile;
GetLocalTime(&st);
sprintf(logfilename,"Myfilename_%d%02d%02d.log",st.wYear,st.wMonth,st.wDay);
logfile.open(logfilename, ios::app);
logfile <<"# Time is :: "<
|
|
|
|
|
I don't know why your stream uses hex format here. But you can set the format: ios_base::fmtflags - C++ Reference[^].
Because you are still using the C library function sprintf for the file name you might use it also for formatting the output. I still prefer this because it is often simpler (e.g. for date and times with leading zeroes).
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
