|
Rajesh R Subramanian wrote: Hontesly no genius.
Actually, you are a genius. Only geniuses swap not adjacent characters in a word the way you did.
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
|
|
|
|
|
Yuo wlil nto msis oen signle cahnce to mcok at me, wlil oyu?
Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP
|
|
|
|
|
Oh no, you reverted to common-man adjacent characters swapping! 
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
|
|
|
|
|
Probably this[^] would give you an idea why such swapping happens while I type.
Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP
|
|
|
|
|
Well, thanks to both of you for the explanations anyway. It solved the problem.
|
|
|
|
|
|
|
Hello everyone,
The following code will result in compile error below is because of private method of base class is also considered into name lookup, even if we can not access directly the private method of base class?
error C2385: ambiguous access of 'foo'
class Base
{
private:
void foo() {}
public:
void bar() {}
};
struct Mixin { void foo() {} };
class Derived: public Base, public Mixin
{
public:
void bar() { foo(); }
};
int main()
{
Derived().bar();
}
thanks in advance,
George
|
|
|
|
|
Yes.
C++ provides information hiding its own way, i.e. with information locking. 
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
|
|
|
|
|
Thanks CPallini,
Does your below comments relate to my question? Why? Could you provide more description please?
CPallini wrote: C++ provides information hiding its own way
regards,
George
|
|
|
|
|
It was a (unsuccessful, I see  ) pun. In OOP restricted access to a class member is denoted as Information Hiding, but you see there is actual hiding in your C++ code since derived class instance sees (even if it cannot access it) private foo member and therefore the ambiguity complains by the compiler.
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
|
|
|
|
|
Thanks CPallini,
So name lookup has nothing to do with access control, right? Does C++ bring us special benefits from this design model?
regards,
George
|
|
|
|
|
hi,
in my code i do the following thing
<br />
char* pByte = new char[16];<br />
memset( pByte, 0, 16 );<br />
memcpy( pByte,"çj]%Þ6f$.JÛ.$(ñå", 16);<br />
So, the content of my pByte pointer should be "çj]%Þ6f$.JÛ.$(ñå" (and all following characters until editor reach a null-terminated string character).
But if i check in memory what my pointer contains, i see the following value :
+ pByte 0x04b78f98 "çj]%Ãz6f$.JÃ>.$ýýýý««««««««îþîþ" char * 
I don't understand why my content is modified.
I'm using VC++ 2003.
On another project i do exactly the same thing and my pointer is not modified. the two project have exactly the same settings ...
This problem make me crazy  , all suggestions are welcome.
Thanks.
modified 14-Jun-22 21:01pm.
|
|
|
|
|
Actually your code works fine on my system, the 16 characters of pByte being initialized to "çj]%Þ6f$.JÛ.$(ñå" of course the debugger shows some garbage at the end, since the string is not 0 terminated.
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
|
|
|
|
|
"the debugger shows some garbage at the end, since the string is not 0 terminated"
as Pallini told, this what is happening in your case. you better increase your buffer length to 17 and check again, then the debugger shows the string properly.
|
|
|
|
|
The problem is not what the debugger diplay, but the content displayed.
i know my data is not null-terminated, but each character should be the same as the original string.
modified 14-Jun-22 21:01pm.
|
|
|
|
|
Ahryman40k wrote: i know my data is not null-terminated...
Then you know why it appears wrong. The terminating nul character has been overwritten.
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
This code works well on another project too.
i'm looking for a preprocessor or an option who should modify my string but i have no idea.
modified 14-Jun-22 21:01pm.
|
|
|
|
|
That code must work. Are you sure there aren't aother statements between assignment and check?
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
|
|
|
|
|
This is my problem.
It MUST work but it doesn't work ! :s
no override on new operator.
just this simple code:
char* pByte = new char[16];
memset( pByte, 0, 16 );
memcpy( pByte,"çj]%Þ6f$.JÛ.$(ñå",17);
who do not its job !
Is there any VC++ options who can change this ?? ( this is not a UNICODE problem and i really have no idea where the problem comes from )
modified 14-Jun-22 21:01pm.
|
|
|
|
|
Ahryman40k wrote: But if i check in memory what my pointer contains, i see the following value :
+ pByte 0x04b78f98 "çj]%Ãz6f$.JÃ>.$ýýýý««««««««îþîþ" char *
How are you verifying this?
Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP
|
|
|
|
|
With the VC++ 2003 debugger. In step by step debug mode.
Just after memcpy, i'm looking the content of my pointer. but datas allocated are different from original datas.
I'm looking for an option or a preprocessor whitch could modify datas ...
This problem appears in a project that i don't maintain.
In this project when copying "ç" character in a char pointer, the result become "ç".
I have all code sources.
the whole project is well compilated.
I don't know what it happens in this project ...
modified 14-Jun-22 21:01pm.
|
|
|
|
|
First check memory is allocated or not. Then check ASCII value stored in pByte memory location in memory debug window.
|
|
|
|
|
Memory is well allocated,
the value stored in memory location is provided in the first post.
modified 14-Jun-22 21:01pm.
|
|
|
|
|
Your source code file has been saved as UTF-8, but the compiler is reading it as Windows-1252 or whatever your local code page is.
Don't use characters outside of ASCII in source code, use the \x escape instead (or \u if your compiler supports it).
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
