www.digitalmars.com         C & C++   DMDScript  

D - Program entry point

reply Vathix <vathix dprogramming.com> writes:
This has been in the back of my mind for awhile and I've finally decided 
it's not a bad idea: Having the program entry-point be this() instead of 
main(). You'll see how it fits in well with how we do classes, static 
this() and instance this(). Module this() would be the instance of the 
program. It would take either no parameters or char[][] like main, and 
have no return value.

this(char[][] args)
{
    printf("hello world %d args.", args.length);
}

What about main's int error code return value, you may ask? This isn't 
actually needed anymore, because we throw an exception on error. The 
exception handler that wraps this() would catch it and return an error 
code, whereas if this() cleanly returns, it would return 0. Kind of like 
this:

//real, hidden main
int main(char[][] args)
{
    int result = 0;
    try
    {
       this(args); //call module this
    }
    catch(Object o)
    {
       o.print();
       result = 1; //error!
    }
    return result;
}

This seems to be more OO, and main() could still be allowed for old time 
sake and for more structured programs.


-- 
Christopher E. Miller
www.dprogramming.com
irc.dprogramming.com #D
Feb 25 2004
next sibling parent larry cowan <larry_member pathlink.com> writes:
..and if I have a group of interrelated modules dropped on me which implement
multiple executables (src\dmd ?) and I want to find out where to start sorting
things out, do I have to search through and find all the naked 'this'
occurrences?

In article <c1ibv8$1u5s$1 digitaldaemon.com>, Vathix says...

This has been in the back of my mind for awhile and I've finally decided 
it's not a bad idea: Having the program entry-point be this() instead of 
main(). You'll see how it fits in well with how we do classes, static 
this() and instance this(). Module this() would be the instance of the 
program. It would take either no parameters or char[][] like main, and 
have no return value.

this(char[][] args)
{
    printf("hello world %d args.", args.length);
}

What about main's int error code return value, you may ask? This isn't 
actually needed anymore, because we throw an exception on error. The 
exception handler that wraps this() would catch it and return an error 
code, whereas if this() cleanly returns, it would return 0. Kind of like 
this:

//real, hidden main
int main(char[][] args)
{
    int result = 0;
    try
    {
       this(args); //call module this
    }
    catch(Object o)
    {
       o.print();
       result = 1; //error!
    }
    return result;
}

This seems to be more OO, and main() could still be allowed for old time 
sake and for more structured programs.


-- 
Christopher E. Miller
www.dprogramming.com
irc.dprogramming.com #D
Feb 25 2004
prev sibling next sibling parent reply Sean Kelly <sean ffwd.cx> writes:
So in a multi-module program, which "this" should the compiler make "main?"


Sean
Feb 25 2004
next sibling parent reply Vathix <vathix dprogramming.com> writes:
Sean Kelly wrote:

 So in a multi-module program, which "this" should the compiler make "main?"
 
 
 Sean
 



Only put it in one module of the program, like main.


-- 
Christopher E. Miller
www.dprogramming.com
irc.dprogramming.com #D
Feb 25 2004
next sibling parent Stephan Wienczny <wienczny web.de> writes:
Vathix wrote:

 Sean Kelly wrote:
 

 So in a multi-module program, which "this" should the compiler make 
 "main?"


 Sean



 Only put it in one module of the program, like main.
 
 



As first apporach you could make a global this an alias of main.

Stephan
Feb 25 2004
prev sibling parent Sean Kelly <sean ffwd.cx> writes:
Vathix wrote:

 
 Only put it in one module of the program, like main.



So does this mean I could only have one module "this" in the entire 
project?  Or would this be based on the parameters passed?


Sean
Feb 25 2004
prev sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Sean Kelly wrote:

 So in a multi-module program, which "this" should the compiler make "main?"
 
 Sean



I found this at http://digitalmras.com/d/module.html:


"The order of static initialization is implicitly determined by the 
import declarations in each module.  Each module is assuemd to depend on 
any imported modules being statically constructed first.  Other than 
following that rule, there is no imposed order on executing the module 
static constructors.

Cycles (circular dependencies) in the import declarations are allowed as 
long as not both of the modules contain static constructors or static 
desctructors. Violation of this rule will result in a runtime exception."


So I would say that the "main" this() of the program should be the last 
one to be called in the ordering of constructors.  (I'm assuming, 
though, that in reality it is the first to be called...and that its 
implementation automatically calls the constructors for all others.)


I actually like this idea a lot, at least in theory.  I would like to 
have the "main" this stand out from all other this() functions.  So I 
would lean toward a required "main" keyword:

main this(char[][] args) {...}

but now we've gotten back to something that really is a main() function. 
  So I'm not convinced that we've really gained anything.


Still, I would like to have this discussed some more.  Let's see what 
good ideas turn up here.
Feb 25 2004
parent reply resistor mac.com writes:
What could be done is to create a syntax where each module can specify which
imported modules are absolutely required to be initialized before its this() is
run.

Thus if one module imports another, but doesn't actually require it for
initialization, it could safely not "require" that module.  The this() which
replaces the main() would just have to "require" every other module.

This could actually lead to an interesting new threading paradigm, if the this()
of each module runs in a separate thread.  It reminds me of a microkernel: each
separate component operates in its own thread, and the order they are started in
is determined by requirement lists.

Just some random ideas though.

Owen

In article <c1imsp$2ibb$1 digitaldaemon.com>, Russ Lewis says...

Sean Kelly wrote:

 So in a multi-module program, which "this" should the compiler make "main?"
 
 Sean



I found this at http://digitalmras.com/d/module.html:


"The order of static initialization is implicitly determined by the 
import declarations in each module.  Each module is assuemd to depend on 
any imported modules being statically constructed first.  Other than 
following that rule, there is no imposed order on executing the module 
static constructors.

Cycles (circular dependencies) in the import declarations are allowed as 
long as not both of the modules contain static constructors or static 
desctructors. Violation of this rule will result in a runtime exception."


So I would say that the "main" this() of the program should be the last 
one to be called in the ordering of constructors.  (I'm assuming, 
though, that in reality it is the first to be called...and that its 
implementation automatically calls the constructors for all others.)


I actually like this idea a lot, at least in theory.  I would like to 
have the "main" this stand out from all other this() functions.  So I 
would lean toward a required "main" keyword:

main this(char[][] args) {...}

but now we've gotten back to something that really is a main() function. 
  So I'm not convinced that we've really gained anything.


Still, I would like to have this discussed some more.  Let's see what 
good ideas turn up here.
Feb 25 2004
parent "Kris" <someidiot earthlink.net> writes:
Makes sense for that style of threading ... the ~this() would also make
sense in that context.


<resistor mac.com> wrote in message news:c1iq2p$2o8m$1 digitaldaemon.com...

 What could be done is to create a syntax where each module can specify




 imported modules are absolutely required to be initialized before its




 run.

 Thus if one module imports another, but doesn't actually require it for
 initialization, it could safely not "require" that module.  The this()




 replaces the main() would just have to "require" every other module.

 This could actually lead to an interesting new threading paradigm, if the




 of each module runs in a separate thread.  It reminds me of a microkernel:




 separate component operates in its own thread, and the order they are




 is determined by requirement lists.

 Just some random ideas though.

 Owen

 In article <c1imsp$2ibb$1 digitaldaemon.com>, Russ Lewis says...

Sean Kelly wrote:

 So in a multi-module program, which "this" should the compiler make










 Sean



I found this at http://digitalmras.com/d/module.html:


"The order of static initialization is implicitly determined by the
import declarations in each module.  Each module is assuemd to depend on
any imported modules being statically constructed first.  Other than
following that rule, there is no imposed order on executing the module
static constructors.

Cycles (circular dependencies) in the import declarations are allowed as
long as not both of the modules contain static constructors or static
desctructors. Violation of this rule will result in a runtime exception."


So I would say that the "main" this() of the program should be the last
one to be called in the ordering of constructors.  (I'm assuming,
though, that in reality it is the first to be called...and that its
implementation automatically calls the constructors for all others.)


I actually like this idea a lot, at least in theory.  I would like to
have the "main" this stand out from all other this() functions.  So I
would lean toward a required "main" keyword:

main this(char[][] args) {...}

but now we've gotten back to something that really is a main() function.
  So I'm not convinced that we've really gained anything.


Still, I would like to have this discussed some more.  Let's see what
good ideas turn up here.
Feb 25 2004
prev sibling next sibling parent reply "Walter" <walter digitalmars.com> writes:
It's an interesting idea, and it can work. But I see a few problems:

1) When I get a large block of source, I usually have to grep around looking
for where main() is. With this() instead, I'd have to filter out a lot of
false hits.

2) C/C++ tradition is for main().

3) DLL's and Windows apps have differently named main() functions, the
reason for the difference is so that different startup code can be called
in.
Feb 25 2004
next sibling parent resistor mac.com writes:
1) When I get a large block of source, I usually have to grep around looking
for where main() is. With this() instead, I'd have to filter out a lot of
false hits.



True.  But it could also lead to some very interesting possibilities in terms of
parallelism if taken to its fullest extent.


2) C/C++ tradition is for main().



Yes, that's the biggest hurdle I see.  It would take some serious getting used
to.  I'd imagine a programmer should still be able to use main() if he so
desired.


3) DLL's and Windows apps have differently named main() functions, the
reason for the difference is so that different startup code can be called
in.



I don't think that's a big hurdle.  If the programmer uses the this() syntax,
the compiler is going to have to generate a stub main for him anyways.  In this
case, the compiled just makes a stub main with the appropriate name for Win32.

Owen
Feb 25 2004
prev sibling next sibling parent reply Vathix <vathix dprogramming.com> writes:
Walter wrote:


 It's an interesting idea, and it can work. But I see a few problems:
 
 1) When I get a large block of source, I usually have to grep around looking
 for where main() is. With this() instead, I'd have to filter out a lot of
 false hits.



Agreed, but where you position the function could help. Top of 
programname.d for example.


 
 2) C/C++ tradition is for main().



Using this() appears more OO to me, I could be wrong. Since D is 
multiple paradigm, allowing structured main() or OO this() seems quite 
OK to me.


 
 3) DLL's and Windows apps have differently named main() functions, the
 reason for the difference is so that different startup code can be called
 in.



To me, WinMain() is useless (plus see how difficult it is to use in D as 
of now). Lately I've just been using main() and telling the linker it's 
a Windows app.
DLLs seem completely different. DllMain/DllEntryPoint isn't actually a 
"program driver" function, it's just a initialization/cleanup function. 
More like an event callback. DLLs wouldn't use this().


-- 
Christopher E. Miller
www.dprogramming.com
irc.dprogramming.com #D
Feb 25 2004
parent Sean Kelly <sean ffwd.cx> writes:
Vathix wrote:

 Walter wrote:


 2) C/C++ tradition is for main().



 Using this() appears more OO to me, I could be wrong. Since D is 
 multiple paradigm, allowing structured main() or OO this() seems quite 
 OK to me.



But a program's execution point isn't an OO concept, unless you want to 
support the idea of multiple entry points within a single application. 
Either way, I don't think it's entirely foreign as Java does this already.


 To me, WinMain() is useless (plus see how difficult it is to use in D as 
 of now). Lately I've just been using main() and telling the linker it's 
 a Windows app.
 DLLs seem completely different. DllMain/DllEntryPoint isn't actually a 
 "program driver" function, it's just a initialization/cleanup function. 
 More like an event callback. DLLs wouldn't use this().



Why not?  Using this() and ~this() seems to make sense as the C model 
doesn't have any natural support for release functionality.


Sean
Feb 25 2004
prev sibling parent reply Ant <Ant_member pathlink.com> writes:
In article <c1ir1t$2pr4$1 digitaldaemon.com>, Walter says...

It's an interesting idea, and it can work. But I see a few problems:

1) When I get a large block of source, I usually have to grep around looking
for where main() is. With this() instead, I'd have to filter out a lot of
false hits.



I still don't know why we have "this" instead of "ctor".

Ant
Feb 25 2004
parent "Phill" <phill pacific.net.au> writes:
Isnt "this" more appropriate? It refers to
this particular Object that has been constructed doesnt it?
If you called it "ctor", would you then go

ctor.var;
instead of
this.var; ?

Phill.


"Ant" <Ant_member pathlink.com> wrote in message
news:c1j584$a54$1 digitaldaemon.com...

 In article <c1ir1t$2pr4$1 digitaldaemon.com>, Walter says...

It's an interesting idea, and it can work. But I see a few problems:

1) When I get a large block of source, I usually have to grep around







for where main() is. With this() instead, I'd have to filter out a lot of
false hits.



 I still don't know why we have "this" instead of "ctor".

 Ant
Mar 02 2004
prev sibling parent "Kris" <someidiot earthlink.net> writes:
I was thinking this might lead to an interesting use for ~this()  as well.
But then, if the constructor (main) failed, then the destructor wouldn't be
invoked anyway (according to the D ctor/dtor rules)  ...


"Vathix" <vathix dprogramming.com> wrote in message
news:c1ibv8$1u5s$1 digitaldaemon.com...

 This has been in the back of my mind for awhile and I've finally decided
 it's not a bad idea: Having the program entry-point be this() instead of
 main(). You'll see how it fits in well with how we do classes, static
 this() and instance this(). Module this() would be the instance of the
 program. It would take either no parameters or char[][] like main, and
 have no return value.

 this(char[][] args)
 {
     printf("hello world %d args.", args.length);
 }

 What about main's int error code return value, you may ask? This isn't
 actually needed anymore, because we throw an exception on error. The
 exception handler that wraps this() would catch it and return an error
 code, whereas if this() cleanly returns, it would return 0. Kind of like
 this:

 //real, hidden main
 int main(char[][] args)
 {
     int result = 0;
     try
     {
        this(args); //call module this
     }
     catch(Object o)
     {
        o.print();
        result = 1; //error!
     }
     return result;
 }

 This seems to be more OO, and main() could still be allowed for old time
 sake and for more structured programs.


 --
 Christopher E. Miller
 www.dprogramming.com
 irc.dprogramming.com #D
Feb 25 2004