On Monday, 28 March 2016 at 21:01:19 UTC, cy wrote:
No exception raised for dereferencing a null.
If it didn't give the error, either you swallowed it or you
didn't actually dereference null.
The latter is a kinda strange happenstance, but if you are
calling a static or final method on an
On Monday, 28 March 2016 at 21:01:19 UTC, cy wrote:
I invoked db.find_chapter.bindAll(8,4), when db was a null
pointer.
No, no, no it's worse than that. What I did was (db.)find_chapter
= (db.)backend.prepare("...") when backend was null, and got no
error. find_chapter was garbage of course,
I finally found the null pointer. It took a week. I was assigning
"db = db" when I should have been assigning "this.db = db".
Terrible, I know. But...
I invoked db.find_chapter.bindAll(8,4), when db was a null
pointer. There was no null pointer error. No exception raised for
dereferencing a
On Mon, Mar 28, 2016 at 10:49:28PM +, Jack Stouffer via Digitalmars-d-learn
wrote:
> On Monday, 28 March 2016 at 22:43:26 UTC, Anon wrote:
> >On Monday, 28 March 2016 at 22:34:31 UTC, Jack Stouffer wrote:
> >>void main () {
> >>import std.range.primitives;
> >>char[] val = ['1', '0',
On Monday, March 28, 2016 22:34:31 Jack Stouffer via Digitalmars-d-learn
wrote:
> void main () {
> import std.range.primitives;
> char[] val = ['1', '0', 'h', '3', '6', 'm', '2', '8', 's'];
> pragma(msg, ElementEncodingType!(typeof(val)));
> pragma(msg, typeof(val.front));
> }
On Mon, Mar 28, 2016 at 04:07:22PM -0700, Jonathan M Davis via
Digitalmars-d-learn wrote:
[...]
> The range API considers all strings to have an element type of dchar.
> char, wchar, and dchar are UTF code units - UTF-8, UTF-16, and UTF-32
> respectively. One or more code units make up a code
On 29.03.2016 00:49, Jack Stouffer wrote:
But the value fits into a char; a dchar is a waste of space. Why on
Earth would a different type be given for the front value than the type
of the elements themselves?
UTF-8 strings are decoded by the range primitives. That is, `front`
returns one
On Monday, 28 March 2016 at 23:06:49 UTC, Anon wrote:
Any because you're using ranges,
*And because you're using ranges,
On Monday, 28 March 2016 at 22:43:26 UTC, Anon wrote:
On Monday, 28 March 2016 at 22:34:31 UTC, Jack Stouffer wrote:
void main () {
import std.range.primitives;
char[] val = ['1', '0', 'h', '3', '6', 'm', '2', '8', 's'];
pragma(msg, ElementEncodingType!(typeof(val)));
On Monday, 28 March 2016 at 22:49:28 UTC, Jack Stouffer wrote:
On Monday, 28 March 2016 at 22:43:26 UTC, Anon wrote:
On Monday, 28 March 2016 at 22:34:31 UTC, Jack Stouffer wrote:
void main () {
import std.range.primitives;
char[] val = ['1', '0', 'h', '3', '6', 'm', '2', '8',
's'];
On Monday, 28 March 2016 at 14:40:40 UTC, Adam D. Ruppe wrote:
On Monday, 28 March 2016 at 04:53:19 UTC, aki wrote:
So... You mean there are no way to declare functions
without exporting the symbol?
alas, no, even if it is private it can conflict on the outside
(so stupid btw).
Seems to
On Monday, 28 March 2016 at 22:34:31 UTC, Jack Stouffer wrote:
void main () {
import std.range.primitives;
char[] val = ['1', '0', 'h', '3', '6', 'm', '2', '8', 's'];
pragma(msg, ElementEncodingType!(typeof(val)));
pragma(msg, typeof(val.front));
}
prints
char
dchar
On 3/28/16 7:06 PM, Anon wrote:
The compiler doesn't know that, and it isn't true in general. You could
have, for example, U+3042 in your char[]. That would be encoded as three
chars. It wouldn't make sense (or be correct) for val.front to yield
'\xe3' (the first byte of U+3042 in UTF-8).
I
On Monday, 28 March 2016 at 23:07:22 UTC, Jonathan M Davis wrote:
...
Thanks for the detailed responses. I think I'll compile this info
and put it in a blog post so people can just point to it when
someone else is confused.
On Monday, 28 March 2016 at 18:28:33 UTC, Steven Schveighoffer
wrote:
On 3/27/16 12:04 PM, Jonathan Villa wrote:
I can reproduce your issue on windows.
It works on Mac OS X.
I see different behavior on 32-bit (DMC stdlib) vs. 64-bit
(MSVC stdlib). On both, the line is not read properly (I
void main () {
import std.range.primitives;
char[] val = ['1', '0', 'h', '3', '6', 'm', '2', '8', 's'];
pragma(msg, ElementEncodingType!(typeof(val)));
pragma(msg, typeof(val.front));
}
prints
char
dchar
Why?
On Monday, March 28, 2016 16:02:26 H. S. Teoh via Digitalmars-d-learn wrote:
> For the time being, I'd recommend std.utf.byCodeUnit as a workaround.
Yeah, though as I've started using it, I've quickly found that enough
of Phobos doesn't support it yet, that it's problematic. e.g.
On Tuesday, 29 March 2016 at 01:04:50 UTC, Mike Parker wrote:
On Monday, 28 March 2016 at 14:40:40 UTC, Adam D. Ruppe wrote:
On Monday, 28 March 2016 at 04:53:19 UTC, aki wrote:
So... You mean there are no way to declare functions
without exporting the symbol?
alas, no, even if it is private
On 2016-03-28 06:02, aki wrote:
Hello,
When I porting legacy app. written in C to D,
I have a problem.
file a.d:
extern (C) private void foo() {}
file b.d:
extern (C) private void foo() {}
Error 1: Previous Definition Different : _foo
In C language, "static void foo(){}" does not
export
On Monday, 28 March 2016 at 14:40:40 UTC, Adam D. Ruppe wrote:
On Monday, 28 March 2016 at 04:53:19 UTC, aki wrote:
So... You mean there are no way to declare functions
without exporting the symbol?
alas, no, even if it is private it can conflict on the outside
(so stupid btw).
Is it all
On Monday, 28 March 2016 at 04:53:19 UTC, aki wrote:
So... You mean there are no way to declare functions
without exporting the symbol?
alas, no, even if it is private it can conflict on the outside
(so stupid btw).
Is it all the same function being referenced? Just importing from
there
On Sunday, 27 March 2016 at 07:45:00 UTC, ParticlePeter wrote:
On Wednesday, 23 March 2016 at 20:00:55 UTC, wobbles wrote:
[...]
Thanks Wobbles, I took your approach. There were some minor
issues, here is a working version:
[...]
Great, thanks for fixing it up!
On 3/27/16 12:04 PM, Jonathan Villa wrote:
On Saturday, 26 March 2016 at 16:34:34 UTC, Steven Schveighoffer wrote:
On 3/25/16 6:47 PM, Jonathan Villa wrote:
On Friday, 25 March 2016 at 13:58:44 UTC, Steven Schveighoffer wrote:
[...]
OK, the following inputs I've tested: á, é, í, ó, ú, ñ, à,
23 matches
Mail list logo
