On Thu, 25 Jul 2002 15:58:32 +0200 "OddesE" <OddesE_XYZ@hotmail.com> wrote:

>> Just a note: this isn't right, because main() must return int. =)
> 
> 
> It's the same as with C/C++...
> Walter, I think you should forbid this,
> It's lazy coding. Just do this:

It _is_ forbidden. It's just the compiler doesn't check main() return
type. And since it's extern(C), it's all the same to the linker as
well... but main() is treated specially anyhow, why not add a check?

"Pavel Minayev" <evilone@omen.ru> wrote in message news:CFN374629870745486@news.digitalmars.com...
> On Thu, 25 Jul 2002 15:58:32 +0200 "OddesE" <OddesE_XYZ@hotmail.com>
wrote:
>
> >> Just a note: this isn't right, because main() must return int. =)
> >
> >
> > It's the same as with C/C++...
> > Walter, I think you should forbid this,
> > It's lazy coding. Just do this:
>
> It _is_ forbidden. It's just the compiler doesn't check main() return
> type. And since it's extern(C), it's all the same to the linker as
> well...

Ah, I did not know that...


> but main() is treated specially anyhow, why not add a check?

Agreed.


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail

"Pavel Minayev" <evilone@omen.ru> wrote in message news:CFN374629870745486@news.digitalmars.com...
> It _is_ forbidden. It's just the compiler doesn't check main() return
> type. And since it's extern(C), it's all the same to the linker as
> well... but main() is treated specially anyhow, why not add a check?

Probably a good idea.

"Juarez Rudsatz" <juarez@correio.com> wrote in message news:Xns924588988CEB7juarezcom@63.105.9.61...
> module error9;
>
> void main()
> {
>
> char s;
>
> debug(5)
> {
> // Semantical errors are not detected in debug.

Yes, that is correct.

> // Only syntatical are. How I can assure if a
>         // program is debugable?

The only way is to compile with the debug conditionals enabled.

> s.Value.Anything.Value();
> }
>
> }

Why not enforce the code in debug by doing semantical pass?
If you have two conflitant implementations you need use version instead.
This will reduce the amount of code with possible erros.

E.G:

int main()
{

version (x) {
    	char[] s;
}
version (y) {
    	string s;
}

debug()
{
    	version(x) {
    	    	printf(s);
    	}
    	version(y) {
    	    	s.print();
    	}

    	// this will be checked all time for semantic
    	s = getS();
}

}

"Walter" <walter@digitalmars.com> wrote in news:ai9que$27he$2 @digitaldaemon.com:

> 
> "Juarez Rudsatz" <juarez@correio.com> wrote in message news:Xns924588988CEB7juarezcom@63.105.9.61...
>> module error9;
>>
>> void main()
>> {
>>
>> char s;
>>
>> debug(5)
>> {
>> // Semantical errors are not detected in debug.
> 
> Yes, that is correct.
> 
>> // Only syntatical are. How I can assure if a
>>         // program is debugable?
> 
> The only way is to compile with the debug conditionals enabled.
> 
>> s.Value.Anything.Value();
>> }
>>
>> }
> 

"Juarez Rudsatz" <juarez@nowhere.com> wrote in message news:Xns925D85FB1293Ajuarezcorreiocom@63.105.9.61...
> Why not enforce the code in debug by doing semantical pass?
> If you have two conflitant implementations you need use version instead.
> This will reduce the amount of code with possible erros.

D is deliberately designed to do a syntax check only (no semantic check) in
false debug and version conditionals. The reasons are:
1) faster compilation
2) such code may refer to symbols that do not exist because some
debug/version library is missing
3) such code may be works in progress that are not ready yet to be compiled

It's intent is to provide an equivalent but superior capability than #ifdef DEBUG / #endif.

Imported symbols into function scope can hide local symbols, making for hard to find bugs, especially if the symbol is added into string later.

"Juarez Rudsatz" <juarez@correio.com> wrote in message news:Xns924588C5D4E08juarezcom@63.105.9.61...
> module error11;
>
> void main()
> {
>
> char s;
>
> debug(5)
> {
> import string; // Why this is not allowed ?
> }
>
> }

"Walter" <walter@digitalmars.com> escreveu em news:aic9sp$d33$2@digitaldaemon.com:

> Imported symbols into function scope can hide local symbols, making for hard to find bugs, especially if the symbol is added into string later.
> 

When I wrote this post I have in mind a simple problem : Attaching library
for debuging ( or logging ).
If import is not allowed in debug statement I will need another form of
doing this.
For example, I wanna "printf" out variable values in debug code but in the
release I dont need "c.stdio". This is a simple example, and, maybe, could
exists anothers more complex.
There are another form of doing this ?

dmd -JR

"Walter" <walter@digitalmars.com> escreveu em news:aic9so$d33$1@digitaldaemon.com:

> 1) faster compilation
> 2) such code may refer to symbols that do not exist because some
> debug/version library is missing
> 3) such code may be works in progress that are not ready yet to be
> compiled
> 

Understood !

If the programmer don't deploy the code needed for debug, the mananger could not compile the code.

But the problem remains. Only programmer competence will ensure a debugable programm. Then if someone wanna add a little feature or correct a bug, he could have a good surprise.

Maybe a third way can be applied.

Juarez Rudsatz wrote:
> "Walter" <walter@digitalmars.com> escreveu em
> news:aic9so$d33$1@digitaldaemon.com: 
> 
> 
>>1) faster compilation
>>2) such code may refer to symbols that do not exist because some
>>debug/version library is missing
>>3) such code may be works in progress that are not ready yet to be
>>compiled 
>>
> 
> 
> Understood !
> 
> If the programmer don't deploy the code needed for debug, the mananger could not compile the code.
> 
> But the problem remains. Only programmer competence will ensure a debugable programm. Then if someone wanna add a little feature or correct a bug, he could have a good surprise.
> 
> Maybe a third way can be applied.

Maybe we should have a compiler switch that, in addition to building executables for a specific version and debug level, would automatically also do semantic checks on the rest?  I can imagine that I would use that often in my makefiles, particularly if I'm doing a debug build anyway.

Of course, you could do this with makefiles, if you had a complete list of the potential versions for a given file.  To do that, I would like 2 compiler switches.  One would examine a set of D files and report all of the versions that can be used on them.  The other option would compile things only up to the semantic level.  Then I would build a makefile that first gets all of the versions, then test-builds each in turn.