|
have a look at atoi() and itoa()
For me CAR is Challenge, Achievement and Recognition.
_AnShUmAn_
|
|
|
|
|
sunita ramesh wrote: How to convert int to string ,string to int in vc++.
CString::Format, wsprintf, _ttoi
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
|
|
|
|
|
Using MFC:
Convert int to string
<br />
int x=12345;<br />
CString s;
s.Format("%d", x);
Convert string to int
<br />
int x=0;<br />
CString s="12345";<br />
x = atoi(s);
Osama E. Adly
|
|
|
|
|
|
Hello
I am trying to exchange data between VB4 (16 Bit) and vc 6 using OLE. I have a problem when I try to modify string data in VB which need to be sent to c.
I can get a LPSTR from VB completely but I can not modify that in the c and give that back. AS far as I understand that would be possible with a BSTR *. But I could not get that to work in nether way.
In the following example the VB code calls the c++ code and the messagebox just shows one character 'T'. Thats all.
What am I doing wrong?
And what do I need to do to be able to modify the text in the c code so that the modification can be seen in the VB code after the call
Thanks in advance
Dirk
//////////////////////
// c++
//////////////////////
void TestDlgAutoProxy::test(BSTR FAR* text)
{
TCHAR szFinal[255];
_stprintf(szFinal, _T("%s"), (LPCTSTR) *text);
AfxMessageBox(szFinal);
}
///////////////////////////
// VB code
///////////////////////////
Private Sub Command2_Click()
Dim text As String
Dim x As Variant
t = "Text from VB to C"
x = oAuth.test(t)
MsgBox t
End Sub
|
|
|
|
|
|
Thanks Milton,
that way works fine.
How can I modify -> text, so that the change can be used in the calling function?
It must be very basic but how can I just change that variable text?
Like in the old c it would be
sprintf (text, "Thats what I want");
All other data exchange was no problem .. (yet )
Thank you
Dirk
|
|
|
|
|
You must be able to modify the value of text as you are receiving it into a BSTR pointer. So you can write the following to modify it.
_bstr_t bstr(*text);<br />
bstr += _bstr_t(" appened string here");<br />
AfxMessageBox(bstr);
No need to change the Vb code. Since by default VB passes function parameters by reference.
cheers...milton.
|
|
|
|
|
Thanks Milton..
that works.
Dirk
|
|
|
|
|
Hi Milton,
there is one question left.
Is there a way to convert that bstr into a character string?
So I need a modification also in the other way round.
cheers
Dirk
|
|
|
|
|
Dihirk wrote: convert that bstr into a character string?
sprintf(...) ?!
Maxwell Chen
|
|
|
|
|
Hi Maxwell,
yes, your are right it must be that easy...
I used the wrong format
sprintf (str, "%s", *bstr);
which just resulted in the first character of ther bstr..
correct is
sprintf (str, "%S", *bstr);
Your answer made me sure to look further at the point where I was before.
Thanks
Dirk
|
|
|
|
|
Hi All,
The blocks of code shown below basically do the same thing...
CTest1 c ;<br />
c.Hello() ;
CTest1 *t ;<br />
t = new CTest1() ;<br />
t->Hello() ;<br />
delete t ;<br />
t = NULL ;
They call the Hello() function in CTest1.
My Question is, when should we use them?
What is the advantage of one over the other?
Are there specific instances where one is preferred over the other?
Thanks...
---
With best regards,
A Manchester United Fan
The Genius of a true fool is that he can mess up a foolproof plan!
|
|
|
|
|
In general, dynamic creations of classes (with new and delete) are used in polymorphism (you have a pointer to a base class and you 'create' a pointer to a child class):
CBaseClass
{
};
CChildClass : public CBaseClass
{
};
CBaseClass* pNewClass = new CChildClass;
It is a little bit complicated to explain in details what are the advantages but in brief, it lets you have several pointers to different child classes being used in the same way (as a pointer to the base clase). This is impossible to do without pointers (except by using references but this is another subject )
|
|
|
|
|
This is not a reason to use or not use new - You can still treat a object on the stack polymorphically. For example the following does:
class Base
{
public:
virtual void Message() const = 0;
};
class Derived1
{
public:
virtual void Message() const
{
cout << "Hello from Derived1" << endl;
}
};
class Derived2
{
public:
virtual void Message() const
{
cout << "Hello from Derived2" << endl;
}
};
void PrintMessage(const Base &b)
{
b.Message();
}
void Driver()
{
CDerived1 d1;
CDerived2 d2;
PrintMessage(d1);
PrintMessage(d2);
}
In this example PrintMessage exhibits polymorphic behaviour but there are no new s.
Steve
|
|
|
|
|
TechyMaila wrote: CTest1 c ;
c.Hello() ;
With this technique the object is on the stack. If the object is very large you might not want to put it on the stack - However it is fairly rare for an object to be so big that it comes into the decision process. The main reason you use new to create an object is when you want to control its life time explicitly. For example, if you have an object on the stack and use it like this you're in for problems:
CTest1& Voodoo()
{
CTest1 c;
return c;
}
This is because the object c is destroyed when its scope is exited; in this case when we exit the function the object is destroyed and no longer exists. Thus returning a reference to it is a disastrous mistake.
If you recode the example like this however there is no such problem but you are now responsible for controlling to object's life time:
CTest1* Voodoo()
{
CTest1 *pObject = new CTest1;
return pObject;
}
The programmer must remeber to call delete on the object returned!
Steve
|
|
|
|
|
Thanks a lot for your answers.
So what you are saying is that it is better to use new and delete ? Thanks.
---
With best regards,
A Manchester United Fan
The Genius of a true fool is that he can mess up a foolproof plan!
|
|
|
|
|
TechyMaila wrote: So what you are saying is that it is better to use new and delete? Thanks.
No, I'm not saying that. Here's what I'd say: "Use objects on the stack if you can and new and delete if you have to". It is more efficient (in general) to have objects on the stack; but less flexible. Also if you new an object but forget to delete it you'll leak memory: it's more error prone. In short it depends, for the most part, on the life time requirements of the object.
Steve
|
|
|
|
|
|
In addition to their answers, here is the 3rd reason.
When you declare an object as the data member, you have to include the .H file of the implementation. As:
#include "bar.h"
class foo
{
bar _MyBar;
}; Any changes to the implementation of class bar will cause class foo to be re-compiled again. This is nothing in small projects, but it is quite annoying in large projects. (The case you click [Build] button, you go out to buy a cup of coffee, and you go back 10 minutes later... You see it is still compiling.)
So we would take this way as:
class bar;
class foo
{
bar* _pMyBar;
};
Maxwell Chen
-- modified at 10:24 Saturday 6th May, 2006
|
|
|
|
|
To new , or not to new : that is the question. While your answer is correct I think the question was about the pros and cons of using new vs putting an object on the stack.
Steve
|
|
|
|
|
You should avoid using leading underscores in your code, because it makes it non-portable.
IAW C++ standard, names with leading underscore, are reserved for the implementation.
If you need to use an underscore, use a trialing underscore instead.
----------------------------------------------------------------------------------------
David Maisonave
http://axter.com
Author of Axter's policy based smart pointers
(http://axter.com/smartptr)
|
|
|
|
|
|
Axter wrote: should avoid using leading underscores in your code, because it makes it non-portable.
Please read the language standard specification, ISO/IEC 14882:2003.
The well known non-portable one is '$'.
Axter wrote: a trialing underscore
Huh?
Maxwell Chen
|
|
|
|
|
Is that where all the leading underscores are coming from????
I've been wondering why I've been seeing them more and more lately.
For the record: regarding ANSI specifications, ANSI.org and places like that. I'll be damned if i'm going to pay $291 so I can download a 2MB file of instructions telling me how I'm supposed to name my variables.
If I feel like using m_blahblah...or mixedUpperLower...or lower local and Upper global or whatever then tough.
I've been listening to this grand promise of making code portable for over 20 years now and I've lost count of how many times I've been told we're all doing it wrong.
At least 5 times I've changed to suit some imaginary standard and guess what? As soon as the next new compiler comes out we're told we aren't doing it right and we spend countless hours converting our supposed "portable" code anyway.
If you want to run along with ISO/IEC whatever, more power to you. Have fun and why not? There's nothing wrong with guidelines and doing things consistently (more to make everything readable than anything).
I'll make you a bet that within the next 5 years you'll be programming in a completely different environment, there's a new way and leading underscores are suddenly wrong. I have history on my side.
|
|
|
|