ATL / WTL / STL

20-Sep-06 22:52

Hi.

I have a WTL 7.5 app created in VS2005 on XP.

In the app I was intending to make use of various STL containers. I began by entering:

using namespace std;

just under my header declarations, BOOM!
I instantly got 11 errors, 5 pairs of:

error C2006: '#using' : expected a filename, found 'namespace'
fatal error C1190: managed targeted code requires a '/clr' option WTF | :WTF:

and 1:

BSCMAKE: error BK1506 : cannot open file '.\Debug\DispInterface.sbr': No such file or directory.

I've rummaged around my settings and could see nothing that cause this (though obviously, I expect I'm missing something). Anyway, I continued with the app as I could use std:: to use the containers I wanted, only to find when I called push_back on a vector I got a heap corruption (C0000005).

I can only presume these are connected as I understand neither.

Any insights would be greatly appreciated

Thanks

Tom

Rob Caldecott20-Sep-06 23:09

Rob Caldecott

20-Sep-06 23:09

Weird - it seems to be parsing using as #using!

How about using the std namespace qualifier directly, e.g.:

std::string str = "Test";

Does this work OK?

FWIW I use the STL with all my WTL/ATL apps with no issues, however, I avoid using namespace .... I prefer to specify the namespace directly.

Should I use using namespace std in my code?[^]

Kicking squealing Gucci little piggy.

Stuart Dootson21-Sep-06 1:03

Stuart Dootson

21-Sep-06 1:03

Rob Caldecott wrote:
I avoid using namespace

And me - the only namespace I use is boost::lambda, and then only in the smallest scope I can find.

Stuart Dootson20-Sep-06 23:11

Stuart Dootson

20-Sep-06 23:11

TClarke wrote:
#using

'#using' - sure there's not a rogue '#' in there?

Also - I've used STL and WTL together with *no* problems, so I'd suggest it isn't going to be that...

TClarke20-Sep-06 23:30

20-Sep-06 23:30

Firstly, thanks for the speedy responses Smile | :)

there's certainly no rogue '#' in there, the file begins as follows:

<br />
<br />
#pragma once<br />
#include "idlobject.h"<br />
#include "IDLMethod.h"<br />
#include "IDLProperty.h"<br />
<br />
#using namespace std;<br />
<br />
class CDispInterface :<br />
	public CIDLObject<br />
{<br />
<br />

std::string test = "Test";
Worked fine, but:

std::vector< CIdlMethod* > m_vMethods;<br />
CIdlMethod* pMethod = new CIdlMethod(); <br />
m_vMethods.push_back( pMethod );

fails with a heap corruption Confused | :confused:

PS. thanks for the link to that FAQ page.

Tom

Stuart Dootson21-Sep-06 1:02

Stuart Dootson

21-Sep-06 1:02

TClarke wrote:
#using namespace std;

Ummmm - it should be using namespace std;, not #using namespace std; - that's what I meant by a rogue #. C++ namespaces are used with a plain using. #using pulls in a .NET assembly[^].

TClarke21-Sep-06 3:12

21-Sep-06 3:12

Ah Ha!

Goodness knows where I got that from Blush | :O

Thanks Stuart

prasad_som20-Sep-06 23:12

prasad_som

20-Sep-06 23:12

TClarke wrote:
fatal error C1190: managed targeted code requires a '/clr' option

This requires setting property "common language runtime support".
You can do it by setting project properties-->Genearal-->Project Defaults--> common language runtime support-->common language runtime support

TClarke wrote:
error C2006: '#using' : expected a filename, found 'namespace'

Not sure about this one, but may be this[^] helps you.

Prasad
Notifier using ATL | Operator new[],delete[][^]

TClarke20-Sep-06 23:47

std::string in unicode builds

20-Sep-06 23:47

It's bizare that the comiler is looking for CLR support when I'm not using anything I'm aware has even a whiff of a connection to it.

When I set the /clr property It just ran into the '/MTd' property and compiling ceased. Since I rely heavily on threads in this app that's kind checkmate as far as 'using namespace std;' is concerned. Sigh | :sigh:

thanks to an article I got pointed to by an earlier comment I'm now resolved to using std:: anyway. Now I just have to figure out what's going on with my std::vector

Thanks

Tom

rana7420-Sep-06 19:56

rana74

20-Sep-06 19:56

Let us take a simple function
::MessageBox(0,data.c_str(),"log",0);
where data is a std::sting type.

When i change the build type to unicode ,this will spit out error
error C2664: 'MessageBoxW' : cannot convert parameter 2 from 'const char *' to 'LPCWSTR'

How can i feed in the underlying data of a std::string type(const char *),so that it builds smoothly in both MBCS and UNICODe builds.

Re: std::string in unicode builds [modified]

Rob Caldecott20-Sep-06 20:31

Rob Caldecott

20-Sep-06 20:31

typedef std::basic_string<TCHAR> tstring;
...
tstring str = _T("Hello, World!");
::MessageBox(NULL, str.c_str(), _T("Test"), 0);

The above will work in both MBCS and Unicode builds.

Or see here[^].

FWIW I always use std::wstring and build for Unicode and for Win9x support I link with the MS unicows library.

Last modified: 2hrs 12mins after originally posted --

Kicking squealing Gucci little piggy.

Jörgen Sigvardsson21-Sep-06 9:46

Jörgen Sigvardsson

21-Sep-06 9:46

Rob Caldecott wrote:
FWIW I always use std::wstring and build for Unicode and for Win9x support I link with the MS unicows library.

Smart choice, as going from ANSI -> UNICODE is a pain in the ass. I just wish all platforms and libraries used the same Unicode encoding scheme. I recently tried to do Unicode for different platforms. P.I.T.A! Windows uses UCS2/UTF-16 internally, while on Unix you use either UTF-8 (char) or UTF-32 (wchar_t). Dear god in heaven, that amounts to a huge frickin layer of string crap.

--
Mr. Bender's Wardrobe by ROBOTANY 500

George L. Jackson21-Sep-06 15:23

George L. Jackson

21-Sep-06 15:23

You are mixing two types and the literal string is the problem:

data.c_str() is UNICODE, and "log" is not under a UNICODE build. Change "log" to L"log".

::MessageBox(0, data.c_str(), L"log", 0);

Steve S21-Sep-06 22:11

Steve S

21-Sep-06 22:11

Better would be to use the TCHAR include (tchar.h) and to have literals with _T()
such as _T("log"). That way, it builds as ANSI string for ANSI/MBCS, and as wide string for UNICODE.

The original point was about parameter#2, which was the std::string's c_str() function, and the first reply sorted out that problem. Literal strings are another...

Given that MS no longer offer support for Win9x, I've taken the decision to produce only UNICODE binaries now. Of course, most of the code I've been writing for years (since W2K was released) has been compilable for both anyway...

Steve S
Developer for hire