|
As correctly pointed out, the problem at hand is deriving your own stream class. Just entering that into a search on CP (using the tag "C++") gave me a list of articles, the third of which looked promising: audio_ostream - A Text-to-Speech ostream. If nothing else it's a working example with code.
|
|
|
|
|
Hello, I've got this little program in Visual Studio C++ 2008; console application.
When I run it into debug mode, it works perfectly. If I compile for release, the instructions:
<br />
<br />
while(nVector[nPos + 1] == nVector[nPos] + 1)<br />
<br />
or
<br />
<br />
for(;nVector[nPos + 1] == nVector[nPos] + 1;)<br />
<br />
are not working...
The only one that works for both debug and release is:
<br />
<br />
nPos--;<br />
<br />
do<br />
{<br />
nPos++;<br />
}<br />
while(nVector[nPos + 1] == nVector[nPos] + 1);<br />
<br />
Here is the whole code:
<br />
<br />
<br />
#include "stdafx.h"<br />
<br />
#define SIZE_VECTOR 10<br />
#define _DEBUG_WHILE_USE<br />
<br />
<br />
unsigned int random(const unsigned int &uMin, const unsigned int &uMax);<br />
void printVector(unsigned int nVector[]);<br />
void swap(unsigned int &uFirst, unsigned int &uSecond);<br />
void randomize(unsigned int nVector[], const int &nPos);<br />
<br />
<br />
int _tmain(int argc, _TCHAR* argv[])<br />
{<br />
unsigned int nVector[SIZE_VECTOR];<br />
unsigned int nStep = 0;<br />
int nPos = 0;<br />
<br />
for(int i = 0; i < SIZE_VECTOR; i++)<br />
{<br />
nVector[i] = i;<br />
}<br />
<br />
printf("Start...\r\n\r\n");<br />
<br />
while(nPos < SIZE_VECTOR - 1)<br />
{<br />
randomize(nVector, nPos + 1);<br />
printVector(nVector);<br />
nStep++;<br />
<br />
#ifdef _DEBUG<br />
#ifdef _DEBUG_WHILE_USE<br />
while(nVector[nPos + 1] == nVector[nPos] + 1)<br />
{<br />
nPos++;<br />
}<br />
#else // _DEBUG_WHILE_USE<br />
for(;nVector[nPos + 1] == nVector[nPos] + 1;)<br />
nPos++;<br />
#endif // _DEBUG_WHILE_USE<br />
#else // _DEBUG<br />
nPos--;<br />
<br />
do<br />
{<br />
nPos++;<br />
}<br />
while(nVector[nPos + 1] == nVector[nPos] + 1);<br />
#endif // _DEBUG<br />
}<br />
<br />
printf("\r\nSteps: %d.\r\n\r\n", nStep);<br />
return 0;<br />
}<br />
<br />
unsigned int random(const unsigned int &uMin, const unsigned int &uMax)
{<br />
unsigned int uRand = 0;<br />
<br />
if((uMin <= uMax) && (rand_s(&uRand) == 0))<br />
{<br />
double dDiv = (double)uRand / (double)UINT_MAX;<br />
double dMul = dDiv * (double)(uMax - uMin + 1);<br />
uRand = (unsigned int)(dMul + uMin);<br />
}<br />
<br />
return uRand;<br />
}<br />
<br />
void printVector(unsigned int nVector[])<br />
{<br />
for(int i = 0; i < SIZE_VECTOR; i++)<br />
{<br />
printf("%2d%s", nVector[i], (i == SIZE_VECTOR - 1) ? ".\r\n" : ", ");<br />
}<br />
}<br />
<br />
void swap(unsigned int &uFirst, unsigned int &uSecond)<br />
{<br />
unsigned int uTemp = uFirst;<br />
uFirst = uSecond;<br />
uSecond = uTemp;<br />
}<br />
<br />
void randomize(unsigned int nVector[], const int &nPos)<br />
{<br />
for(int i = nPos; i < SIZE_VECTOR - 1; i++)<br />
{<br />
swap(nVector[nPos], nVector[random(i, SIZE_VECTOR - 1)]);<br />
}<br />
}<br />
<br />
with
<br />
<br />
#define _CRT_RAND_S<br />
<br />
#include <stdlib.h><br />
<br />
in stdafx.h
Does anyone have any idea why this is happening?
Thank you!
|
|
|
|
|
what do you mean "not working" ? does it crash? do you get an error message?
for(;nVector[nPos + 1] == nVector[nPos] + 1;)
my first guess is that nPos + 1 >= SIZE_VECTOR, so you're going off the end of the array and you get an access violation.
|
|
|
|
|
I mean, the instruction is as if it's not there...
No, there is no violation...
For example...
I have the vector: 1, 2, 4, 3..
In debug, he analyzes 1 and 2 and changes nPos so that in the next cycle it analyzes 2 and 4...
In release, it's as if the instruction is not there...
If I replace "while" with "if", it works for both debug and release, in:
<br />
while(nVector[nPos + 1] == nVector[nPos] + 1)<br />
{<br />
nPos++;<br />
}<br />
|
|
|
|
|
Khan Shere wrote: In release, it's as if the instruction is not there...
That is because the instructions are not there. Take a look at your source; all the code between #ifdef _DEBUG and its corresponding #endif will be excluded from the release build.
NB please also use <pre></pre> tags (not code) to format your code blocks.
I must get a clever new signature for 2011.
|
|
|
|
|
Ooops, I'm sorry, I forgot to mention: those #ifdefs I've placed there in order for the app to run in both debug and release modes.. but if you run the _DEBUG part of code in release, it won't work..
|
|
|
|
|
I have tried running your code with the various different configurations but cannot see how to tell that a particular part of the release version does not work. In each case the output is similar, although when using the for statement the program crashes.
I must get a clever new signature for 2011.
|
|
|
|
|
This sounds like an optamisation bug.
there is a similar bug with the following:
int x = 0;
int y = ++x + ++x;
You would expect this to be y = 1 + 2 (=3) which it is when optimisations are disabled, but the value of y when optimisations are turned on is 4
Try disabling optimisations in the release build. They don't help all that much unless you are after extreme speed or a tiny image.
If this helps, you can try re-enabling them 1 at a time if you want optimisation.
|
|
|
|
|
It's not a bug, it's standard behaviour. If you write statements with more than one sub-expression in it that writes to a variable then the compiler can generate any old rubbish it wants.
modified on Tuesday, February 1, 2011 2:32 PM
|
|
|
|
|
I agree, it could very well be an optimisation 'feature'.
It might be worth it to give this a shot:
while(nVector[nPos + 1] == (nVector[nPos] + 1))
modified 13-Sep-18 21:01pm.
|
|
|
|
|
It still doesn't work.
I also suspect it's an optimization 'feature'.. just read the other day about the bogosort on wikipedia (http://en.wikipedia.org/wiki/Bogosort) and wanted to play a little with it and discovered this little gem between debug and release versions.. and this is by no means an application, just a little fun I was having, but such an 'optimization' in a big and important program could really have a serious problematic impact. 
|
|
|
|
|
hi guys
probably already discussed but I did not find the explenation:
in the above code:
My question is why I have to use reference to the pointer
when returning from mGetPt?
If this pointer whould have been used inside the function,
and for example used in constructor to allocate memory
if I have an Get function like CInner* mGetPt(void)
I am able to use the pointer as I want.
but in the above example it is required to return a reference.
(this is the return value, is not a function param; OK I know in case of function params I have to use reference to pinter)
Please someone clarify me why?
class CInner
{
public:
int mx;
CInner()
{
mx=1;
}
};
class CTest
{
private:
CInner *pt;
public:
CTest()
{
pt= NULL;
}
CInner*& mGetPt(void)
{
return pt;
}
};
int _tmain(int argc, _TCHAR* argv[])
{
CTest *obj= new CTest();
obj->mGetPt() = new CInner();
cout<<obj->mGetPt()->mx;
cin.get();
return 0;
}
|
|
|
|
|
You need to return a reference to the pointer if you want an outsider to be able to change the value of that pointer. It looks like an ugly attempt to make dependency injection. A setter/getter would IMO be clearer. Who's responsible for deallocating the instance? The contract isn't clear at all. If trying something like that, a massive comment block describing responsibilities would be a minimum.
|
|
|
|
|
Firstly, I agree with Niklas, this is terrible style and structure. A class should be responsible for allocating and deallocating all its memory.
To answer your question, returning a pointer allows you to modify the data that is pointed to (in your case this is NULL, so it would result in an access violation).
Returning a reference allows you to modify the value of the original variable returned (think of reference as "another name for the variable X")
So, in order to modify the value of the variable pt rather than the data it points to, you can either return a reference to the variable, or a pointer to the variable itself.
You are returning the reference, to return a pointer you would use it like:
CInner** mGetPt(void) {
return &pt;
}
*obj->mGetPt() = new CInner();
Having said that, this is still bad style, and you would be much better off with something like:
class CInner {
public:
CInner() : mx(1) { }
int GetMX() { return mx; }
void SetMX(int nNewMx) { mx = nNewMx; }
private:
int mx;
};
For CTest you have 2 choices, you can either allocate pt = new CInner in the constructor or when it is needed.
class CTest {
public:
CTest() : pt(new CInner) { }
~CTest() {
if (pt != NULL) {
delete pt;
}
}
CInner *mGetPt() { return pt; }
private:
CInner *pt;
};
class CTest {
public:
CTest() : pt(NULL) { }
~CTest() {
if (pt != NULL) {
delete pt;
}
}
CInner *mGetPt() {
if (pt == NULL) {
pt = new CInner;
}
return pt;
}
private:
CInner *pt;
};
You can then use it like:
int _tmain(int argc, TCHAR *argv[]) {
CTest *obj = new CTest();
cout << obj->mGetPt()->GetMX();
cin.get();
return 0;
}
|
|
|
|
|
Hi all,
I have a problem using CMemDC class in my project. I am using Visual Studio 2010, when i include and compile the class it gives error like:-
error C2011: 'CMemDC' : 'class' type redefinition
my class is working fine in visual studio 2008.
I am not getting what exactly problem is...
Thanks in advance
|
|
|
|
|
Are you using your own CMemDC class, other than the one provided by MFC Feature Pack (or VS 2010 - though iam not sure)? Then you have to rename your class to some thing else. There is a built in CMemDC Class as part of Internal Classes of MFC Feature Pack.
|
|
|
|
|
Thanks i renamed it and it worked
|
|
|
|
|
I am starting to get into the habit of putting all my own stuff into my own namespace. Proving to be the best way of avoiding naming conflicts between my stuff and MFC stuff.
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good - Use it!
|
|
|
|
|
|
Hi!
I've seen the following pair of preprocessor directives before the class declaration:
#ifndef somename
#define somename
This directive appears at each and every header file. What is the use of it?
|
|
|
|
|
It is very common that a header file will be included more than once in a single .cpp file.
If this happens then anything that is declared or defined in the header file will be defined more than once, even tho it is the same definition it will cause a compile error.
This is called a macro guard, and it ensures that the contents of the header file are only included once. an alternative to this is a single #pragma once at the top of the header file, however this only works with Visual Studio 7.0 and later.
Consider the folowing:
class Base {
};
#include "Base.h"
class Sub1 : public Base {
};
#include "Base.h"
class Sub2 : public Base {
};
#include "Sub1.h"
#include "Sub2.h"
int main() {
Sub1 s1;
Sub2 s2;
return 0;
}
Then the file Base.h will be included twice, hence the class Base will be defined twice.
This can happen with function definitions as well, so you should always use the macro guard.
Just note that at the end of the .h file there is also a #endif if you us the #ifndef
EDIT: The macro that is defined with #define and tested with #ifndef should be the same within the 1 header file, and unique amongst your project as well as any headers from other projects and libraries that you are using
|
|
|
|
|
In addition to your excellent reply, adding a #pragma once increases compilation speed since the compiler doesn't have to re-open/re-parse the file after the first #include. To make it both fast and portable, use both.
|
|
|
|
|
[edit]Please ignore this, see responses below[/edit]
Using #pragma once still forces the compiler to at least reopen the header file. If you want to prevent that as well you have to place the guards outside the header file, around every inclusion, such as this:
#define MY_GUARD_A_H
class A {
};
#ifndef MY_GUARD_A_H
#include "A.h"
#endif
I've done it like that in a project once, some 20+ years ago, but it was a hell to maintain. It did help a lot though, as it was really a huge project, and computers (and specifically file system calls) weren't all that fast at the time.
modified on Tuesday, February 1, 2011 5:55 AM
|
|
|
|
|
I don't know for sure, but I see no reason that Niklas Lindquist's comment would be wrong.
When the preprocessor sees the #pragma once in a file, it should mark that file as having been included and that it does not need to be included again.
This list would need to be kept in order for the directive to work, so there is no reason that it should need to re-open the same file to realise this.
|
|
|
|
|
I am sorry, I've just looked up the description of #pragma and according to what it says you, and Niclas, are indeed correct.
I always thought the preprocessor would always have to resolve #include statements until coming to a #pragma, but when I think about it, it's trivial to keep a list of files that have #prgama once specified. My bad for never looking for the exact definition of this feature... 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
