Tried C++ to D. Wrong result.
I tried translate C++ programm to D, but result is different. original: https://github.com/urraka/alpha-bleeding/blob/master/src/alpha-bleeding.cpp result (with removed alpha): https://github.com/urraka/alpha-bleeding/blob/master/media/alpha-bleeding-opaque.png my: https://pastebin.com/GzZQ7WHt result (with removed alpha): https://www.dropbox.com/s/xbjphlievboslv2/original-2.png What did I wrong? P.S. Also on an one image it was crashed at line 63 (range violation) https://pastebin.com/TenGusw0 so I added ((index + 3) < N) into condition.
Re: Tried C++ to D. Wrong result.
On Monday, 27 November 2017 at 14:08:27 UTC, Dmitry wrote: I tried translate C++ programm to D, but result is different. original: https://github.com/urraka/alpha-bleeding/blob/master/src/alpha-bleeding.cpp result (with removed alpha): https://github.com/urraka/alpha-bleeding/blob/master/media/alpha-bleeding-opaque.png my: https://pastebin.com/GzZQ7WHt result (with removed alpha): https://www.dropbox.com/s/xbjphlievboslv2/original-2.png What did I wrong? P.S. Also on an one image it was crashed at line 63 (range violation) https://pastebin.com/TenGusw0 so I added ((index + 3) < N) into condition. First I'd make sure that what you get out of dlib load is the same as the c++ version gets. Just use standard debugging techniques.
Re: Tried C++ to D. Wrong result.
Did you confirm that the image was loaded originally correctly?
Re: Tried C++ to D. Wrong result.
On Monday, 27 November 2017 at 14:14:12 UTC, rikki cattermole wrote: Did you confirm that the image was loaded originally correctly? Yes. This image was used: https://github.com/urraka/alpha-bleeding/blob/master/media/original.png
Re: Floating point types default to NaN?
On 11/25/17 5:13 PM, Adam D. Ruppe wrote: On Saturday, 25 November 2017 at 16:16:52 UTC, A Guy With a Question wrote: If D chooses it's defaults to make errors stick out, why not just error at declaration if they don't explicitly set it to something. It technically did: https://dlang.org/spec/function.html#local-variables "It is an error to use a local variable without first assigning it a value. The implementation may not always be able to detect these cases. Other language compilers sometimes issue a warning for this, but since it is always a bug, it should be an error. " But that paragraph was never implemented (it is a bit easier said than done to actually detect given if conditions and stuff too, especially in the early days of D when the compiler didn't even make any effort to track such things, though it does now...). The compiler author took the easy way out of initializing them to invalid values instead. While it is more realistic to implement technically now than it was years ago when the current behavior got in, I think we're at the point now that so many people use it as a convenience thing on ints and nulls that there'd be hell to pay if the compiler actually started calling it an error :( I rely on the default value initialization all the time! I don't know how that would jive with structs, since they are technically local variables, but usually are valid without initialization. What about AAs? Would you have to do = []? -Steve
Re: Floating point types default to NaN?
On Monday, 27 November 2017 at 14:58:42 UTC, Steven Schveighoffer wrote: I rely on the default value initialization all the time! I don't know how that would jive with structs, since they are technically local variables, but usually are valid without initialization. Yes, indeed, me too. I like it now. But there might be a compromise that is still workable: let structs and ints (and bytes, short, etc) be exceptions and not issue an error there. But then conservatively check other types. If the compiler sees any read before any write, issue the error. Otherwise, keep the status quo. That's fit the spec and catch real bugs more often than false positives. Though, I'm in no ruse to see that implemented either, overall I am meh on it. What about AAs? Would you have to do = []? they could be an exception too, but you could do = null (= [] won't pass the type check lol)
Re: Tried C++ to D. Wrong result.
On Monday, 27 November 2017 at 17:01:29 UTC, Adam D. Ruppe wrote: In the C++ version they are declared std::vector pending; std::vector pendingNext; Ah, indeed. I thought that pending.reserve(N); pendingNext.reserve(N); initializes them (last time I used C++ about 17 years ago...) I suspect you will get better results by just making the D decls and leave the rest of the code the same and see what happens. It fixed a delay (you can see it on video I posted before), but result is same.
Re: Tried C++ to D. Wrong result.
On Monday, 27 November 2017 at 14:08:27 UTC, Dmitry wrote: https://pastebin.com/GzZQ7WHt The first thing that jumped out to me is this: size_t[] pending = new size_t[N]; size_t[] pendingNext = new size_t[N]; That's giving it N elements of zero, then you append to it later with pending ~= i; In the C++ version they are declared std::vector pending; std::vector pendingNext; which doesn't put empty elements at it. I suspect you will get better results by just making the D decls size_t[] pending; size_t[] pendingNext; and leave the rest of the code the same and see what happens.
Re: Floating point types default to NaN?
On Saturday, 25 November 2017 at 09:39:15 UTC, Dave Jones wrote:
I mean at the end of the day, that would turn a run time error
into a compile time error which is a good thing isnt it?
Debatable in this case. Consider:
string servicePhoneNumber;
final switch (car.manufacturer) //an enumerated value.
{ case CarMaker.Audi:
servicePhoneNumber = staff["Dorff Hans"].phone;
//...
break;
case CarMaker.Skoda:
servicePhoneNumber = staff["Telegin Svetlana"].phone;
//...
break;
//more cases ...
}
Here it is arguably unnecessary typing if you had to manually set
servicePhoneNumber to "" or something at start. And in case of
structs it tends to be a verbose thing to manually set one to
it's init value.
Re: Tried C++ to D. Wrong result.
On Monday, 27 November 2017 at 14:35:39 UTC, Stefan Koch wrote: First I'd make sure that what you get out of dlib load is the same as the c++ version gets. Just use standard debugging techniques. Yes, it's same. As you can see, the top-middle area of the result is same. I wrote a video of process (D version, every 100-th frame) https://www.dropbox.com/s/hcw1x4cwjou69su/video.mpg C++ version: https://www.dropbox.com/s/i7xpa5mzddpz6nu/video_orig.mpg
Re: Floating point types default to NaN?
On Monday, 27 November 2017 at 16:04:14 UTC, Dukc wrote: Debatable in this case. Consider: string servicePhoneNumber; final switch (car.manufacturer) //an enumerated value. Well, the compiler can see it is initialized before being read again later, so that *should* pass the check (at least conservatively- the spec is flexible enough to let the compiler not catch them all).
Re: How you guys go about -BetterC Multithreading?
On Friday, 10 November 2017 at 11:55:57 UTC, Guillaume Piolat wrote: For now we do have some @nogc alternatives for mutex, condition variables, thread-pool, file reading, etc... (dplug:core package) for use with the runtime disabled - the middle ground that's way more usable than -betterC. They may, or not, be applicable to -betterC. Your thread module (among others) is an amazing read and a very nice starting point for my endeavor. Thanks for pointing me in this direction!
Re: Tried C++ to D. Wrong result.
On Monday, 27 November 2017 at 18:40:41 UTC, Ali Çehreli wrote: So, it looks like the original code was accessing out of bounds and probably that's why you inserted the ((index + 3) < N) check in the D version because D was catching that error at runtime. Yes, it is. Which of course would skip the body of the if block, causing a difference from the original result. Yes. I fixed it in C++ version also and now both versions works same.
Re: On Attributes
On Mon, Nov 27, 2017 at 07:10:04PM +, A Guy With a Question via
Digitalmars-d-learn wrote:
> Hi again!
>
> I've been trying to do my best to write idiomatically. One thing that
> is bugging me is having to mark up all of my declarations with
> attributes. Which means I'm having to remember them all. It's a bit
> much to keep in my head with every function. Is there a good way to
> reverse this (imply the attributes by default) and then turn them off
> explicitly? Like declaring them at the top of the file so they apply
> to everything below?
[...]
You can declare attributes at the top of the file by writing "attr:"
where "attr" is pure, nothrow, @nogc, etc..
However, there is currently no way to negate these attributes afterwards.
An alternative is to let the compiler do the hard work for you by
templatizing your code. Template functions and members of templated
aggregates (structs and classes) trigger attribute inference. You can
turn non-template functions into template functions by adding an empty
list of compile-time parameters:
int myfunc()(int x, int y) { ... }
This has the added advantage that if myfunc is never actually referenced
elsewhere in the code, it won't even be compiled into the executable.
Of course, this is not a perfect solution, since you can't use it if for
whatever reason your function must not be a template. One area is class
methods that must be overridden by derived classes, which can't be
template methods. There's no way around specifying explicit attributes
in that case.
T
--
The fact that anyone still uses AOL shows that even the presence of options
doesn't stop some people from picking the pessimal one. - Mike Ellis
Re: Tried C++ to D. Wrong result.
On Monday, 27 November 2017 at 17:21:05 UTC, Dmitry wrote: It fixed a delay (you can see it on video I posted before), but result is same. It seems I found the problem. C++ version (line 93): if (image[index + 3] != 0) I changed to if (image[index] != 0) and it works. I don't understand why there was used "+ 3" (and why it works in C++ version). Thank you all for help.
Re: Tried C++ to D. Wrong result.
On 11/27/2017 10:25 AM, Dmitry wrote: > On Monday, 27 November 2017 at 17:21:05 UTC, Dmitry wrote: >> It fixed a delay (you can see it on video I posted before), but result >> is same. > > It seems I found the problem. > > C++ version (line 93): > if (image[index + 3] != 0) > > I changed to > if (image[index] != 0) > > and it works. > > I don't understand why there was used "+ 3" (and why it works in C++ > version). So, it looks like the original code was accessing out of bounds and probably that's why you inserted the ((index + 3) < N) check in the D version because D was catching that error at runtime. // C++ if (image[index + 3] != 0) // D if (((index + 3) < N) && (data[index + 3] != 0)) Which of course would skip the body of the if block, causing a difference from the original result. Ali
Re: Tried C++ to D. Wrong result.
On 11/27/2017 10:47 AM, Dmitry wrote: > On Monday, 27 November 2017 at 18:40:41 UTC, Ali Çehreli wrote: > >> So, it looks like the original code was accessing out of bounds and >> probably that's why you inserted the ((index + 3) < N) check in the D >> version because D was catching that error at runtime. > Yes, it is. This is exactly the kind of bug Walter wanted to avoid when leaving C's arrays behind. (This includes C++'s std::vector because vector::operator[] is permissive. (To be safe, one needs to use .at() or check indexes explicitly.)) So, as advertised, port your programs to D and the results will likely be more correct. I like it! :) Ali P.S. I think you have an unnecessary 'ref' on the D version because a slice is already a reference to elements: // C++ void alpha_bleeding(unsigned char *image, int width, int height) // D private void alphaBleeding(ref ubyte[] data, int width, int height) You would need that 'ref' if you wanted to modify the original array itself by e.g. adding elements to it.
On Attributes
Hi again! I've been trying to do my best to write idiomatically. One thing that is bugging me is having to mark up all of my declarations with attributes. Which means I'm having to remember them all. It's a bit much to keep in my head with every function. Is there a good way to reverse this (imply the attributes by default) and then turn them off explicitly? Like declaring them at the top of the file so they apply to everything below? Thanks!
Re: On Attributes
On 11/27/17 2:10 PM, A Guy With a Question wrote:
Hi again!
I've been trying to do my best to write idiomatically. One thing that is
bugging me is having to mark up all of my declarations with attributes.
Which means I'm having to remember them all. It's a bit much to keep in
my head with every function. Is there a good way to reverse this (imply
the attributes by default) and then turn them off explicitly? Like
declaring them at the top of the file so they apply to everything below?
You can have some degree of success with global application and inference.
Note that ALL attributes can be applied in one of 3 ways:
1. At the declaration:
@safe int foo();
@safe int bar();
2. In a scope:
@safe {
int foo();
int bar();
}
3. as a label:
@safe:
int foo();
int bar();
There are some limitations, such that it will NOT apply to functions
inside classes or structs. Also, attributes without an opposite
attribute (e.g. pure) cannot be undone once you apply at the top with a
label.
Note that templates automatically infer attributes, you do not have to
write them:
T foo(T)() {... } // implies @safe if possible
Functions which return auto also imply attributes:
auto foo() {... } // implies @safe if possible
The reason here is because the implementation of the function must be
available to properly compile, therefore the compiler can infer the
proper attributes.
Hope this helps.
-Steve
Re: On Attributes
On Monday, 27 November 2017 at 19:10:04 UTC, A Guy With a One thing that is bugging me is having to mark up all of my declarations with attributes. Meh, you could also just ignore the attribute crap. Only reason I ever mess with them is if someone who is using them tries to use my code... otherwise you can pretend the spam doesn't exist and be more productive.
Re: On Attributes
On Monday, 27 November 2017 at 19:41:03 UTC, Adam D. Ruppe wrote: On Monday, 27 November 2017 at 19:10:04 UTC, A Guy With a One thing that is bugging me is having to mark up all of my declarations with attributes. Meh, you could also just ignore the attribute crap. Only reason I ever mess with them is if someone who is using them tries to use my code... otherwise you can pretend the spam doesn't exist and be more productive. Yeah, I'm leaning towards that direction. It seems they could have been useful if they were the default. But opting into them doesn't seem as useful, unfortunately. I'll probably continue fiddling with them, but I might just abandon using them.
Re: Is variable void?
On Tuesday, 28 November 2017 at 05:10:39 UTC, bauss wrote: null != void "initialized or not?" != void
Re: Tried C++ to D. Wrong result.
On Monday, 27 November 2017 at 19:01:28 UTC, Ali Çehreli wrote: P.S. I think you have an unnecessary 'ref' on the D version because a slice is already a reference to elements: Fixed, thank you.
Re: Is variable void?
On Tuesday, 28 November 2017 at 05:10:39 UTC, bauss wrote: null != void also...void is a completely useless concept for initialisation. what can you determine about the nothingness of void? ... nothing. writeln(typeof(void).stringof); // ?? what do I know now? nothing. vs Nullable!int x; writeln(typeof(x).stringof); // Nullable!int .. now I know something.
Re: Is variable void?
On Monday, 27 November 2017 at 02:12:40 UTC, codephantom wrote:
On Saturday, 25 November 2017 at 15:34:21 UTC, John Chapman
wrote:
Is there any way of determining whether a variable has been
initialized or not? For example, if something is declared like
this:
int x = void;
can I check if it's void before I use it, say, in a function
it's been passed to?
// --
module test;
import std.stdio;
import std.typecons; // see:
https://dlang.org/phobos/std_typecons.html#Nullable
void main()
{
Nullable!int x; // requires: import std.typecons
assert(x.isNull);
writeln("x is ", x);
x = 1;
assert(!x.isNull);
writeln("x is ", x);
x.nullify(); // Forces x back to a null state.
assert(x.isNull);
writeln("x is ", x);
}
// --
null != void
Re: Floating point types default to NaN?
On Saturday, 25 November 2017 at 22:13:43 UTC, Adam D. Ruppe wrote: It technically did: https://dlang.org/spec/function.html#local-variables "It is an error to use a local variable without first assigning it a value. The implementation may not always be able to detect these cases. Other language compilers sometimes issue a warning for this, but since it is always a bug, it should be an error. " But that paragraph was never implemented (it is a bit easier said than done to actually detect given if conditions and stuff too, especially in the early days of D when the compiler didn't even make any effort to track such things, though it does now...). The compiler author took the easy way out of initializing them to invalid values instead. WOW!! I am shocked to learn this. All this time, I though it was a design oversight. I think I'm going to implement a feature gate to require explicit initialization. It would be better to be strict up front and relax it as flow control analysis becomes more mature. Mike
Re: On Attributes
On Monday, 27 November 2017 at 20:07:08 UTC, A Guy With a Question wrote: On Monday, 27 November 2017 at 19:41:03 UTC, Adam D. Ruppe wrote: On Monday, 27 November 2017 at 19:10:04 UTC, A Guy With a One thing that is bugging me is having to mark up all of my declarations with attributes. Meh, you could also just ignore the attribute crap. Only reason I ever mess with them is if someone who is using them tries to use my code... otherwise you can pretend the spam doesn't exist and be more productive. Yeah, I'm leaning towards that direction. It seems they could have been useful if they were the default. But opting into them doesn't seem as useful, unfortunately. I'll probably continue fiddling with them, but I might just abandon using them. I also rarely put the attributes (although sincerely i think that my funcs are pure 99% of them time) but take care because recently it was announced that better code will be generated if there are scope(exit) / try-finally inside nothrow funcs: https://forum.dlang.org/thread/ovbduq$m3a$1...@digitalmars.com
