|
Use the project wizard to create a WTL SDI or MDI application. Accept the default settings and it will create a command bar for you.
|
|
|
|
|
Hi.
How do you know if find() returns a valid element in a map that is inside a map? For example:
-----
typedef std::map<<int, int="">> mapIntInt;
typedef std::map<<double, mapintint="">> mapDM;
mapIntInt mapOne;
mapOne.insert(std::pair<<int, int="">>(0, 1));
mapDM mapTwo;
mapTwo.insert(std::pair<<double, mapintint="">>(8.9, mapOne));
// Now I want to search mapOne, but first I need to search mapTwo for mapOne.
if (twoIterator != mapTwo.end())
{
oneIterator = twoIterator->second.find(8.9);
// How do you check if oneIterator points to a valid element?
}
-----
Given the example above, how do you know what if the search in the second map container (map inside of map) points to a valid element?
Thanks,
Kuphryn
|
|
|
|
|
if(oneIterator!=twoIterator->second.end()){...}
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
|
How to output string into a file? My part of code is belowLook at the last line, it is not ok.)
// Open the file ready write
if((pOutputFileStream = fopen(csFilePath, "w")) != NULL)
bStatus = TRUE;
// Otherwise output message to the console window.
else
{
printf("The output %s file is not available!", csFilePath);
bStatus = FALSE;
}
if (bStatus)
{
// STL string.
string str = vNode.back ();
cout << str << endl;
//
// this line is not ok.
//
fprintf(pOutputFileStream, "%s", str.substr);
}
Thanks.
mIchAel Liu
__________________________________________________________
The secret of business is to know something that nobody else knows. 
|
|
|
|
|
You're using C++ to output to the console, and C to output to the file. Use iostreams instead.
#include <iostream>
#include <fstream>
#include <string>
using std::string;
using std::ofstream;
...
string s("This is a test of the veracity of my system");
ofstream op("c:\\test.txt");
op << s;
// can call op.close(), but the destructor does it anyhow.
Christian
No offense, but I don't really want to encourage the creation of another VB developer. - Larry Antram 22 Oct 2002
Hey, at least Logo had, at it's inception, a mechanical turtle. VB has always lacked even that... - Shog9 04-09-2002
During last 10 years, with invention of VB and similar programming environments, every ill-educated moron became able to develop software. - Alex E. - 12-Sept-2002
|
|
|
|
|
Hello,
My projects doesn't seem to be using MFC, although I made a redist. of my project and I get an error on MSVCR70.dll
In my project settings, in: Use Of MFC, I have: Use Standard Windows Librairies.
Why do I have a dependency on MFC anyways???
Thanks!
---------------
Concentrating on Ideas
http://www.edovia.com
|
|
|
|
|
Um, MSVCR70 isn't MFC, it is part of the C runtime library. If you want to get rid of that, build the project using static libraries and not dynamic.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
Where do I set that? In: Use of ATL I have: Static link to ATL already...
Thanks!
EDIT: I think I found it... it's in Minimise CRT use in ATL...
---------------
Concentrating on Ideas
http://www.edovia.com
|
|
|
|
|
Minimize CRT use in ATL
Do I set it to Yes or No? If I set it to Yes, I get soooo many errors when I compile/link the project!!!
---------------
Concentrating on Ideas
http://www.edovia.com
|
|
|
|
|
Project Properties:
C/C++:
Runtime Library:
Either set to "single threaded" or "multi threaded" (with or without debug). If you use "multi threaded DLL", it will using the CRT DLLs.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
My main problem is how do I pass a pointer of my connection object to the childviews, where the pointer is a public member of my childframe.
Is there some way from my view that I could get a reference of the parent childframe?
Can somebody please help me.
|
|
|
|
|
Send the pointer via message.
Kuphryn
|
|
|
|
|
So you think every body is like you
|
|
|
|
|
I have read the threads on this site and searched google for information on using an stl map (and set) class in a DLL. I am not sure that what I want to do can be done or is safe. Here is the situation:
I have 2 classes:
#ifdef USING_FROM_EXE
#define EXPORT_OR_IMPORT_CLASS _declspec(dllimport)
#else
#define EXPORT_OR_IMPORT_CLASS _declspec(dllexport)
#endif
class EXPORT_OR_IMPORT_CLASS CMyClass
{
protected:
std::map<DWORD, CMyOtherClass> SomeMember;
std::set<CMyOtherClass> SomeOtherMember;
};
class EXPORT_OR_IMPORT_CLASS CMyOtherClass
{
bla.bla.bla
}
There are methods of the CMyClass class for adding/removing/finding items in the map and set which are not returing the map or iterators, just results.
When I compile the code I get a compiler warning
<pre>
warning C4251: bla.bla.bla needs to have dll-interface to be used by clients of class 'CMyClass'
</pre>
I have downloaded the XTree header file from the dinkumware web site and rebuilt the project, but I still get this error. (I am currently exporting a vector and a list of other object types using the MSDN recommended method.) If I add export lines to the code, I get a new warning C4251.
Is it possible to export a STL set or a map from a DLL in the way which I am attempting? If so, what is the recommended way of doing it? If not, is there another way to acheive what I want? If no, what good is STL if you can't use it in a DLL safely?
Thanks,
Matt Gullett
|
|
|
|
|
I do not think that it is a good idea to export STL objects from a DLL. You may run into memory allocation/deallocation and threading problems.
Drinking In The Sun
Forgot Password?
|
|
|
|
|
Thanks for the reply, but what do you base this on. I have reviewed the "limited" info on MSDN and it seems that you are right, BUT if I can't have objects in my DLLs exported because they use STL, then STL is a HUGE waste of time.
I mean, if I can't take a utility class that uses STL from a console app (or any other EXE for that matter) and put it in a DLL so it can be reused by other apps, what good is STL to me?
Someone please tell me this is not the case.
|
|
|
|
|
There are known problems with std::map. It uses a local static structure to mark nodes. The DLL might have one copy while the EXE will have another. This can cause problems when std::map tries to detect certain conditions based on if a pointer references this static structure.
Templates that don't use static structures or variables should have little problem being exported.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
You can make a thin class wrapper over your class which contains the maps and export the class wrapper instead. The class wrapper will new an instance of your class in its constructor and delete it in the destructor. In this way you can hide the implementation details which are exposed in the header file of your actual clas.
Drinking In The Sun
Forgot Password?
|
|
|
|
|
I have used stl map and set across dlls successfully.
My compiler says on warning C4251:
'class' : multiple copy constructors specified
The class has multiple copy constructors of a single type. The first constructor is used.
I am confused on what your really problem is!
Best regards,
Alexandru Savescu
|
|
|
|
|
According to the MSDN July 2001 (??). If it matters, I am using Visual Studio 6 with SP5.
Compiler Warning (level 1) C4251
'identifier' : class 'type' needs to have dll-interface to be used by clients of class 'type2'
The specified base class was not declared with the __declspec(dllexport) keyword.
A base class or structure must be declared with the __declspec(dllexport) keyword if a function in a derived class is to be exported.
|
|
|
|
|
Yes, you are right, I was looking on C:4521
Do you export the classes that the map contains also?
Best regards,
Alexandru Savescu
|
|
|
|
|
|
Another method besides Joaquin suggestion is to utilize the pimpl idiom as mentioned by Herb Sutter (http://gotw.ca[^]) (I believe it's called a compiler firewall in terms of design patterns).
Basically the pimpl (pimpl = pointer to implementation) idiom separates the implementation details from the interface definition.
Look at this class for instance:
class TheClass {
int member;
public:
void DoSomething();
};
All that the clients can do is call DoSomething(). Clients can't touch member, but it can still observe it. This means that all changes to the private parts of the class is visible to all clients - thus you'd have to recompile all depending cpp files.
The pimpl idiom eliminates this by putting the implementation details in the cpp file rather than in the h file.
Example:
struct Impl;
class TheClass {
std::auto_ptr<Impl> pimpl;
public:
TheClass();
void DoSomething();
};and
struct Impl {
int member;
};
TheClass::TheClass() : pimpl(new Impl) { }
void TheClass::DoSomething() { manipulate(pimpl->member); }
Now you can change anything in your implementation details without the clients noticing it.
From this, it's obvious that you should put the STL-containers in the Impl-struct, thus saving yourself some export-problems.
It's a little bit more typing, but it's a clean way to separate interface from implementation - a very big plus in HUGE projects. (Picture the happy faces on 20 programmers in a project after you've fiddle with the private parts of a common class which many source files depend on.. )
--
standing so tall, the ground behind
no trespassers, on every floor
a garden swing, and another door
she makes it clear, that everything is hers
A place of abode, not far from here, Ms. Van de Veer
|
|
|
|
|
Sort of generic solution to COM.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
