Thread overview | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
|
June 11, 2013 Variable shadowing bug? | ||||
---|---|---|---|---|
| ||||
Piece of code: https://github.com/denizzzka/DSFML/blob/237a752988c76e3c2f63ed03ae12558823ce43ec/dsfml/system.d#L53 ============================ Time getElapsedTime() const { auto r = sfClock_getElapsedTime(sfPtr); static assert( is (typeof(r) == sfTime) ); // added for debug return Time(r); } [...] struct sfTime // accidentally defined below in this file { long microseconds; } ============================ sfClock_getElapsedTime return type actually defined in the another file, typeid = _D45TypeInfo_S8derelict5sfml211systemtypes6sfTime6__initZ compilation causes: dsfml/system.d(54): Error: static assert (is(sfTime == sfTime)) is false This message looks weird. I am spent hour to find this bug. :-( |
June 11, 2013 Re: Variable shadowing bug? | ||||
---|---|---|---|---|
| ||||
Posted in reply to denizzz | denizzz:
> This message looks weird. I am spent hour to find this bug. :-(
Why aren't you just using code like this?
sfTime r = sfClock_getElapsedTime(sfPtr);
return Time(r);
I don't fully understand, it seems a diagnostic problem.
Please create a minimal test case that shows the problem. Maybe there is something for Bugzilla here.
Bye,
bearophile
|
June 11, 2013 Re: Variable shadowing bug? | ||||
---|---|---|---|---|
| ||||
Posted in reply to denizzz | On Tuesday, 11 June 2013 at 08:08:03 UTC, denizzz wrote: > > sfClock_getElapsedTime return type actually defined in the another file, typeid = _D45TypeInfo_S8derelict5sfml211systemtypes6sfTime6__initZ > > compilation causes: > > dsfml/system.d(54): Error: static assert (is(sfTime == sfTime)) is false > > This message looks weird. I am spent hour to find this bug. :-( This is essentially what you are doing: static assert( is (derelict.sfml2.system.types.sfTime == dsfml.system.sfTime) ); They are two different types. It should pass you change your assert to this: is(typeof(r)==derelict.sfml2.system.types.sfTime) On another note not related to your problem, you have a redundant import at the top of your system module. derelict.sfml2.system publicly imports the system.types module, so you don't have to. |
June 11, 2013 Re: Variable shadowing bug? | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | On Tuesday, 11 June 2013 at 11:22:15 UTC, bearophile wrote:
> denizzz:
>
>> This message looks weird. I am spent hour to find this bug. :-(
>
> Why aren't you just using code like this?
>
> sfTime r = sfClock_getElapsedTime(sfPtr);
> return Time(r);
>
sfTime* r = sfClock_getElapsedTime(sfPtr);
says what sfTime can not be implictly converted to sfTime
|
June 12, 2013 Re: Variable shadowing bug? | ||||
---|---|---|---|---|
| ||||
Posted in reply to denizzz | On Tuesday, 11 June 2013 at 16:37:18 UTC, denizzz wrote: > > sfTime* r = sfClock_getElapsedTime(sfPtr); > > says what sfTime can not be implictly converted to sfTime sfClock_getElapsedTime does not return a pointer. You're going to continue to have type mismatches because you are trying to use two different types interchangeably. Your sfTime declared in your dsfml.system module is *not* the same type as the one declared in Derelict. sfClock_getElapsedTime does *not* return a dsfml.system.sftime, but a derelict.sfml2.system.types.sfTime. I strongly suggest you get rid of your redundant types and just publicly import derelict.sfml2.system.types to avoid this sort of error. |
June 12, 2013 Re: Variable shadowing bug? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike Parker | On Wednesday, 12 June 2013 at 01:17:50 UTC, Mike Parker wrote: > On Tuesday, 11 June 2013 at 16:37:18 UTC, denizzz wrote: > >> >> sfTime* r = sfClock_getElapsedTime(sfPtr); >> >> says what sfTime can not be implictly converted to sfTime > > sfClock_getElapsedTime does not return a pointer. > > You're going to continue to have type mismatches because you are trying to use two different types interchangeably. Ok, but why compiler says that types of these types is equal? It should say something about shadowing of variable? > Your sfTime declared in your dsfml.system module is *not* the same type as the one declared in Derelict. I understand that and already removed this code. (It was left by mistake - I am changing SFML-D for use with Derelict3) > sfClock_getElapsedTime does *not* return a dsfml.system.sftime, but a derelict.sfml2.system.types.sfTime. I strongly suggest you get rid of your redundant types and just publicly import derelict.sfml2.system.types to avoid this sort of error. "sfTime", not "sftime". /usr/include/dmd/derelict/sfml2/systemfunctions.d: alias nothrow sfTime function(const(sfClock*) clock) da_sfClock_getElapsedTime; |
June 12, 2013 Re: Variable shadowing bug? | ||||
---|---|---|---|---|
| ||||
Posted in reply to denizzz | On Wednesday, 12 June 2013 at 02:01:27 UTC, denizzz wrote: > On Wednesday, 12 June 2013 at 01:17:50 UTC, Mike Parker wrote: >> On Tuesday, 11 June 2013 at 16:37:18 UTC, denizzz wrote: > Ok, but why compiler says that types of these types is equal? ...that typeids of these types are equal? |
June 12, 2013 Re: Variable shadowing bug? | ||||
---|---|---|---|---|
| ||||
Posted in reply to denizzz | On Tuesday, 11 June 2013 at 16:37:18 UTC, denizzz wrote:
> On Tuesday, 11 June 2013 at 11:22:15 UTC, bearophile wrote:
>> denizzz:
>>
>>> This message looks weird. I am spent hour to find this bug. :-(
>>
>> Why aren't you just using code like this?
>>
>> sfTime r = sfClock_getElapsedTime(sfPtr);
>> return Time(r);
>>
>
>
> sfTime* r = sfClock_getElapsedTime(sfPtr);
>
> says what sfTime can not be implictly converted to sfTime
says what sfTime* can not be implictly converted to sfTime*
|
Copyright © 1999-2021 by the D Language Foundation