|
If C++ is an OO program, why compiler doesn't provide automaticaly a default program entry point, if it is not provided by programmer?
IMHO, the object-orientation of the language has little if anything to do with the automatic provision of an entry point for a program.
There are compilers that do this? Which one?
None that I know of. It would be against the standard, which very clearly specifies how an entry program is to be provided.
What is that you're after? If you explain yourself a little longer, maybe we'll be able to help you.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
My problem is that in MFC, program entry point is encapsulated somewhere in a class. (Or maybe my understanding is wrong here??). I want to do the same, and have no global function in my application.
Thanks.
|
|
|
|
|
Don Miguel wrote:
why compiler doesn't provide automaticaly a default program entry point
It does, it's main() or WinMain().
--Mike--
"There are only a limited number of jobs where they will ask to see the sausage. Most of them are in movies."
-- Christian Graus, 2/11/2002
My really out-of-date homepage
Sonork - 100.10414 AcidHelm
Big fan of Alyson Hannigan.
|
|
|
|
|
Michael Dunn wrote:
It does, it's main() or WinMain().
If I don't put main() in my code, the linker tell me about an unresolved symbol, so, IMO the compiler doesn't provide what I need.
|
|
|
|
|
What is the purpose of your application to not have an entry point?
If you do not have a global entry point, there is no way for your code to start executing.
|
|
|
|
|
kilowatt wrote:
What is the purpose of your application to not have an entry point?
Really, I agree with ideea to have an entry point, but I want this entry point to be a member function of a class, and not a global function.
|
|
|
|
|
In order to get that to work, your entry point function will need to be a static function of the class, because your class will not yet be initialized when your program starts up.
Then you will have to find the compiled symbol for that static class function and set this into the the entry-point symbol field of the ouput category on the linker page of Project settings.
Finally you will need to initialize the C/C++ runtime library yourself if you plan on using printf, cout, the string functions and things like this. You should be able to find some articles in MSDN or on the internet that explain how to do this.
Here is a sample program that I wrote to test this:
<br />
#include "stdafx.h"<br />
<br />
class entry<br />
{<br />
public:<br />
static int point()<br />
{<br />
return 0;<br />
}<br />
<br />
};<br />
<br />
int main(int argc, char* argv[])<br />
{<br />
entry::point();<br />
<br />
printf("Hello World!\n");<br />
return 0;<br />
}<br />
The entry point that I used was this: ?point@entry@@SAHXZ, I found it in the disassempbly when I called entry::point from main before I reset the entry point.
If you have any more questions feel free to ask.
|
|
|
|
|
Thanks a lot! Youre answer bring a lot of light to me.
Everithing you say is right, I tested the snippet you show me.
I must say it work for me without check entry point in disassembly, but putting in project settings->link->output->entry point symbol directly the function, "point" (without specification of class, "entry").
I make another try, to delete "static" qualifier for function "point"
and, everything work again!!! This really amasing me, since I am totally in agree with you that the function must be static. 
Removing "static" and trying to use something like "this->aFunction" work also, and I was curious where point this, so I break program and look at the addresses. It point somewhere in an unknown zone, but invocation of entry function in form "this->point" continue to work!! Amazing, I think the compiler do something hydden, here. (I use VC++ 6.0)
Thanks for your answer.
|
|
|
|
|
It's not terribly mysterious. point is a member function of a class so it may be called and executed. However, no actual instance of the class has been created when it is called. If you add some data members you should see that they have not been initialized. Set up a constructor for the class to initialize the data members and you should see that it is never called.
|
|
|
|
|
Yes, you are right, the class is not initialized,
but, the amazing fact is that calling another function
from the class, through "this" pointer work!!!!!
Is like a virtual table exist, for a class uninstantiated!!!!
 - maybe I should verify this with another compiler!!
|
|
|
|
|
You really will want to make your entry point function a static function, unless there is no member variables in your class, then it wont matter.
The function V-Table always exists for a C++ object, that is why your non-static member function succeeded, however, the moment that you try to use a member variable from this function, without an instantiated object, your program will crash because no memory has been allocated to this object, and there is no valid this pointer sent into the function.
If you were to try this example with teh get_data member funtion as the entry point, it would crash on you:
<br />
#include "stdafx.h"<br />
<br />
class entry<br />
{<br />
int m_data;<br />
public:<br />
static int point()<br />
{<br />
return 0;<br />
}<br />
<br />
int get_data()<br />
{<br />
return m_data;<br />
}<br />
<br />
};<br />
<br />
int main()<br />
{<br />
entry::point();<br />
<br />
entry x;<br />
x.get_data();<br />
<br />
return 0;<br />
}<br />
With this is mind, your static member function should instantiate a class object for you to continue with your plans.
|
|
|
|
|
kilowatt wrote:
The function V-Table always exists for a C++ object, that is why your non-static member function succeeded,
Thanks, I doesn't know this. So, no misterys here! 
kilowatt wrote:
however, the moment that you try to use a member variable from this function, without an instantiated object, your program will crash because no memory has been allocated to this object, and there is no valid this pointer sent into the function.
You again are right.
So, my questions are clear now. Thanks a lot for your patience.
Regards.
|
|
|
|
|
Well, someone here recently remarked that its better to speak up and find out you're wrong and learn something... 
I was testing with just a global foo() fn, and had to force linkage if I removed main, but I see now this can work.
I wasn't able to track down anything on the ability to manually initialize the c runtime though, and would like to know if thats possible. FWTW I did stumble on a '96 MSJ article by Matt Pietrek where he outlines how to _avoid_ using the CRT - search for TINYCRT in MSDN - win32 routines are used instead.
|
|
|
|
|
I am concerned about the following:
As long as in the linker options, I can set the program entry point,
and - I tested personally - this can be any function, with any prototype
(I mean not just main standard prototype), I wonder if is a way to set
as entry point a function with prototype like
AClass myClassInstance;
i.e a class type (user defined data type).
I put the question because I couldn't remember where I found a topic about
the fact that C++ doesn't really need main() function to work (was certainly
a discution about OO Programming and OO nature of C++)
Can anybody help? Does anyone know something similar?
Regards.
|
|
|
|
|
C++, like C, requires a main function for its entry point.
Yes, you can put a different function in the linker settings but I think its ignored for executables unless its just a question of resolution (i.e. wWinMainCRTStartup for unicode windows apps).
The key here is that you're linking with a standard runtime library (CRT) that has startup and exit code that will call your main routine after certain operations are performed (init static vars etc).
The 'nostub' programs you speak of are built with non-standard libraries and are I think targeted at embedded code that wants to bypass certain lib code for compatibility reasons.
It should be said that the reason for main is to maintain (no pun) the ability for C programs to be compiled. Would you rather go with a java construct where the 'main' class contains a defined entry point? Or is that still a restriction? I won't fight you if your argument is that that is more 'object oriented' - but until I get smarter that Stroustrup (note, I've almost got his hairstyle ) I'll try and deal with it.
|
|
|
|
|
I need a file open dialog with the following attributes:
#1 - Floppy drive access disabled.
#2 - Drag & Drop disabled within the file/folder list(s).
#3 - Context sensitive menu disabled.
#4 - Runs on Windows 95/98/Me.
Can this be done with the standard Microsoft CFileDialog class? If so, how? (I've read several CFileDialog sub-classing articles and none provide any clue to any of these issues.) If this is not possible with the standard dialog, does anyone know of a class that provides this functionality so I don't have to re-invent the wheel?
If anyone is interested in why I need this, read below...
Concept - My application is a control for a piece of industrial machinery. It provides a GUI to the operator as well as machine logic and high speed messaging with proprietary motion control modules for the machines axes. It runs on an industrial PC with a flat panel touch screen and a Texas Industrial pointing device. The operator needs to load new program files for each piece of raw stock that comes to the machine. Right now I am using the standard CFileDialog and have the following problems:
#1 - Floppy drive access is very slow and drags down system performance, when this happens the proprietary motion control modules' watchdog timers time out and shutdown the control. We tell everyone not to use floppies directly in the control software, but some never learn and I'd like to stop them.
#2 - Because the touch screen and industrial pointing devices are... well... industrial, they don't provide a good high resolution consistent method of handling smallish items (like files/folders in a CListCtrl) and heavy-handed operators accidently drag files/folders and drop them into other folders and lose them.
#3 - The machine operators have no need of the items in the context sensitive menu and can only get themselves in trouble with these commands. I'd like to eliminate the possibility.
#4 - Unfortunately the drivers for the proprietary motion control modules run ONLY under Windows 95/98/Me and many of our current machines in the field are running Windows 95, so any solution MUST run on it.
Problems #2 and #4 are the most important, #1 and #3 are icing on the cake!
Mike Mullikin
"Programming is like sex. One mistake and you have to support it for the rest of your life." - Michael Sinz
|
|
|
|
|
I'd craft my own, using a combo box of hard disks, a folder listbox and a files list box, much like the old style File Open dialog. You can also auto-filter for files of a specific type that make sense to your app.
/ravi
"There is always one more bug..."
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
I don't think CFileDialog is as customizable as you need. Xiaolong Wu has written a CFileDialog clone for which he provides the source code. Maybe you can download it and modify it to suit your needs (he even points this in his article as a major reason for having written the clone).
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
I am no expert, but why not just use a simple list control that lists all the available programs, or may be a series of list controls if the programs are grouped in some way. It seems to me the operator does not need to have any knowledge of where the programs are located on disk, he/she just needs the ability to choose the one that is required for the current job.
Use the KISS (Keep It Simple, Stupid) method. Don't give the operator any more functionality than what he needs to do the job, it just confuses most of them.
---
Sonork 100.11743 Chicken Little
It may be that your sole purpose in life is simply to serve as a warning to others.
|
|
|
|
|
PJ Arends wrote:
I am no expert, but why not just use a simple list control that lists all the available programs, or may be a series of list controls if the programs are grouped in some way. It seems to me the operator does not need to have any knowledge of where the programs are located on disk, he/she just needs the ability to choose the one that is required for the current job.
The problem is that in this industry (structural steel fabrication) a fabricator will typically have dozens (maybe hundreds) of separate projects running through their shop at any given time. Each project can have dozens of phases that get done individually. Each phase can have several hundred or even several thousand individual unique parts. Some projects can last several years. Most fabricators use a somewhat elaborate (and nearly always proprietary) network folder tree structure to keep the projects/phases/parts organized. The strength of our machinery is that it requires virtually no setup or reconfiguring to switch from part to part and therefore fabricators tend to send parts at it in no particular order (as it relates to specific projects/phases) and the operator must navigate thru this maze of folders to find the correct part.
PJ Arends wrote:
Use the KISS (Keep It Simple, Stupid) method. Don't give the operator any more functionality than what he needs to do the job, it just confuses most of them.
I agree 100% and have argued this point on this very topic, but fabricators are also a pig-headed group and demand this flexibility.
It looks like I'll have to roll my own or live with it the way it is.
Mike Mullikin
"Programming is like sex. One mistake and you have to support it for the rest of your life." - Michael Sinz
|
|
|
|
|
Add another vote for roll your own. I have dealt with touchscreens also and they present some challenges. Although they may look clunky, buttons must often be a bit larger so that people wearing gloves can press them.
I would make a dialog with a listbox for the files and two large up down arrow buttons for selection. It is easy to write logic for filling the list with files and additional logic for directory navigation is not too tough.
Good luck.
|
|
|
|
|
The roll-your-own solutions mentioned above sound like your best bet, but for a quick solution, you can remove the OFN_EXPLORER style from CFileDialog::m_ofn.Flags. This will make it an old-style dialog, with no support for drag & drop or property menus.
CFileDialog dlgFile(TRUE);
dlgFile.m_ofn.Flags &= ~OFN_EXPLORER;
dlgFile.DoModal();
This page describes a way that might work for hiding the a: drive.
Setting up windows to use large fonts might make this all easier to use via a touch screen.
farewell goodnight last one out turn out the lights Smashing Pumpkins, Tales of a Scorched Earth
|
|
|
|
|
Hi everyone, im trying to display an icon within a button so i inserted
the code below:
void CButtonDlg::OnButton1()
{
m_btn1.SetIcon(IDI_ICON1);
}
But it an error occurs : error C2664: 'SetIcon' : cannot convert parameter 1 from 'const int' to 'struct HICON__ *' (new behavior; please see help)
CAN ANYONE HELP ME? THANK YOU IN ADVANCE ! 
|
|
|
|
|
There are lots of articles in CP about buttons.
Mazy
Don't Marry a Person You Can Live With...
Marry Someone You Can Not Live Without
|
|
|
|
|
SetIcon accepts an HICON (a handle to an icon) rather than a resource identifier. Use AfxGetApp()->LoadIcon(...) to obtain the icon first.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
