|
the content of manifest file is linked to executabe by linker or must be distributed into the same folder where the app's executable is running from?
|
|
|
|
|
tibiz wrote: the content of manifest file is linked to executabe by linker or must be distributed into the same folder where the app's executable is running from?
Since, you are using VS2003, the manifest file can be linked to the executable.modified on Wednesday, March 10, 2010 12:19 AM
|
|
|
|
|
I have Dev-c++ version 4.9.9.2 on my computer. When I try to compile anything, it gives me the same error.
<br />
Makefile.win [Build Error] [main.o] Error -1073741515 <br />
I have two different copies of the program on my computer; one that is installed and a portable one and they both give me the same error. I know that it isn't my code because i use the portable one to compile code at school and it works fine there. In advance, thank you for your help.
Here is the compile log I got from trying to compile on the portable version:
<br />
Compiler: Default compiler<br />
Building Makefile: "J:\opengl\Makefile.win"<br />
Executing make...<br />
make.exe -f "J:\opengl\Makefile.win" all<br />
g++.exe -c main.cpp -o main.o -I"J:/Portables/Dev-CppPortable/App/devcpp/lib/gcc/mingw32/3.4.2/include" -I"J:/Portables/Dev-CppPortable/App/devcpp/include/c++/3.4.2/backward" -I"J:/Portables/Dev-CppPortable/App/devcpp/include/c++/3.4.2/mingw32" -I"J:/Portables/Dev-CppPortable/App/devcpp/include/c++/3.4.2" -I"J:/Portables/Dev-CppPortable/App/devcpp/include" <br />
<br />
make.exe: *** [main.o] Error -1073741515<br />
<br />
Execution terminated <br />
|
|
|
|
|
A wild guess: you have a problem with your PATH, the build tools aren't able to locate a DLL file they need, such as e.g. mspdb80.dll (and are not smart enough to provide a descent error message).
|
|
|
|
|
I have had this same issue in the past and I agree with ^ him, I would suggest dloading Microsoft Office C++ Express Edition 2008, you will have a more compatibility and the file size is very small.
|
|
|
|
|
I have a class and a constructor taking a reference argument. I will use this argument to initialize a reference class member:
CMyClass::CMyClass(MyType& MyArg)
: class_member(MyArg)
{//...}
Ok, that's fine but there's a problem. Even though I don't need a default constructor, the compiler requires one. I must initialize the class_member reference in the initializer list. Because there are no arguments, I don't have a valid argument to make an initialization. NULL is not accepted by the compiler as a repacement. I wonder if there is a workaround.
I'm aware I can replace the reference with a pointer and eliminate the need to make the initialization in the initializer list, but I'm curious if there is any way to have a default constructor under the given conditions ?
|
|
|
|
|
No. References are immutable once set, and have to be set on initialisation. Although…you could use a reference wrapper class like boost::ref[^].
CString(0xcccccccc) wrote: Even though I don't need a default constructor, the compiler requires one
Ummm - I might be slitting hairs here, but it's some library that requires the default constructor, not the compiler per se.Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
CodeProject MVP for 2010 - who'd'a thunk it!
|
|
|
|
|
Declare a private default constructor, but don't define it.
class CMyClass {
private:
MyType& ref_member;
CMyClass();
};
|
|
|
|
|
If a default constructor is required (by a library, as Stuart pointed out), then probably a private one won't be accepted. 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
[My articles]
|
|
|
|
|
And if it requires it because it is actually going to use it and you don't define it, I smell an unresolved external coming.  You measure democracy by the freedom it gives its dissidents, not the freedom it gives its assimilated conformists.
|
|
|
|
|
True, but if it's just the compiler complaining because it can't create one then this should solve it. Though I suppose that's more likely with the copy constructor and operator= than the default constructor.
|
|
|
|
|
Graham Breach wrote: Though I suppose that's more likely with the copy constructor and operator= than the default constructor.
Good guess: usually the default constructor is required by serialization classes. 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
[My articles]
|
|
|
|
|
CPallini wrote: Good guess
From "Midway":
Captain Garth: Ten percent? That's one word in ten, Joe! You're guessing!
Commander Rochefort: [slightly hurt] We like to call it "analysis."You measure democracy by the freedom it gives its dissidents, not the freedom it gives its assimilated conformists.
|
|
|
|
|
error C2248: 'CMyOb::CMyOb' : cannot access private member declared in class 'CMyOb'
I failed to mention that, (supposing it's not important) my class is derived from the CObject MFC class.
Thanks for trying to help me.
|
|
|
|
|
CString(0xcccccccc) wrote: I don't need a default constructor, the compiler requires one.
Actually, the compiler should not require one, unless something in your code (like a library as Stuart Dootson suggested) is triggering the compiler to use one. If you are getting errors due to its absence, that means that it is getting used. You either need to track down those locations and change them so that the default constructor is not used or make your class default constructable.
If you declare a private default constructor but do not provide an implementation for it (as Graham Breach suggested), it should make most of those situations compiler rather than linker errors. This should make it easier to locate them.Please do not read this signature.
modified on Monday, March 8, 2010 3:40 PM
|
|
|
|
|
Thanks. My class is derived from CObject (MFC). At this time I just started writing the class code, there is not even a single instantiation of the class anywhere in my application.
|
|
|
|
|
| Hmmm. Are you perhaps using DECLARE_DYNCREATE or DECLARE_SERIAL ? Please do not read this signature.
|
|
|
|
|
Here it is the whole header file:
#pragma once
#include "atltypes.h"
#include "MyObArray.h"
// CMyOb command target
class CMyOb : public CObject
{
private:
CMyOb();
public:
CMyOb(CMyObArray& arr, CMyOb& par, CPoint pos);
virtual ~CMyOb();
CMyOb& parent;
CPoint position;
int distDone;
int distToGo;
CMyObArray& myArray;
};
Here it is the whole cpp file:
// MyOb.cpp : implementation file
//
#include "stdafx.h"
#include "Test551.h"
#include "MyOb.h"
// CMyOb
CMyOb::CMyOb(CMyObArray arr, CMyOb& par, CPoint pos)
: myArray(arr)
, parent(par)
, position(pos)
, distDone(0)
, distToGo(0)
{
}
CMyOb::~CMyOb()
{
}
// CMyOb member functions
That's all. The rest of the code isn't in any way connected to this code (there's not even an include directive for the header file other than in this cpp).
Actually I want to implement the "A star" pathfinding algorithm and I need this class for informations about a partcular cell on the map. I'm aware that there are lots of different options for implementation, it's not about being stucked. But while I work, I also want to learn.
|
|
|
|
|
Obviously, my idea about DECLARE_DYNCREATE was wrong.
What is CMyObArray?
Also, you seem to have omitted an &:
CMyOb::CMyOb(CMyObArray &arr, CMyOb& par, CPoint pos)
CMyObArray is the only thing that looks like a candidate for your symptom to me.
I'm also curious how you are planning to get a parent for your first CMyOb.Please do not read this signature.
|
|
|
|
|
The & symbol was lost during the copy/paste operation. Something (VS, the clipboard, the web page edit control) replaced all occurences of that symbol with "amp &" so I was forced to edit the copied code. I deleted the symbol by accident, sorry. It's missing only from the message, not from the code.
CMyObArray it's a class derived from CObArray MFC class. I use it for it's ease to add/remove array elements. In the end it will be more than an array of objects, it will also hold all relevant info about the map (like the position of starting and ending cell, a pointer to an array describing the map, a function to retrieve minimal the object with the minimal distance and so on.) At this time it's only a minimal scratch.
The header file is:
#pragma once
#include "atltypes.h"
// CMyObArray command target
class CMyObArray : public CObArray
{
public:
CMyObArray();
virtual ~CMyObArray();
CPoint cellBegin;
CPoint cellEnd;
};
The cpp file is:
// MyObArray.cpp : implementation file
//
#include "stdafx.h"
#include "Test551.h"
#include "MyObArray.h"
// CMyObArray
CMyObArray::CMyObArray()
: cellBegin(0)
, cellEnd(0)
{
}
CMyObArray::~CMyObArray()
{
}
// CMyObArray member functions
For he first parent I can pass any CObject casted to CMyOb. It doesn't matter if some class members will be incorrect as long as I only use it as a marker for the end of the path in searching.
Now you know all about that problem to test it on your own computer. I used the VS 2008 full version in a dialog based project. Apart form the ccode I posted, there's nothing else in the project except what VS automatically generated.
|
|
|
|
|
I found a solution by declaring the necessary objects for initialization at global scope. Here it how the MyOb.cpp file looks:
// MyOb.cpp : implementation file
//
#include "stdafx.h"
#include "Test551.h"
#include "MyOb.h"
// CMyOb
CMyObArray a;
CMyOb* pB = NULL;
CMyOb::CMyOb()
: myArray(a)
, parent(*pB)
{
}
CMyOb::CMyOb(CMyObArray& arr, CMyOb& par, CPoint pos)
: myArray(arr)
, parent(par)
, position(pos)
, distDone(0)
, distToGo(0)
{
}
CMyOb::~CMyOb()
{
}
// CMyOb member functions
Obviously, the pB pointer id invalid, it's only purpose is to trick the compiler. It's not supposed to be used in any way.
Frankly, it's a sh**, i'll use a structure instead of the class CMyOb.
|
|
|
|
|
I think I got the madness of creating my first MFC Dll figured out.
Now for the proverbial $64 question.
The DLL is being developed concurently with the main program as dependant of the main program. The OS looks for it in many places execept in the current DLL Debug directory!
I was thinking I could use Post / Pre link in Project Setting to copy the DLL to some OS accessible place - OS/System32 for example.
I do not know how to do this.
Any other idea, preferably simpler, how to do this would be nice.
Any constructive help as allways is appreciated.
Vaclav
-- Modified Monday, March 8, 2010 1:48 PM
|
|
|
|
|
10 develop
20 update the DLL
30 GOTO 10
|
|
|
|
|
Sir, we need a break (or a ![Beer | [beer]](https://www.codeproject.com/script/Forums/Images/beer.gif) ) somewhere...  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
[My articles]
|
|
|
|
|
I thought that using GOTO is immoral.
I think you answered before I typed my message.
It got posted empty first!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
