Re: Semicolon can be left out after do-while
> Timon Gehr: > > I just noticed a little oddity. > > > Why does this code compile? The equivalent C code is rejected: > I think Andrei wants (rightly) it to be fixed. So I think it is an > implementation "bug" that will be fixed. IIRC, TDPL says that the semicolon is required, even though it isn't, and when that was brought to Andrei's attention, he asked Walter to change it so that it is required like TDPL says. But as far as I know, nothing has happened. I don't recall Walter saying anything about it on the list either. So, I have no idea what the state of this is. I susupect that it was completely forgetten. An bug stating that this needs to be fixed to match TDPL is probably in order. - Jonathan M Davis
Re: Questions to template overload resolution
> 1) T foo(T:SomeClass)(T arg){..}
> It is specified on the main page that this template will match against
> instantiations with a subclass of SomeClass. Will this also duplicate the
> code? Or will the template work similar to the function T foo(SomeClass
> arg){..}? If yes, why should normal functions and function templates
> without type params be separated at all?
Templates are used for code generation, pure and simple. They don't exist
until you instantiate them (so, for instance, if a template is horribly broken
and wouldn't compile if you tried to use it, the code will still compile as
long as the template isn't used), and every time that you instantiate a
template with a new type, it generates new code. This allows you to do some
really nice stuff with different versions of stuff for different types, as
well as stuff like eponymous templates, where you use a template to generate a
value.
The templated function
T foo(T)(T arg){...}
is really something like
template foo(T)
{
T foo(T arg) {...}
}
and the template doesn't really exist until it's instantiated, so it's very
different from a normal function, which would exist regardless of whether it
was used. And since the function could change considerably depending on the
template arguments (you can use static ifs and other templates inside the
function which could cause the instiated template function to be drastically
different depending on the template arguments, even if the template's
signature and constraints are the same).
>
> 2) Why is this an error? Obviously, the second template is a better match.
>
> What is the rationale for requiring the clumsier f(T:double,U:int)(T a,U b)
> to f()(double a,int b) to allow proper overload resolution?
>
> import std.stdio;
>
> T f(T,U)(T a,U b){
> return a;
> }
> T f()(double a,int b){
> return a;
> }
>
> void main(){
> writeln(f(1.2,1));//error
> }
> test.d(11): Error: template test.f(T,U) f(T,U) matches more than one
> template declaration, test.d(3):f(T,U) and test.d(6):f()
The second template wouldn't even work. Where does the T come from? I'm
surprised that even compiles far enough to sayt that it can't determine which
template to use. But even if you did something like
double f(U)(double a, U b)
{
return a;
}
I expect that it still wouldn't work, because it matches two separate
templates. I believe that all template overload resolutions are done via the
template arguments and template constraints and that the function arguments
don't enter into it at all. The contents of the template are only relevant
once the template has been instantiated. Remember that the definition of f is
really something like this
T f(T, U)
{
T f(T a, U b)
{
return ;
}
}
That outer template must be properly resolved before what's inside the
template is even brought into consideration.
If you want to do what you're doing, the second template would look something
more like
T f(T : double, U : int)(T a, U b)
{
return a;
}
That way, the template overload resolution can be done based on the template
parameters, not the function's parameters.
- Jonathan M Davis
Re: Semicolon can be left out after do-while
On 04/12/2011 11:51 PM, Steven Schveighoffer wrote:
On Tue, 12 Apr 2011 17:21:57 -0400, spir wrote:
On 04/12/2011 09:21 PM, Steven Schveighoffer wrote:
int main(){
int a,b;
do{
scanf("%d %d",&a,&b);
}while(ahttp://www.digitalmars.com/d/2.0/statement.html#DoStatement)
[...]
I think the grammar should be changed...
yop!
This is almost as bad as go's
requirement for if statement opening block to be on the same line...
why? I like Go's syntactuc diffs. (except for its "multi-for")
in Go, this:
if(x)
{
gosWriteRoutineThatIDontKnowTheSyntaxOf("hello")
}
is equivalent to this in D:
if(x)
{
}
writeln("hello");
This is frankly unforgivable IMO.
Of course it's fixable, but the attitude that "the coder should know better"
doesn't really make me comfortable with it. And I hate the "brace on the same
line" format (but this of course is not a real argument against it).
Oh, that's what you meant! I find this a Good Thing, in that it enforces one
bracing style (the right one, that does not eats one more line for just a '{').
About knowing or not about this (non/mis/-)feature, it's written down, and
clearly, in all Go docs I've read. And one cannot miss it for very long anyway
;-) Maybe, if not done already, a line starting with an opening brace should
generate a parsing error.
Denis
--
_
vita es estrany
spir.wikidot.com
Re: Semicolon can be left out after do-while
On Tue, 12 Apr 2011 17:21:57 -0400, spir wrote:
On 04/12/2011 09:21 PM, Steven Schveighoffer wrote:
int main(){
int a,b;
do{
scanf("%d %d",&a,&b);
}while(aThe grammar specifies this correctly, but then again, the example uses
the
semicolon. (http://www.digitalmars.com/d/2.0/statement.html#DoStatement)
[...]
I think the grammar should be changed...
yop!
This is almost as bad as go's
requirement for if statement opening block to be on the same line...
why? I like Go's syntactuc diffs. (except for its "multi-for")
in Go, this:
if(x)
{
gosWriteRoutineThatIDontKnowTheSyntaxOf("hello")
}
is equivalent to this in D:
if(x)
{
}
writeln("hello");
This is frankly unforgivable IMO.
Of course it's fixable, but the attitude that "the coder should know
better" doesn't really make me comfortable with it. And I hate the "brace
on the same line" format (but this of course is not a real argument
against it).
-Steve
Re: Semicolon can be left out after do-while
On 04/12/2011 09:21 PM, Steven Schveighoffer wrote:
int main(){
int a,b;
do{
scanf("%d %d",&a,&b);
}while(ahttp://www.digitalmars.com/d/2.0/statement.html#DoStatement)
[...]
I think the grammar should be changed...
yop!
This is almost as bad as go's
requirement for if statement opening block to be on the same line...
why? I like Go's syntactuc diffs. (except for its "multi-for")
denis
--
_
vita es estrany
spir.wikidot.com
Re: Should writef try to statically check for format specifiers?
On 4/12/11, bearophile wrote: > Template functions may not require a bang+types if argument > types can be inferred from the given arguments. So isn't the string literal a candidate in this case?
Questions to template overload resolution
1) T foo(T:SomeClass)(T arg){..}
It is specified on the main page that this template will match against
instantiations with a subclass of SomeClass. Will this also duplicate the
code? Or will the template work similar to the function T foo(SomeClass
arg){..}? If yes, why should normal functions and function templates without
type params be separated at all?
2) Why is this an error? Obviously, the second template is a better match.
What is the rationale for requiring the clumsier f(T:double,U:int)(T a,U b) to
f()(double a,int b) to allow proper overload resolution?
import std.stdio;
T f(T,U)(T a,U b){
return a;
}
T f()(double a,int b){
return a;
}
void main(){
writeln(f(1.2,1));//error
}
test.d(11): Error: template test.f(T,U) f(T,U) matches more than one template
declaration, test.d(3):f(T,U) and test.d(6):f()
Re: Should writef try to statically check for format specifiers?
Andrej Mitrovic: > I thought templated functions can be called without a bang if an > argument can be deduced to be available at compile time. I know I've > read about this somewhere, either TDPL or the docs. So I thought that > writef checks the string literal at compile time, not runtime. I think there is some confusion here. Each function call is done fully at compile time or fully at run time, there is no partial compilation. Template arguments always require the bang, and they are always taken at compile-time. Template functions may not require a bang+types if argument types can be inferred from the given arguments. Bye, bearophile
Re: Semicolon can be left out after do-while
On Tue, 12 Apr 2011 14:57:26 -0400, Timon Gehr wrote:
I just noticed a little oddity.
Why does this code compile? The equivalent C code is rejected:
import std.stdio;
//#include
int main(){
int a,b;
do{
scanf("%d %d",&a,&b);
}while(aThe grammar specifies this correctly, but then again, the example uses
the
semicolon. (http://www.digitalmars.com/d/2.0/statement.html#DoStatement)
That looks horrible, reformatted looks even worse:
int main()
{
int a,b;
do
{
scanf("%d %d",&a,&b);
}
// so here is a comment to separate things a bit
//
// do you think this makes sense?:
while(aI think the grammar should be changed... This is almost as bad as go's
requirement for if statement opening block to be on the same line (would
be as bad, but do..while doens't occur a lot).
-Steve
Re: Semicolon can be left out after do-while
Timon Gehr: > I just noticed a little oddity. > Why does this code compile? The equivalent C code is rejected: I think Andrei wants (rightly) it to be fixed. So I think it is an implementation "bug" that will be fixed. Bye, bearophile
Semicolon can be left out after do-while
I just noticed a little oddity.
Why does this code compile? The equivalent C code is rejected:
import std.stdio;
//#include
int main(){
int a,b;
do{
scanf("%d %d",&a,&b);
}while(ahttp://www.digitalmars.com/d/2.0/statement.html#DoStatement)
Re: implib
It's for Windows only.
Re: static variables for non-constant expressions?
On 12/04/2011 01:59, Steven Wawryk wrote: On 12/04/11 07:36, Simon wrote: On 11/04/2011 22:15, Stewart Gordon wrote: On 11/04/2011 02:37, Jonathan M Davis wrote: This is true for static "globals" and static members, but the C++ standard requires static locals (local to functions) to be initialized on first call. It's a widely used idiom to avoid static initialization order issues to use functions that do nothing more than return a reference to a static local rather than use static globals directly. Hmm, that's only true for objects w/ ctors by the looks of it. The OPs question was about int, though values types can just be compiled in. MS must have changed their compiler to match the spec then at some point; I've been bitten by undefined order of statics before. -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk
Re: Should writef try to statically check for format specifiers?
I thought templated functions can be called without a bang if an argument can be deduced to be available at compile time. I know I've read about this somewhere, either TDPL or the docs. So I thought that writef checks the string literal at compile time, not runtime. Template shenanigans..
implib
Hi, can anyone tell me where to find implib. I am using mac OS X, but bup.zip have just exe files, which are of no use. Is there a place where I can find implib for mac or unix system? Thanks for the help Tine Šukljan
Re: Range violation error in the code
>An array does not dynamically adjust its length when you assign an >element, you have to assign the length explicitly before-hand. Some >dynamic languages do this (like Javascript), but not D. > >You can achieve this with an associative array: > >Node*[int] pointers; > >However, iterating an AA does not guarantee order. So it depends on your >requirements. > >-Steve Thank you..!. That clarifies the things a lot. :)
strange warning at link-time
/usr/bin/ld: Warning: size of symbol `_D5table14__T5TableTkTkZ5Table7opApplyMFDFKkZiZi' changed from 96 in /tmp/.rdmd/rdmd-table.d-403917940996C846133B5FCD56447466/table.o to 100 in /tmp/.rdmd/rdmd-table.d-403917940996C846133B5FCD56447466/table.o ??? Note: this is just a warning, program runs fine anyway. Denis -- _ vita es estrany spir.wikidot.com
Re: Range violation error in the code
-Christian Manning wrote: >Seems like Node*[] pointers needs to have a defined length before >allocating to an index as adding "++pointers.length;" before >"pointers[i]=n;" makes it work fine. Thanks, it works...! -Denis wrote: >There is no node in pointers as of now, thus pointers[i] can only be a range >violation, whatever i (even 0, which should point to the *first* node). > pointers[i]=n; >would *change* the current element number i. To put a *new* node into pointers, >if that's what you intended, use the '~' appending operator (here in version >>'~='); > pointers ~= n; Yes, that's exactly what I wanted to do. Thanks...!
Re: Range violation error in the code
On Tue, 12 Apr 2011 08:20:20 -0400, Ishan Thilina
wrote:
I can compile the following code. But when I run the program it gives me
a
"core.exception.RangeError@untitled(34): Range violation
" error.
The code is as follows.
"
import std.stdio;
int main(char[][] args)
{
struct Node{
int _value;
Node* _next,_prev,_up,_down;
}
Node*[] pointers;
int i=0;
auto n=new Node;
pointers[i]=n;
return 0;
}
"
Here's the error.
"
core.exception.RangeError@untitled(34): Range violation
/home/ishan/untitled(onRangeError+0x28) [0x8098a08]
/home/ishan/untitled(_d_array_bounds+0x16) [0x80968c6]
/home/ishan/untitled(_D8untitled7__arrayZ+0x12) [0x8094332]
/home/ishan/untitled(_Dmain+0x35) [0x8094309]
/home/ishan/untitled(_D2rt6dmain24mainUiPPaZi7runMainMFZv+0x1a)
[0x8096a26]
/home/ishan/untitled(_D2rt6dmain24mainUiPPaZi7tryExecMFMDFZvZv+0x20)
[0x80969b8]
/home/ishan/untitled(_D2rt6dmain24mainUiPPaZi6runAllMFZv+0x32)
[0x8096a6a]
/home/ishan/untitled(_D2rt6dmain24mainUiPPaZi7tryExecMFMDFZvZv+0x20)
[0x80969b8]
/home/ishan/untitled(main+0x94) [0x8096964]
/lib32/libc.so.6(__libc_start_main+0xe7) [0xf7613ce7]
/home/ishan/untitled() [0x8094221]
"
As it seems the problem is with the line "pointers[i]=n". What's wrong
here? :s
An array does not dynamically adjust its length when you assign an
element, you have to assign the length explicitly before-hand. Some
dynamic languages do this (like Javascript), but not D.
You can achieve this with an associative array:
Node*[int] pointers;
However, iterating an AA does not guarantee order. So it depends on your
requirements.
-Steve
Re: Should writef try to statically check for format specifiers?
On Mon, 11 Apr 2011 16:35:39 -0400, Andrej Mitrovic wrote:
There is a bug here:
import std.stdio;
void main()
{
int index;
writef("The index is", index);
}
Actually I found this bug in some example code:
http://d.puremagic.com/issues/show_bug.cgi?id=5836
writef is missing a format specifier. But it still accepts this code.
Is it possible for writef to statically check whether there's a format
specifier, assuming there's multiple arguments and the first argument is
a string literal?
I realize runtime checks would be out of the question, but I'm looking
for compile-time checks when it's possible to do so.
Why would runtime checks be out of the question? You are already parsing
the string at runtime, why can't it say "hey, I processed the whole format
string, but I have these arguments left over"? Would be a simple if
statement...
A compile-time check would be nice, but you'd have to pass it as a
compile-time argument (i.e. a template parameter), which would be
not-so-nice.
What would be nice is if the compiler could check when you give it a
string literal, and resort to runtime checks when it was a variable. I
don't think that's possible, however.
-Steve
Re: Range violation error in the code
On 04/12/2011 02:20 PM, Ishan Thilina wrote:
I can compile the following code. But when I run the program it gives me a
"core.exception.RangeError@untitled(34): Range violation
" error.
The code is as follows.
"
import std.stdio;
int main(char[][] args)
{
struct Node{
int _value;
Node* _next,_prev,_up,_down;
}
Node*[] pointers;
int i=0;
auto n=new Node;
pointers[i]=n;
return 0;
}
"
Here's the error.
"
core.exception.RangeError@untitled(34): Range violation
[...]
As it seems the problem is with the line "pointers[i]=n". What's wrong here? :s
There is no node in pointers as of now, thus pointers[i] can only be a range
violation, whatever i (even 0, which should point to the *first* node).
pointers[i]=n;
would *change* the current element number i. To put a *new* node into pointers,
if that's what you intended, use the '~' appending operator (here in version '~=');
pointers ~= n;
Denis
--
_
vita es estrany
spir.wikidot.com
Re: Range violation error in the code
On 12/04/2011 13:20, Ishan Thilina wrote:
I can compile the following code. But when I run the program it gives me a
"core.exception.RangeError@untitled(34): Range violation
" error.
The code is as follows.
"
import std.stdio;
int main(char[][] args)
{
struct Node{
int _value;
Node* _next,_prev,_up,_down;
}
Node*[] pointers;
int i=0;
auto n=new Node;
pointers[i]=n;
return 0;
}
"
Here's the error.
"
core.exception.RangeError@untitled(34): Range violation
/home/ishan/untitled(onRangeError+0x28) [0x8098a08]
/home/ishan/untitled(_d_array_bounds+0x16) [0x80968c6]
/home/ishan/untitled(_D8untitled7__arrayZ+0x12) [0x8094332]
/home/ishan/untitled(_Dmain+0x35) [0x8094309]
/home/ishan/untitled(_D2rt6dmain24mainUiPPaZi7runMainMFZv+0x1a) [0x8096a26]
/home/ishan/untitled(_D2rt6dmain24mainUiPPaZi7tryExecMFMDFZvZv+0x20) [0x80969b8]
/home/ishan/untitled(_D2rt6dmain24mainUiPPaZi6runAllMFZv+0x32) [0x8096a6a]
/home/ishan/untitled(_D2rt6dmain24mainUiPPaZi7tryExecMFMDFZvZv+0x20) [0x80969b8]
/home/ishan/untitled(main+0x94) [0x8096964]
/lib32/libc.so.6(__libc_start_main+0xe7) [0xf7613ce7]
/home/ishan/untitled() [0x8094221]
"
As it seems the problem is with the line "pointers[i]=n". What's wrong here? :s
Seems like Node*[] pointers needs to have a defined length before
allocating to an index as adding "++pointers.length;" before
"pointers[i]=n;" makes it work fine.
Range violation error in the code
I can compile the following code. But when I run the program it gives me a
"core.exception.RangeError@untitled(34): Range violation
" error.
The code is as follows.
"
import std.stdio;
int main(char[][] args)
{
struct Node{
int _value;
Node* _next,_prev,_up,_down;
}
Node*[] pointers;
int i=0;
auto n=new Node;
pointers[i]=n;
return 0;
}
"
Here's the error.
"
core.exception.RangeError@untitled(34): Range violation
/home/ishan/untitled(onRangeError+0x28) [0x8098a08]
/home/ishan/untitled(_d_array_bounds+0x16) [0x80968c6]
/home/ishan/untitled(_D8untitled7__arrayZ+0x12) [0x8094332]
/home/ishan/untitled(_Dmain+0x35) [0x8094309]
/home/ishan/untitled(_D2rt6dmain24mainUiPPaZi7runMainMFZv+0x1a) [0x8096a26]
/home/ishan/untitled(_D2rt6dmain24mainUiPPaZi7tryExecMFMDFZvZv+0x20) [0x80969b8]
/home/ishan/untitled(_D2rt6dmain24mainUiPPaZi6runAllMFZv+0x32) [0x8096a6a]
/home/ishan/untitled(_D2rt6dmain24mainUiPPaZi7tryExecMFMDFZvZv+0x20) [0x80969b8]
/home/ishan/untitled(main+0x94) [0x8096964]
/lib32/libc.so.6(__libc_start_main+0xe7) [0xf7613ce7]
/home/ishan/untitled() [0x8094221]
"
As it seems the problem is with the line "pointers[i]=n". What's wrong here? :s
