Re: Function calls
"Michel Fortin" wrote in message news:hjqdca$2ne...@digitalmars.com... On 2010-01-27 15:54:42 -0500, Andrei Alexandrescu said: Now @property is in. That has created (as I had anticipated) the unresolved issue of choosing between @property or just function for any given parameterless function. Also I need to litter my code with @property. To this day I am not sure whether we made the right decision. Well, perhaps it'd be better if it was 'property' instead of '@property'. I find the distinction between keywords and attributes to be pretty arbitrary, almost illogical. I'm on the side that attributes (those keywords starting with @) should be reserved to things you can ignore entirely without preventing the program from working. For instance, remove all @safe and @trusted attributes from a program and it still works with no change in behaviour (except for when an error occurs). 'nothrow', 'pure', 'final', 'deprecated' should be attributes; '@property' should be a regular keyword. Protection attributes could be made attributes too since if you remove them all everything still works. So I think attributes should be reserved to non-essential but useful stuff in the language, generally those things adding restrictions without changing the semantics. Yes, agreed, there should be some more thought put into how keywords work so that things are consistent and make sense. It seems strange that new keywords are preceded by @, but older ones are not. However, aesthetically, I prefer the @ to a double underscore. Perhaps __gshared could be @gshared or even @shared. -Craig -Craig
Safe interval pointer [Was: Re: Perfect hashing for string switch]
Matti Niemenmaa:
> Your test6 is invalid: it reads beyond the bounds of the given array.
> For example with input "th", it will check whether the third character
> is 'i'; but the length of the array is only 2, so it shouldn't be doing
> that.
Shame on me, I am sorry -.- Thank you. I will try to improve the code later.
The good thing is that D2 allows me to implement something to catch that kind
of out-of-range pointer errors at run-time (D1 is not good enough here). That
code at the bottom is not well tested yet, so it can contain many bugs. And
probably it's not const-aware yet (if someone has suggestions to improve it I
will appreciate them). In programs a certain percentage of pointers run inside
an interval of memory, so something like this can be useful. Do you think this
is (once well debugged and improved) useful for Phobos2?
Up sides:
- this code seems to work and catchs the bug at runtime in the test6() function
I've written.
Downsides:
- currently compiled with D2 the test6() gets slower even when the code is not
in debug release. Future D2 compilers will need to reduce to zero or near zero
this overhead, so safer pointers can be used more freely.
Possible future improvements: use an "interval tree" where necessary to quickly
find if the pointer is inside more than one interval. This is probably a quite
less common need.
Bye,
bearophile
-
import std.stdio: writeln, write;
template IsMutable(T) {
enum bool IsMutable = __traits(compiles, { T a; a = T.init; });
}
unittest { // of IsMutable(T)
auto s1 = "hello1";
static assert( !IsMutable!(typeof(s1[0])) );
char[] s2 = cast(char[])"hello2";
static assert( IsMutable!(typeof(s2[0])) );
}
/// * NOT tested well enough yet *
struct IntervalPtr(T) {
T* ptr; // can be null
debug {
private T* start_ptr; // can't be null if present
private T* end_ptr; // can't be null if present
invariant() {
assert(start_ptr != null);
assert(end_ptr != null);
assert(start_ptr <= end_ptr);
assert(ptr == null || (ptr >= start_ptr && ptr < end_ptr));
}
} else {
this(T* aptr) {
this.ptr = aptr;
}
}
this(T* start, T* end) {
this.ptr = start;
debug {
assert(start != null);
assert(end != null);
assert(start <= end);
this.start_ptr = start;
this.end_ptr = end;
}
}
this(T* start, T* end, T* aptr) {
this.ptr = aptr;
debug {
assert(end != null);
assert(end != null);
assert(start <= end);
if (aptr != null) {
assert(aptr >= start);
assert(aptr < end);
}
this.start_ptr = start;
this.end_ptr = end;
}
}
T opStar() {
return *this.ptr;
}
void opPostInc() {
debug assert(this.ptr < (this.end_ptr - 1));
this.ptr++;
}
void opPostDec() {
debug assert(this.ptr > this.start_ptr);
this.ptr--;
}
void opAddAssign(size_t i) {
debug assert(this.ptr < (this.end_ptr - i));
this.ptr += i;
}
void opSubAssign(size_t i) {
debug assert(this.ptr >= (this.start_ptr + i));
this.ptr -= i;
}
void opAssign(T* other_ptr) {
debug {
if (other_ptr != null) {
assert(other_ptr >= this.start_ptr);
assert(other_ptr < this.end_ptr);
}
}
this.ptr = other_ptr;
}
void opAssign(IntervalPtr other) {
debug {
assert(other.start_ptr != null);
assert(other.end_ptr != null);
assert(other.end_ptr != null);
if (other.ptr != null) {
assert(other.ptr >= other.start_ptr);
assert(other.ptr < other.end_ptr);
}
this.start_ptr = other.start_ptr;
this.end_ptr = other.end_ptr;
}
this.ptr = other.ptr;
}
const bool opEquals(ref const(IntervalPtr) other) {
return this.ptr == other.ptr;
}
/*ref ?*/ T opIndex(size_t i) {
debug {
assert((this.ptr + i) >= this.start_ptr);
assert((this.ptr + i) < this.end_ptr);
}
return this.ptr[i];
}
static if (IsMutable!T) {
void opIndexAssign(T value, size_t i) {
debug {
assert((this.ptr + i) >= this.start_ptr);
assert((this.ptr + i) < this.end_ptr);
}
this.ptr[i] = value;
}
}
}
IntervalPtr!T intervalPtr(T)(/*inout ?*/ T[] arr) {
debug
return IntervalPtr!T(arr.ptr, arr.ptr + arr.length);
else
return IntervalPtr!T(arr.ptr);
}
IntervalPtr!T intervalPtr(T)(/*inout ?*/ T[] arr, T* aptr) {
debug
return IntervalPtr!T(arr.ptr, arr.ptr +
Re: Function calls
On Wed, 27 Jan 2010 23:50:26 +0300, Nick Sabalausky wrote: "downs" wrote in message news:hjq2l1$1s5...@digitalmars.com... Adam D. Ruppe wrote: On Wed, Jan 27, 2010 at 06:34:57PM +0100, Pelle Månsson wrote: I disagree, I find the function calls without the () to be really prettifying. But maybe that's just me. I don't think that it causes serious bugs, you would see that it's an integer the moment you try and use it. It also helps changing code from/to functions. I really like this feature, and would miss it should it go away. Me too. Me three. Meh, I hate it hate it hate it hate it hate it. I'd dance on the feature's grave. So I guess you could say I wouldn't miss it. ;) Me too!
Re: Function calls
On 2010-01-27 15:54:42 -0500, Andrei Alexandrescu said: Now @property is in. That has created (as I had anticipated) the unresolved issue of choosing between @property or just function for any given parameterless function. Also I need to litter my code with @property. To this day I am not sure whether we made the right decision. Well, perhaps it'd be better if it was 'property' instead of '@property'. I find the distinction between keywords and attributes to be pretty arbitrary, almost illogical. I'm on the side that attributes (those keywords starting with @) should be reserved to things you can ignore entirely without preventing the program from working. For instance, remove all @safe and @trusted attributes from a program and it still works with no change in behaviour (except for when an error occurs). 'nothrow', 'pure', 'final', 'deprecated' should be attributes; '@property' should be a regular keyword. Protection attributes could be made attributes too since if you remove them all everything still works. So I think attributes should be reserved to non-essential but useful stuff in the language, generally those things adding restrictions without changing the semantics. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: Function calls
On 01/27/2010 09:54 PM, Andrei Alexandrescu wrote: downs wrote: Adam D. Ruppe wrote: On Wed, Jan 27, 2010 at 06:34:57PM +0100, Pelle M�nsson wrote: I disagree, I find the function calls without the () to be really prettifying. But maybe that's just me. I don't think that it causes serious bugs, you would see that it's an integer the moment you try and use it. It also helps changing code from/to functions. I really like this feature, and would miss it should it go away. Me too. Me three. There was a long discussion about that, which prompted the addition of @property. I was in the an...@property camp, but had understanding and sympathy for the ambiguity issues involved without @property. There was a vote in which as far as I recall the p...@property camp was beaten to a tender pulp. Now @property is in. That has created (as I had anticipated) the unresolved issue of choosing between @property or just function for any given parameterless function. Also I need to litter my code with @property. To this day I am not sure whether we made the right decision. Andrei Not just parameterless functions, but functions operating on arrays as well. And mostly anything, if I recall correctly.
Re: Function calls
On 01/27/2010 09:53 PM, boscop wrote: On 27.01.2010 20:54, Michel Fortin wrote: On 2010-01-27 14:01:56 -0500, downs said: Adam D. Ruppe wrote: On Wed, Jan 27, 2010 at 06:34:57PM +0100, Pelle M�nsson wrote: I really like this feature, and would miss it should it go away. Me too. Me three. I'll miss the feature too. But I think it's the right thing to do because otherwise you can't have properties that behave like properties when returning a callable type. It may be optically pleasant sometimes to be able to omit the parens, but beside the problem with returning a callable type it's also easier to spot where computations happen instead of fast access to properties, even more in complex expressions. Of course you can hide a bottleneck in a @property but I'm talking about the normal case here. And it's not hard to type two parens for better readability. I think you're looking for a profiler. I also disagree about the readability part, I dislike line noise.
Re: Google's Go & Exceptions
Nick Sabalausky wrote:
Nick Sabalausky wrote:
""J?r?me M. Berger"" wrote in message
news:hjnrhv$1l0...@digitalmars.com...
Throwing exception inside constructors should be avoided because
then the destructor is never called and you risk leaking like crazy.
That's a risk outside of constructors too. Hence:
scope(failure) {}
- This doesn't exist in C++;
Well, I was really only talking about D. I guess the answer to "Should
throwing exceptions in a constructor be avoided?" is "Depends on the
language." For C++, constructors have historically had a number of tricky
edge cases (though I couldn't really remember what), so I'm not surprised
that throwing exceptions is one of them. For D though, I'm not sure I see
that there's a problem.
The edge cases involve member initialization that throws. The root of
the matter is that in C++ you can't have a type with a guaranteed
nothrow constructor. That makes a lot of things very difficult when it
comes to object composition.
I've aired a number of times the idea that the parameterless constructor
should not throw. That would simplify many issues, but there are still
cases when that doesn't work (nonull!!!)
Andrei
Re: Function calls
downs wrote: Adam D. Ruppe wrote: On Wed, Jan 27, 2010 at 06:34:57PM +0100, Pelle Månsson wrote: I disagree, I find the function calls without the () to be really prettifying. But maybe that's just me. I don't think that it causes serious bugs, you would see that it's an integer the moment you try and use it. It also helps changing code from/to functions. I really like this feature, and would miss it should it go away. Me too. Me three. There was a long discussion about that, which prompted the addition of @property. I was in the an...@property camp, but had understanding and sympathy for the ambiguity issues involved without @property. There was a vote in which as far as I recall the p...@property camp was beaten to a tender pulp. Now @property is in. That has created (as I had anticipated) the unresolved issue of choosing between @property or just function for any given parameterless function. Also I need to litter my code with @property. To this day I am not sure whether we made the right decision. Andrei
Re: Function calls
On 27.01.2010 20:54, Michel Fortin wrote: > On 2010-01-27 14:01:56 -0500, downs said: > >> Adam D. Ruppe wrote: >>> On Wed, Jan 27, 2010 at 06:34:57PM +0100, Pelle Månsson wrote: I really like this feature, and would miss it should it go away. >>> >>> Me too. >> >> Me three. > > I'll miss the feature too. But I think it's the right thing to do > because otherwise you can't have properties that behave like properties > when returning a callable type. > It may be optically pleasant sometimes to be able to omit the parens, but beside the problem with returning a callable type it's also easier to spot where computations happen instead of fast access to properties, even more in complex expressions. Of course you can hide a bottleneck in a @property but I'm talking about the normal case here. And it's not hard to type two parens for better readability.
Re: Function calls
"downs" wrote in message news:hjq2l1$1s5...@digitalmars.com... > Adam D. Ruppe wrote: >> On Wed, Jan 27, 2010 at 06:34:57PM +0100, Pelle Månsson wrote: >>> I disagree, I find the function calls without the () to be really >>> prettifying. >>> >>> But maybe that's just me. >>> >>> I don't think that it causes serious bugs, you would see that it's an >>> integer the moment you try and use it. It also helps changing code >>> from/to functions. >>> >>> I really like this feature, and would miss it should it go away. >> >> Me too. >> > > Me three. Meh, I hate it hate it hate it hate it hate it. I'd dance on the feature's grave. So I guess you could say I wouldn't miss it. ;)
Re: Google's Go & Exceptions
Nick Sabalausky wrote:
>> ""J?r?me M. Berger"" wrote in message
>> news:hjnrhv$1l0...@digitalmars.com...
>>> Throwing exception inside constructors should be avoided because
>>> then the destructor is never called and you risk leaking like crazy.
>>
>> That's a risk outside of constructors too. Hence:
>>
>> scope(failure) {}
>>
>- This doesn't exist in C++;
Well, I was really only talking about D. I guess the answer to "Should
throwing exceptions in a constructor be avoided?" is "Depends on the
language." For C++, constructors have historically had a number of tricky
edge cases (though I couldn't really remember what), so I'm not surprised
that throwing exceptions is one of them. For D though, I'm not sure I see
that there's a problem.
>- Outside of constructor, there is no problem because the destructor
>is called.
1. Not always true in D (though that's a more general problem with D
destructors).
2. There can be times when some cleanup would be needed that isn't in a
destructor (especially in D since destructors can't be relied on actually
being called.)
Re: Function calls
On 2010-01-27 14:01:56 -0500, downs said: Adam D. Ruppe wrote: On Wed, Jan 27, 2010 at 06:34:57PM +0100, Pelle Månsson wrote: I really like this feature, and would miss it should it go away. Me too. Me three. I'll miss the feature too. But I think it's the right thing to do because otherwise you can't have properties that behave like properties when returning a callable type. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: Google's Go & Exceptions
Jérôme M. Berger wrote: > Ali Çehreli wrote: >> Jérôme M. Berger wrote: >>> Throwing exception inside constructors should be avoided because >>> then the destructor is never called and you risk leaking like crazy. >> That's necessarily so, because calling the destructor on the incomplete >> object might cause other troubles. >> >> On the other hand, the destructors of all of the constructed members are >> called when the encapsulating object's constructor throws. >> > Does that include the parent destructor? > I just checked and it seems to. Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: Perfect hashing for string switch
Hello Matti,
On 2010-01-27 15:17, bearophile wrote:
BCS:
Have you compared it to a decisition tree or lex style state
mechine?
I have now implemented that too, it was not an immediate thing to do
(I have removed the versions 2 to 5 to reduce code size on codepad):
http://codepad.org/zOmPeE13
The results are good:
Timings, ldc, seconds:
test1: 4.48 // normal string switch
test2: 2.98 // perfect hash
test3: 2.09
test4: 2.07
test5: 5.44 // AA. Tango AA opIn_r is bug-slow
test6: 1.18 // new result
I hope this is enough.
I have created that large finite state machine in D with a Python
program :-)
Your test6 is invalid: it reads beyond the bounds of the given array.
For example with input "th", it will check whether the third character
is 'i'; but the length of the array is only 2, so it shouldn't be
doing that.
A simple fix to that is to make he first transition of the state machine
based on the length of the key.
that is, 'if' at the top becomes:
switch(word.length) {
case 13: goto S...:
case 12: goto S...:
case 11: goto S...:
case 10: goto S...:
case 9: goto S...:
case 8: goto S...:
case 7: goto S...:
case 6: goto S...:
case 5: goto S...:
case 4: goto S...:
case 3: goto S...:
case 2: goto S...:
default: goto UNREC;
}
--
<
Re: Function calls
Adam D. Ruppe wrote: > On Wed, Jan 27, 2010 at 06:34:57PM +0100, Pelle Månsson wrote: >> I disagree, I find the function calls without the () to be really >> prettifying. >> >> But maybe that's just me. >> >> I don't think that it causes serious bugs, you would see that it's an >> integer the moment you try and use it. It also helps changing code >> from/to functions. >> >> I really like this feature, and would miss it should it go away. > > Me too. > Me three.
Re: Google's Go & Exceptions
Ali Çehreli wrote: > Jérôme M. Berger wrote: >> Throwing exception inside constructors should be avoided because >> then the destructor is never called and you risk leaking like crazy. > > That's necessarily so, because calling the destructor on the incomplete > object might cause other troubles. > > On the other hand, the destructors of all of the constructed members are > called when the encapsulating object's constructor throws. > Does that include the parent destructor? Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: Google's Go & Exceptions
Nick Sabalausky wrote:
> ""J�r�me M. Berger"" wrote in message
> news:hjnrhv$1l0...@digitalmars.com...
>> Throwing exception inside constructors should be avoided because
>> then the destructor is never called and you risk leaking like crazy.
>
> That's a risk outside of constructors too. Hence:
>
> scope(failure) {}
>
- This doesn't exist in C++;
- Outside of constructor, there is no problem because the destructor
is called.
Jerome
--
mailto:jeber...@free.fr
http://jeberger.free.fr
Jabber: jeber...@jabber.fr
signature.asc
Description: OpenPGP digital signature
Re: Perfect hashing for string switch
On 2010-01-27 15:17, bearophile wrote: BCS: Have you compared it to a decisition tree or lex style state mechine? I have now implemented that too, it was not an immediate thing to do (I have removed the versions 2 to 5 to reduce code size on codepad): http://codepad.org/zOmPeE13 The results are good: Timings, ldc, seconds: test1: 4.48 // normal string switch test2: 2.98 // perfect hash test3: 2.09 test4: 2.07 test5: 5.44 // AA. Tango AA opIn_r is bug-slow test6: 1.18 // new result I hope this is enough. I have created that large finite state machine in D with a Python program :-) Your test6 is invalid: it reads beyond the bounds of the given array. For example with input "th", it will check whether the third character is 'i'; but the length of the array is only 2, so it shouldn't be doing that. -- E-mail address: matti.niemenmaa+news, domain is iki (DOT) fi
Re: Function calls
On Wed, Jan 27, 2010 at 06:34:57PM +0100, Pelle Månsson wrote: > I disagree, I find the function calls without the () to be really > prettifying. > > But maybe that's just me. > > I don't think that it causes serious bugs, you would see that it's an > integer the moment you try and use it. It also helps changing code > from/to functions. > > I really like this feature, and would miss it should it go away. Me too. -- Adam D. Ruppe http://arsdnet.net
Re: Function calls
On 01/27/2010 08:34 AM, bearophile wrote:
I have written the following closure, to generate numbers in 1-7 from numbers
in 1-5, as alternative implementation of this:
http://rosettacode.org/wiki/Seven-dice_from_Five-dice#D
auto dice7Gen(alias d5)() {
int rem = 0;
int max = 1;
int gen7() {
while (rem / 7 == max / 7) {
while (max< 7) {
int rand5 = d5() - 1;
max *= 5;
rem = 5 * rem + rand5;
}
int groups = max / 7;
if (rem>= 7 * groups) {
rem -= 7 * groups;
max -= 7 * groups;
}
}
int result = rem % 7;
rem /= 7;
max /= 7;
return result + 1;
}
return gen7;
}
Can you spot the bug? It returns an integer instead of a closure :-)
The correct last line has to be:
return&gen7;
But I think the real "bug" here is in the D2 design. In D2 calling callables
without () has to be disallowed:
-& to take their reference/address
- () to call them
Otherwise syntax error at compile-time.
Only properties marked with @property are allowed to be called without (). (If
you really want it, then even free functions may be allowed to be marked with
@property. This probably will not cause many bugs).
This can avoid bugs and tidy the language a little more.
Bye,
bearophile
I disagree, I find the function calls without the () to be really
prettifying.
But maybe that's just me.
I don't think that it causes serious bugs, you would see that it's an
integer the moment you try and use it. It also helps changing code
from/to functions.
I really like this feature, and would miss it should it go away.
Re: Google's Go & Exceptions
Nick Sabalausky wrote: "Walter Bright" wrote in message news:hjo5t3$2dq...@digitalmars.com... Ary Borenszweig wrote: auto x = new BigInt(someString); How do you implement BigInt's constructor without being able to throw an exception? I presume you mean how can it work without allocating memory. In D, a memory allocation failure is generally not a recoverable exception, it's a fatal exception. A better example would be one that attempted to open a file in the constructor. I think he meant that passing it something like "Hello, Fred." should be disallowed. Yes, that. I don't see another way rather than throwing an exception. Or maybe just do like ruby, when you do "hello".to_i it gives you zero but then you have to check it later. I don't like factory methods like BigInt.fromString. If I want to create a BigInt from a string I should use the constructor, why not?
Re: Perfect hashing for string switch
BCS: > Have you compared it to a decisition tree or lex style state mechine? I have now implemented that too, it was not an immediate thing to do (I have removed the versions 2 to 5 to reduce code size on codepad): http://codepad.org/zOmPeE13 The results are good: Timings, ldc, seconds: test1: 4.48 // normal string switch test2: 2.98 // perfect hash test3: 2.09 test4: 2.07 test5: 5.44 // AA. Tango AA opIn_r is bug-slow test6: 1.18 // new result I hope this is enough. I have created that large finite state machine in D with a Python program :-) Bye, bearophile
Re: Function calls
On 2010-01-27 05:58:51 -0500, "Lars T. Kyllingstad" said: I thought that this issue had been settled a long time ago, and that this was the whole point of @property. It's just not fully implemented yet. The @property attribute is there, but it doesn't change how you can call a function. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: Google's Go
On 2010-01-26 22:34:38 -0500, "Steven E. Harris" said: KennyTM~ writes: Users can reassign most keyboard shortcut in Mac OS X. That's not what I mean. There are applications where it's not possible to bind any key to certain essential operations, such as "move the cursor from the tree pane thing on the left to the list-like pane in the center, and back again". I played with iCal for a while in the Apple Store one day, amusing myself with punishment. There's a keyboard shortcut to bring up a small "go to date" dialog, which allows one to type in a date. But the enter key doesn't "confirm" the dialog. I could not find any keystroke that had the same effect as pressing "OK", or whatever the accepting button is labeled. Is that a cruel joke? That looks like an oversight. It looks like the date entry field eats all keyboard events. I agree it's particularly bad, especially since it's the typical interface element you'd want to access with the keyboard. But I must also say I don't see that often in OS X applications. There's still a way out with the keyboard: activate the VoiceOver spoken interface (Cmd-Fn-F5), then use its shortcuts (Ctrl-Alt-Arrows) to navigate to the control you want. But it's definitely overkill for something that should just work. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: Function calls
bearophile wrote:
I have written the following closure, to generate numbers in 1-7 from numbers
in 1-5, as alternative implementation of this:
http://rosettacode.org/wiki/Seven-dice_from_Five-dice#D
auto dice7Gen(alias d5)() {
int rem = 0;
int max = 1;
int gen7() {
while (rem / 7 == max / 7) {
while (max < 7) {
int rand5 = d5() - 1;
max *= 5;
rem = 5 * rem + rand5;
}
int groups = max / 7;
if (rem >= 7 * groups) {
rem -= 7 * groups;
max -= 7 * groups;
}
}
int result = rem % 7;
rem /= 7;
max /= 7;
return result + 1;
}
return gen7;
}
Can you spot the bug? It returns an integer instead of a closure :-)
The correct last line has to be:
return &gen7;
But I think the real "bug" here is in the D2 design. In D2 calling callables
without () has to be disallowed:
- & to take their reference/address
- () to call them
Otherwise syntax error at compile-time.
Only properties marked with @property are allowed to be called without (). (If
you really want it, then even free functions may be allowed to be marked with
@property. This probably will not cause many bugs).
This can avoid bugs and tidy the language a little more.
Bye,
bearophile
I thought that this issue had been settled a long time ago, and that
this was the whole point of @property.
-Lars
Re: Function calls
On 27/01/10 20:34, bearophile wrote: But I think the real "bug" here is in the D2 design. In D2 calling callables without () has to be disallowed: -& to take their reference/address - () to call them Otherwise syntax error at compile-time. Nothing to add except a voice of support.
Re: Google's Go & Exceptions
Rainer Deyke wrote: Walter Bright wrote: When it's convenient and easy to do the wrong thing, people will do it. Even the ones who know better, and promise themselves they won't do it, do it. WRT warnings, DMD doesn't just make it convenient and easy to do the wrong thing, it /forces/ you to do the wrong thing. Except that DMD doesn't really have any incorrect warnings any more. The only time that you get a warning that isn't necessarily a bug in your code is with implicit conversions. Once the range-tracking implicit conversion rules for arithmetic operations are fully implemented, all of the warnings could be turned into errors, and DMD could lose the -w switch.
Re: DMD generated exes' size differ from PE headers
Walter Bright Wrote:
> bobef wrote:
> > I'm walking the PE header sections to find out the file size. I find
> > the maximum PointerToRawData and add SizeOfRawData of the section to
> > find where the exe ends. It works with the files I've tested. When
> > compiling exe file with DMD 1.055 and -g there are additional four
> > bytes after the last section. Why is that? Is SizeOfRawData wrong or
> > there is something else at the end?
>
>
> I don't know. Could be alignment padding.
I found some article on MSDN that says that SizeOfRawData includes the
alignment padding and something other was indicating the actual size, so this
shouldn't be the case.
I do like this:
uint peFileSize(void[] data) {
auto dos_header = cast(PIMAGE_DOS_HEADER)data;
if(dos_header.e_magic != IMAGE_DOS_SIGNATURE) return -1;
auto nt_header = cast(PIMAGE_NT_HEADERS)&data[dos_header.e_lfanew];
if(nt_header.Signature != IMAGE_NT_SIGNATURE) return -1;
uint maxpointer, exesize;
PIMAGE_SECTION_HEADER section = IMAGE_FIRST_SECTION(nt_header);
for(uint i=0; i maxpointer) {
maxpointer = section.PointerToRawData;
exesize = section.PointerToRawData +
section.SizeOfRawData;
}
}
return exesize;
}
and if I do
exesize = section.PointerToRawData + section.SizeOfRawData +
section.SizeOfRawData%nt_header.OptionalHeader.SectionAlignment;
then I get wrong results don't know why.
Re: DMD generated exes' size differ from PE headers
BCS Wrote: > Hello bobef, > > > I'm walking the PE header sections to find out the file size. I find > > the maximum PointerToRawData and add SizeOfRawData of the section to > > find where the exe ends. It works with the files I've tested. When > > compiling exe file with DMD 1.055 and -g there are additional four > > bytes after the last section. Why is that? Is SizeOfRawData wrong or > > there is something else at the end? > > > > What are the 4 bytes? Can you change what they are by tweaking things? > > -- > > < > > Yep, they seem to change.
Re: std.bigint?
Paul D. Anderson wrote: Julian Salazar Wrote: Just wondering, is std.bigint still included in the D2 standard library? Yes, the source file is there and the documentation is on the site, but it does not appear on the list of standard library modules on the sidebar for D2 (but unlike the documentation for std.bitarray, which indicates deprecation, the bigint documentation does not). In addition, there are some instances where BigInt is a bit dodgy (for example, it is impossible to do something such as someBigInt % someIntegerVariable for ANY someIntegerVariable type that isn't int, meaning that uint, long, ubyte, etc. all produce errors - I might try figuring out the cause of this and file some bug reports later). So is bigint being deprecated in the future or is it just unmaintained? Thanks, - Julian I've written a bug report on the absence of the docs for bigint in the D delivery several releases ago. At first I thought it was a simple oversight, but I have become suspicious...what do they know that we don't??? I know the current implementation (by Janice Caron) has some shortcomings. I thought that someone (Don?) was creating a new implementation, but I don't know if that's true or not. It's true. I just haven't got around to including it yet. I was waiting for my cache module to be included in druntime; that finally happened in the last release. Paul
