|
Wellness Wednesday? 
|
|
|
|
|
I got an application MFC and openGL are used. When I run the application it should load a 3D graphics model. But my tool bar, menu bar everything is coming properly but the 3D model window with the model is not appearing. There is no error or no dll problem. Everything linked propely. Why the 3D model is not coming. Please help me someone. Thanks Sujan
Please check this link for the screen shot
https://www.dropbox.com/sh/5thffcacwx7ye6u/i_mmqIgerU?m[^]
|
|
|
|
|
Is there any chance you have tried to debug this application? 
Chris Meech
I am Canadian. [heard in a local bar]
In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
posting about Crystal Reports here is like discussing gay marriage on a catholic church’s website.[Nishant Sivakumar]
|
|
|
|
|
Could it be happened becasue of graphics card. May be the graphics card is not supporting the 3D model or it is not sufficient. Because in some systems it is working fine.
|
|
|
|
|
The question posted by Chris is asking whether you have used your debugger to try and find out what is happening in your program. From the information you have provided (including that picture) we have nothing that would give any clues.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
i tried using debugger. All calls are fine. I am passing the 3D model's file name to the function draw() and then its being called. But nothing is drawn on the screen. pls help.
|
|
|
|
|
I'm sorry but we cannot begin to guess what is happening in your program. You need to find out what is happening in your drawing function and whether it is reading the file and processing its content correctly.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
I have built a unit tester in C++. Compiles and runs under VS and linux (Ubuntu 10). (I know, there are others out there. Spare time project of mine over the years)
I just finished the port to Linux. However, if I throw an exception anywhere, within the shared object that contains the test case it will signal SIGABRT. All my searching has not revealed an answer. I figure there is something messed up in the compile switches.
I reduced it to a very simple occurence
void UTL_STR_RTRIM_1() {
try {
int x = 99;
throw x;
}
catch (int i) {
mr_cout << L("Caught int within test case ") << i << std::endl;
}
catch (...) {
mr_cout << L("Caught ... within test case ") << std::endl;
}
TEST_EQUAL(this, mr_utils::mr_string(L("This is a str")), mr_utils::TrimRight(L("This is a str \t\n\r\0")));
}
So even, throwing and catching and int (tried it with other types and exceptions) will cause SIGABRT
Here is my make file for the shared object that is loaded (with above code) followed by makefile of executable that loads the shared object of test cases. Any ideas?
#
# 'make depend' uses makedepend to automatically generate dependencies
# (dependencies are added to end of Makefile)
# 'make' build static lib 'libutils.a'
# 'make clean' removes all .o and static lib files
#
# define the C compiler to use
CC = gcc
# define any compile-time flags
CFLAGS = -c
CFLAGS = -g
CFLAGS += -fPIC
CFLAGS += -fno-stack-protector
# define any directories containing header files other than /usr/include
INCLUDES =-Iinclude
INCLUDES +=-ICppTestCaseTests
INCLUDES +=-I../CppTestUtils/include
INCLUDES +=-I../CppTest/include
#INCLUDES +=-ICore/include
#INCLUDES +=-IDlls/include
#INCLUDES +=-IExceptions/include
#INCLUDES +=-IFactories/include
#INCLUDES +=-ILogging/include
#INCLUDES +=-IOutputs/include
#INCLUDES +=-IScriptReader/include
# define library paths in addition to /usr/lib
# specify path using -Lpath, something like:
#LFLAGS = -L/home/newhall/lib -L../lib
# define the CPP source files
SRCS = \
source/dllmain.cpp \
# define the CPP object files
#
# This uses Suffix Replacement within a macro:
# $(name:string1=string2)
# For each word in 'name' replace 'string1' with 'string2'
# Below we are replacing the suffix .cpp of all words in the macro SRCS
# with the .o suffix
OBJS = $(SRCS:.cpp=.o)
# folder for lib file.
LIBDIR = lib
# define the shared object file
UTILLIB = $(LIBDIR)/libmr_testTestCases.so
DEFINES+=-DMR_USE_WIDE_STR
DEFINES+=-DDEBUG
# User defined function for compile to make for each compact.
do-compile=$(CC) $(DEFINES) $(CFLAGS) $(INCLUDES) -c $1.cpp -o $1.o > stderr
#do-compile=$(CC) $(DEFINES) $(CFLAGS) $(INCLUDES) -c $1.cpp -o $1.o > stderr
# The following part of the makefile is generic; it can be used to
# build any static lib just by changing the definitions above and by
# deleting dependencies appended to the file from 'make depend'
.PHONY: depend clean
all: $(UTILLIB)
@echo Simple compiler named libmrtest.so has been compiled
# rule to archive all of the object files into the static lib
# chains to the OBJS macro which calls the .cpp.o to do the compilation first.
# For some reason gcc does not send out text to stdout of stderr. Must echo
# it
$(UTILLIB): $(SRCS)
mkdir -p $(LIBDIR)
@echo ------------------------------------------------------------
@echo Compiling object files.
$(foreach i,$(SRCS:.cpp=),$(shell $(call do-compile,$i) ))
@echo ------------------------------------------------------------
#@echo ------------------------------------------------------------
#@echo Creating lib
#$(AR) $(ARFLAGS) $@ $(OBJS)
#@echo ------------------------------------------------------------
@echo ------------------------------------------------------------
@echo Creating Shared Object
ld -shared -soname $@ -o $@ $(OBJS)
# $(CC) -shared -W1,-soname $@ -o $@ -fPIC $(SRCS)
# ld -shared -init __nonWinCutTestCaseRegistrationMethod__ -soname $@ -o $@ $(OBJS)
# $(CC) -Wall -shared -fPIC -W1,soname $@ -o $@ $(INCLUDES) $(SRCS)
# $(CC) -shared -W1,-soname,$@ -o $@ $(OBJS)
# $(CC) -Wall -shared -fPIC -W1,-soname,$@ -o $@ $(OBJS)
#this one may actually call the attr constructor on dll. but undefined symbols found
# $(CC) -Wall -shared -fPIC -o $@ $(INCLUDES) $(SRCS)
@echo ------------------------------------------------------------
# ld -shared -soname $@ -o $@ /usr/lib/gcc/i686-linux-gnu/4.6.3/libgcc_s.so -lc -fno-stack-protector $(OBJS)
# ld -shared -fno-stack-protector -soname $@ -o $@ $(OBJS)
#ld -shared -lc -fno-stack-protector -soname $@ -o $@ $(OBJS)
# TODO - lookup what the no-stack-protector might be doing
# this is a suffix replacement rule for building .o's from .cpp's
# it uses automatic variables $<: the name of the prerequisite of
# the rule(a .cpp file) and $@: the name of the target of the rule (a .o file)
# (see the gnu make manual section about automatic variables)
#.cpp.o:
# $(CC) $(CFLAGS) $(INCLUDES) -c $< -o $@
clean:
@echo ------------------------------------------------------------
@echo Cleaning House
@echo ------------------------------------------------------------
$(RM) $(UTILLIB)
$(RM) $(OBJS)
depend: $(SRCS)
makedepend $(INCLUDES) $^
# DO NOT DELETE THIS LINE -- make depend needs it
Executable make file
#
# 'make depend' uses makedepend to automatically generate dependencies
# (dependencies are added to end of Makefile)
# 'make' build static lib 'libutils.a'
# 'make clean' removes all .o and static lib files
#
# define the C compiler to use
CC = gcc
# define any compile-time flags
CFLAGS = -c
CFLAGS = -g
CFLAGS += -fPIC
CFLAGS += -fno-stack-protector
# define any directories containing header files other than /usr/include
INCLUDES +=-I../CppTestUtils/include
INCLUDES +=-I../CppTest/include
INCLUDES +=-I../CppTest/Core/include
# define library paths in addition to /usr/lib
# specify path using -Lpath, something like:
#LFLAGS = -L/home/newhall/lib -L../lib
# define the CPP source files
SRCS = \
source/CppTestDevConsole.cpp \
# define the CPP object files
#
# This uses Suffix Replacement within a macro:
# $(name:string1=string2)
# For each word in 'name' replace 'string1' with 'string2'
# Below we are replacing the suffix .cpp of all words in the macro SRCS
# with the .o suffix
OBJS = $(SRCS:.cpp=.o)
# folder for lib file.
LIBDIR = lib
# define the shared object file
UTILLIB = $(LIBDIR)/cutConsoleRunner
# the libs from the other Cut so
#LIBS+=-lstdc++
#LIBS+=-lcut_utils
#LIBS+=-ldl
#LIBS+=-lcut_test
LIBS+=-lcut_test
LIBS+=-lcut_utils
LIBS+=-ldl
LIBS+=-lstdc++
#until I can get groups and rights setup
#LIBDIRS+=-L/home/michael/opt/cut_test/lib
#LIBDIRS+=-L/usr/lib/gcc/i686-linux-gnu/4.6.3
LIBDIRS+=-L/usr/lib/gcc/i686-linux-gnu/4.6.3/
LIBDIRS+=-L/opt/cut_test/lib/
DEFINES+=-DMR_USE_WIDE_STR
DEFINES+=-DDEBUG
# User defined function for compile to make for each compact.
do-compile=$(CC) $(DEFINES) $(CFLAGS) $(INCLUDES) -c $1.cpp -o $1.o > stderr
#do-compile=$(CC) $(DEFINES) $(CFLAGS) $(INCLUDES) -c $1.cpp -o $1.o > stderr
# The following part of the makefile is generic; it can be used to
# build any static lib just by changing the definitions above and by
# deleting dependencies appended to the file from 'make depend'
.PHONY: depend clean
all: $(UTILLIB)
@echo Simple compiler named ConsoleRunner has been compiled
# rule to archive all of the object files into the static lib
# chains to the OBJS macro which calls the .cpp.o to do the compilation first.
# For some reason gcc does not send out text to stdout of stderr. Must echo
# it
$(UTILLIB): $(SRCS)
mkdir -p $(LIBDIR)
@echo ------------------------------------------------------------
@echo Compiling object files.
$(foreach i,$(SRCS:.cpp=),$(shell $(call do-compile,$i) ))
@echo ------------------------------------------------------------
@echo ------------------------------------------------------------
@echo Objects $(OBJS)
@echo Libs $(LIBS)
@echo ------------------------------------------------------------
@echo ------------------------------------------------------------
@echo Linking into executable
# ld -o $@ $(OBJS) $(LIBDIRS) $(LIBS)
# ld -export-dynamic $(OBJS) $(LIBDIRS) $(LIBS) -o $@
# $(CC) -o $@ $(OBJS) $(LIBDIRS) $(LIBS)
# $(CC) $(OBJS) $(LIBDIRS) $(LIBS) -o $@
$(CC) -export-dynamic $(OBJS) $(LIBDIRS) $(LIBS) -o $@
@echo ------------------------------------------------------------
#$(LDFLAGS) $(CUT_LIBS)
# @echo ------------------------------------------------------------
# @echo Creating Shared Object
# ld -shared -soname $@ -o $@ $(OBJS)
# @echo ------------------------------------------------------------
# ld -shared -soname $@ -o $@ /usr/lib/gcc/i686-linux-gnu/4.6.3/libgcc_s.so -lc -fno-stack-protector $(OBJS)
# ld -shared -fno-stack-protector -soname $@ -o $@ $(OBJS)
#ld -shared -lc -fno-stack-protector -soname $@ -o $@ $(OBJS)
# TODO - lookup what the no-stack-protector might be doing
# this is a suffix replacement rule for building .o's from .cpp's
# it uses automatic variables $<: the name of the prerequisite of
# the rule(a .cpp file) and $@: the name of the target of the rule (a .o file)
# (see the gnu make manual section about automatic variables)
#.cpp.o:
# $(CC) $(CFLAGS) $(INCLUDES) -c $< -o $@
clean:
@echo ------------------------------------------------------------
@echo Cleaning House
@echo ------------------------------------------------------------
$(RM) $(UTILLIB)
$(RM) $(OBJS)
depend: $(SRCS)
makedepend $(INCLUDES) $^
# DO NOT DELETE THIS LINE -- make depend needs it
|
|
|
|
|
Where does the SIGABRT get raised? You may need to add your own signal handler to trap it and take action accordingly.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
It is raised at the point where the exception is thrown. As you can see, unless I am totally missing something, the int is being thrown and properly caught so there should not be a signal raised at all. This is my dilema.
I put in a signal handler but it does no good. App still closes. I will need to handle the signals eventually since this is a unit tester. But for now, I am just trying to figure out why the SIGABRT could possibly be raised on a legitimate thrown and caught exception
This is the message at runtime:
terminate called after throwing an instance of 'int'
The program has unexpectedly finished.
Basically it acts as if there is no catch and the terminate is called. Or perhaps I am misreading something. The stack dump is below
0 __kernel_vsyscall 0 0xb7fdd424
1 __GI_raise raise.c 64 0xb7bd61ef
2 __GI_abort abort.c 91 0xb7bd9835
3 __gnu_cxx::__verbose_terminate_handler() /usr/lib/i386-linux-gnu/libstdc++.so.6 0 0xb7e1813d
4 ?? /usr/lib/i386-linux-gnu/libstdc++.so.6 0 0xb7e15ed3
5 std::terminate() /usr/lib/i386-linux-gnu/libstdc++.so.6 0 0xb7e15f0f
6 __cxa_throw /usr/lib/i386-linux-gnu/libstdc++.so.6 0 0xb7e1605e
7 UtilStrTrimTests::UTL_STR_RTRIM_1 mr_util_str_trim_tests.cpp 31 0xb7b6d692
8 MrTest::Fixture::ExecStep CppTestFixture.cpp 178 0xb7f56d2a
9 MrTest::Fixture::RunTest CppTestFixture.cpp 160 0xb7f56c3c
10 MrTest::EngineImplementation::RunAllFixtureTests MrTestEngineImplementation.cpp 350 0xb7f71a89
11 MrTest::EngineImplementation::ProcessTestList MrTestEngineImplementation.cpp 227 0xb7f711fc
12 MrTest::Engine::ProcessTestList CppTestEngine.cpp 57 0xb7f48241
13 main CppTestDevConsole.cpp 94 0x804cb5c
|
|
|
|
|
I found a solution to the SIGABRT problem. As I suspected it was a problem with the makefile. In particular, I changed
this:
ld -shared -soname $@ -o $@ $(OBJS)
to this:
$(CC) -shared -W1,-soname,$@ -o $@ $(OBJS)
It now behaves in the same way as in Windows. As long as I catch the exception properly it will never SIGABRT.
Seeing that I am not a linux guru, I would appreciate if someone out there has an explanation why a shared object linked with ld will not allow exceptions while one linked with gcc will.
It may also help anyone else having a similar problem. I looked far and wide and could find no documentation on this.
|
|
|
|
|
Can anyone please explain me how to build and use cppunit in visual studio 2010?
I have tried a lot but not able to get it..
|
|
|
|
|
Not sure if this will help, but look at this article[^].
Chris Meech
I am Canadian. [heard in a local bar]
In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
posting about Crystal Reports here is like discussing gay marriage on a catholic church’s website.[Nishant Sivakumar]
|
|
|
|
|
|
Rahul from Poona wrote: I have tried a lot but not able to get it..
Presumably you are using unmanaged C++ right?
|
|
|
|
|
Hello. I am little confused in Late Binding Concept (although I understand it theoretically) as I could not understand it programatically. I am defining two classes here and then casting and using their pointers.
CBaseClass
<br />
void CBaseClass::Function()
{<br />
cout<<"\nBase Class.";<br />
}<br />
CChildClass
<br />
void CChildClass::Function()
{<br />
cout<<"\nChild Class.";<br />
}<br />
MainClass
<br />
void main()<br />
{<br />
CBaseClass* pBase = new cBaseClass();<br />
CChildClass* pChild = (CChildClass*)pBase;<br />
<br />
pBase->Function();<br />
pChild->Function();<br />
}<br />
What should the two function calls produce in MainClass. I think it should produce
BaseClass.
ChildClass.
But it actually produces
BaseClass.
BaseClass.
What is wrong with my understanding. Thanks
This world is going to explode due to international politics, SOON.
|
|
|
|
|
The right main function ought be:
void main()
{
CBaseClass* pBase1 = new cBaseClass();
CBaseClass* pBase2 = new cChildClass();
pBase1->Function();
pBase2->Function();
}
Veni, vidi, vici.
|
|
|
|
|
I just tried this and it produces the expected output:
Base Class.
Child Class.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
It maybe but
Are you sure? What compiler are you using? What code? What else? 
Anyway
CBaseClass * pBase = new CBaseClass();
CChildClass * pChild = (CChildClass *) pBase;
is a gross mistake.
Veni, vidi, vici.
|
|
|
|
|
Exactly so, but as so often happens, the OP has only given us part of the story.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
The code you have shown above does not match the code you are using. If I change it to the following, then it produces the results that you see.
class CBaseClass
{
public:
virtual void Function() {
cout<<"\nBase Class.";
}
};
class CChildClass : CBaseClass
{
public:
void Function() {
cout<<"\nChild Class.";
}
};
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
The bug in your code is obvious. CPallini already gave you the correct code but I feel this is something that needs further clarification.
The bug is the following, and its a major bug in its current context:
CChildClass* pChild = (CChildClass*)pBase;
There are 2 kinds of static casts: downcast and upcast. If you are drawing the uml diagram of your class hierarchy then it looks like a tree with its root node (base class) at the top of the diagram. Down and upcast are named based on the direction of the cast in this tree so an upcast means that you cast a derived class to one of its base classes in the hierarchy, this type of cast is safe, you don't have to mark it explicitly in your code because the compiler does it automatically for you:
Derived * d = new Derived;
Base* b = d;
However downcasts are not only dangerous but they usually mean that you committed a design mistake. A base class can have a lot of derived classes and if you are casting a base class to one of its derived classes than its a bug if the actual object isn't an instance of the downcast type or its descendants. People often say that dowcasts defeat the whole purpose of polymorphism/late binding. Example:
class Base;
class A : public Base;
class B : public Base;
Base* b = new B;
A* p = (A*)b;
So why doesn't your code crash??? Because you were lucky and currently in your simple example the binary representation of instances created by the compiler for your base and derived classes are probably identical, they just differ in their vtable pointer but in any more complex situations it could easily crash.
OK, so when you have a complex hierarchy and you call a virtual function on a base class pointer then which method is executed??? It depends on which object have you actually created! (with new). Since in your example you created just a Base instance it would be magic to see executing the method of the derived class, and its just luck that using the pointer that you filled with your invalid downcast haven't crashed your program.
So based on what we have learned up until now you should only use upcasts that are done automatically for you by the compiler, for example:
CBaseClass* p = new CChildClass; p->Function();
Describing the same in other words:
You can always use a base class pointer to point to an object that was created by instantiating a class derived from the base class. This way if you call some virtual methods on the base class pointer then the methods of the actually instantiated class are called.
modified 24-Sep-12 14:17pm.
|
|
|
|
|
Veni, vidi, vici.
|
|
|
|
|
|
Good explanation about the perils of upcasting and downcasting and how in this simple example the downcasting worked, but that in a real world case, it would likely crash.
Chris Meech
I am Canadian. [heard in a local bar]
In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
posting about Crystal Reports here is like discussing gay marriage on a catholic church’s website.[Nishant Sivakumar]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
