Do you get a compile time error or runtime error?
Compiling using dmd...
source/document.d(79): Error: function
foundation.array.NSArray.arrayWithObjects (ObjcObject object,
...) is not callable using argument types (Class, Class,
typeof(null))
compile time.
hmm, a class object is of
I'm wondering how I should deal with overriding designated
initailizers. I really have no clue about the part self =
[super...]. KeyboardView is a subclass of NSView.
@implementation KeyboardView
- (id)initWithFrame:(NSRect)frame {
self = [super initWithFrame:frame];
if (self) {
15.11.2014 07:48, Rikki Cattermole пишет:
To further Devisualization, I have got the start of an image library.
It should be fairly interface complete now.
For this I really could use help from anyone with experience with PNG
especially with Adam7 interlacing and color correction such as gamma.
On 18/11/2014 10:37 p.m., Timur Gafarov wrote:
15.11.2014 07:48, Rikki Cattermole пишет:
To further Devisualization, I have got the start of an image library.
It should be fairly interface complete now.
For this I really could use help from anyone with experience with PNG
especially with Adam7
On Tuesday, 18 November 2014 at 10:04:15 UTC, Rikki Cattermole
wrote:
However by the looks of things, you definitely have better
quality code.
At the very least some way to convert between the two e.g.
SuperImage and my Image would be worth it.
Please consider the abstraction in
Speaking of drawing, I have a very serious problem wit NSView. I
cannot call frame() nor bounds() on instances or subclasses and
get a valid NSRect. (same goes for NSWindow frame()).
I had similar problems when working with NSAttributedString and
NSRange, because NSRange from Chocolat was
On 2014-11-18 09:46, Christian Schneider wrote:
Compiling using dmd...
source/document.d(79): Error: function
foundation.array.NSArray.arrayWithObjects (ObjcObject object, ...) is
not callable using argument types (Class, Class, typeof(null))
compile time.
hmm, a class object is of course not
On 2014-11-18 10:07, Christian Schneider wrote:
I'm wondering how I should deal with overriding designated
initailizers. I really have no clue about the part self = [super...].
KeyboardView is a subclass of NSView.
@implementation KeyboardView
- (id)initWithFrame:(NSRect)frame {
self =
On 2014-11-18 13:47, Christian Schneider wrote:
Speaking of drawing, I have a very serious problem wit NSView. I cannot
call frame() nor bounds() on instances or subclasses and get a valid
NSRect. (same goes for NSWindow frame()).
I had similar problems when working with NSAttributedString and
On 11/17/14 4:41 PM, Martin Nowak wrote:
Second part on my series to reduce vibe.d turnaround time.
In this part we'll reduce compilation time by 60%.
https://code.dawg.eu/reducing-vibed-turnaround-time-part-2-less-compiling.html
Just quickly (finally) announcing the release of the next vibe.d
version. This one was originally scheduled for start of
September, but I got extremely busy with no time left for tidying
everything up.
The list of changes is long with notable improvements to the web
interface generator, the
On 11/17/2014 4:41 PM, Martin Nowak wrote:
Second part on my series to reduce vibe.d turnaround time.
In this part we'll reduce compilation time by 60%.
https://code.dawg.eu/reducing-vibed-turnaround-time-part-2-less-compiling.html
-Martin
Should say in the title that you reduced build times
On 11/17/2014 4:41 PM, Martin Nowak wrote:
Second part on my series to reduce vibe.d turnaround time.
In this part we'll reduce compilation time by 60%.
https://code.dawg.eu/reducing-vibed-turnaround-time-part-2-less-compiling.html
-Martin
There's no mention of your name as author in the
Compiling using dmd...
source/document.d(79): Error: function
foundation.array.NSArray.arrayWithObjects (ObjcObject object,
...) is
not callable using argument types (Class, Class, typeof(null))
Hmm, I don't know. Can you use a cast to get around the
problem? Perhaps use a variadic template
Could it be this issue [1]? Can you please see if you can
reproduce it using just plain C.
https://issues.dlang.org/show_bug.cgi?id=5570
Uh, oh, that bug looks like a major annoyance in 64bit! I made a
few checks, all appkit methods returning a NSRect currently
produce a runtime segfault.
On 11/18/2014 08:34 PM, Walter Bright wrote:
Should say in the title that you reduced build times by 60%. Otherwise,
have to read all the way to the end to find it!
It's a great statistic, and having it in the title people will have more
reason to read the article.
Thanks for the tip, I now
Can't you just call super in the beginning of the method and
then call return this at the end. Something like this:
override KeyboardView initWithFrame(NSRect frame)
[initWithFrame:] {
super.initWithFrame(frame);
// my stuff
return this;
}
Ups, sorry, my bad! I was trying this
On 11/18/2014 1:08 PM, Martin Nowak wrote:
On 11/18/2014 08:34 PM, Walter Bright wrote:
Should say in the title that you reduced build times by 60%. Otherwise,
have to read all the way to the end to find it!
It's a great statistic, and having it in the title people will have more
reason to
Am Tue, 18 Nov 2014 12:37:54 +0300
schrieb Timur Gafarov gecko0...@gmail.com:
15.11.2014 07:48, Rikki Cattermole пишет:
To further Devisualization, I have got the start of an image library.
It should be fairly interface complete now.
For this I really could use help from anyone with
Am Wed, 19 Nov 2014 00:35:09 +0100
schrieb Marco Leise marco.le...@gmx.de:
I have working PNG export in my image processing package, part of dlib:
https://github.com/gecko0307/dlib
There're also importers for BMP and TGA.
I also just wrote a TGA importer and found RLE and 16-bit in
Thank you for all of the work you've done with Vibe.D.
On 2014-11-18 21:46, Christian Schneider wrote:
Yes, of course, and this is really not an issue! And this convenience
function can be rewritten in a few lines of code, if really necessary.
Good, I just want to make sure you can continue. Than we can figure out
the minor issues later. Anyway,
On 2014-11-18 21:54, Christian Schneider wrote:
Uh, oh, that bug looks like a major annoyance in 64bit! I made a few
checks, all appkit methods returning a NSRect currently produce a
runtime segfault. But this does not apply to NSSize, nor NSPoint,
functions returning either NSSize or NSPoint
On Tuesday, 18 November 2014 at 17:23:48 UTC, Sönke Ludwig wrote:
Just quickly (finally) announcing the release of the next
vibe.d version. This one was originally scheduled for start of
September, but I got extremely busy with no time left for
tidying everything up.
The list of changes is
On 17.11.2014 21:02, Martin Nowak wrote:
Walter is about to fix an old bug [1] so that invariants are now called
before destruction and for non-default construction.
A remaining question is whether invariants should also be called for
default construction [2].
[1]:
On Tuesday, 18 November 2014 at 02:35:41 UTC, Walter Bright wrote:
On 11/17/2014 3:15 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
Ok, but I would rather say it like this: the language C
doesn't really provide
strings, it only provides literals in a particular format. So
On Tuesday, 18 November 2014 at 07:04:50 UTC, FrankLike wrote:
Don't profile with out optimzation.
Add -O -inline -release -boundscheck=off to your dmd
arguments.
I mean projects moved from x86 to x64, 'cast(int)length ' is
better than 'size_t i=(something).length '.
I think the reason
On Tuesday, 18 November 2014 at 04:58:43 UTC, Anonymous Coward
wrote:
Stop wasting time with the mouth breather.
Please write under your full name.
On Tuesday, 18 November 2014 at 07:33:15 UTC, Daniel Kozak via
Digitalmars-d wrote:
Short answer: NO.
Long answer:
If I neeed this, I will build version of phobos and druntime
myself with
this enabled. Or we could distribute both versions and select
one by
some switch. But I am against
On Monday, 17 November 2014 at 23:14:32 UTC, Vladimir Panteleev
wrote:
Would you trade 0.1% in performance for a better debugging
experience?
Yes, of course. In most programs, a day of work can give = 1%
speed-up, and debugging can take many more.
On Monday, 17 November 2014 at 20:07:54 UTC, Freddy wrote:
Why not make the compiler copy the variable how's address is
taken to the heap like how a closure does it? Would it be hard
that optimize away?
int* c;
int main(){
int a;
int* b=a;//a is now a reference to the heap
On Monday, 17 November 2014 at 19:36:10 UTC, GreatEmerald wrote:
But otherwise I pinged some people on openSUSE and it seems
there is some interest in D, so now we have a separate project
for it.
That's great to hear! Duncan Mac-Vicar started work on an LDC
packages, which I'm keeping
On Tuesday, 18 November 2014 at 02:35:41 UTC, Walter Bright wrote:
C is a brilliant language. That doesn't mean it hasn't made
serious mistakes in its design. The array decay and 0 strings
have proven to be very costly to programmers over the decades.
I'd rather say that it is the industry
On Tuesday, 18 November 2014 at 11:15:28 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 18 November 2014 at 02:35:41 UTC, Walter Bright
wrote:
C is a brilliant language. That doesn't mean it hasn't made
serious mistakes in its design. The array decay and 0 strings
have proven to be very costly to
On Tuesday, 18 November 2014 at 08:28:19 UTC, Paulo Pinto wrote:
This is just one case, the CVE List gets updated every day and
90% of the issues are the usual C suspects regarding pointer
misuse and out of bounds.
Sure, but these are not a strict language issues since the same
developers
I mean projects moved from x86 to x64, 'cast(int)length ' is
better than 'size_t i=(something).length '.
I think the reason for the existence of size_t, is that the C
designers thought that the second way is better than the first
way.
But now 'int' is enough, not huge and not small.
if
If you migrate your projct from x86 to x64,you will find the
length is error,you must modify it ,such as:
int i= (something).length
to
size_t i = (something).length
but now ,'int' is enough for use,not huge and not small,only
enough.
'int' is easy to write,and most people are used to it.
I'm thinking about 3 configurations:
1. debug
2. release/conservative: assert=off, bounds checks=on, stack
frames
3. release/optimized: bounds checks=off, no stack frames; can
also apply additional optimizations for more speed like turning
assert into assume.
On 11/17/14 6:14 PM, Vladimir Panteleev wrote:
I proposed to build Phobos and Druntime with stack frames enabled:
Sure, why not 3 versions of phobos/runtime in installation? Space is cheap.
-Steve
On Tue, 18 Nov 2014 12:33:51 +
FrankLike via Digitalmars-d digitalmars-d@puremagic.com wrote:
If you migrate your projct from x86 to x64,you will find the
length is error,you must modify it ,such as:
int i= (something).length
to
size_t i = (something).length
but now ,'int' is
On Tuesday, 18 November 2014 at 11:14:06 UTC, Marc Schütz wrote:
That's great to hear! Duncan Mac-Vicar started work on an LDC
packages, which I'm keeping up-to-date since then:
https://build.opensuse.org/package/show/home:marc_schuetz:branches:home:dmacvicar/ldc
I'm going to ask him, and then
On Tuesday, 18 November 2014 at 13:35:46 UTC, ketmar via
Digitalmars-d wrote:
On Tue, 18 Nov 2014 12:33:51 +
FrankLike via Digitalmars-d digitalmars-d@puremagic.com wrote:
If you migrate your projct from x86 to x64,you will find the
length is error,you must modify it ,such as:
int i=
On Tuesday, 18 November 2014 at 12:02:01 UTC, Paulo Pinto wrote:
On Tuesday, 18 November 2014 at 11:15:28 UTC, Ola Fosheim
Grøstad wrote:
I'd rather say that it is the industry that has
misappropriated C, which in my view basically was typed
portable assembly with very little builtin
On Monday, 17 November 2014 at 19:36:10 UTC, GreatEmerald wrote:
Though I'm still a bit unsure about the whole druntime part.
The official RPM doesn't include any libraries for druntime,
only includes, albeit building it from source does produce a
druntime library. Is it worth separating it
drop your C.
auto len = smth.length;
works ok for both x86 and x86_64 (don't know what x64 is).
Many excellent projects such as dfl,dgui,tango, many 'length'
which type is 'int' or 'uint',they are D's,many people like
it.but they should migrate to 64 bit.So if 'length' type is
'int',they
On Tue, 18 Nov 2014 14:24:16 +
FrankLike via Digitalmars-d digitalmars-d@puremagic.com wrote:
drop your C.
auto len = smth.length;
works ok for both x86 and x86_64 (don't know what x64 is).
Many excellent projects such as dfl,dgui,tango, many 'length'
which type is 'int' or
On Monday, 17 November 2014 at 23:14:32 UTC, Vladimir Panteleev
wrote:
I proposed to build Phobos and Druntime with stack frames
enabled:
This is very much worth it in my opinion. Not just for debugging
but being able to profile (sometimes in production, without
needing to recompile with
Many excellent projects such as dfl,dgui,tango, many 'length'
which type is 'int' or 'uint',they are D's,many people like
it.but they should migrate to 64 bit.So if 'length' type is
'int',they can work on 64 bit,but now,they must be modify for
'length''s type.
broken code must be fixed by the
but now ,'int' is enough for use,not huge and not small,only
enough.
'int' is easy to write,and most people are used to it.
Most importantly easier to migrate code,if 'length''s return
value type is 'int'.
How about your idea?
On Tue, 18 Nov 2014 14:41:18 +
FrankLike via Digitalmars-d digitalmars-d@puremagic.com wrote:
Many excellent projects such as dfl,dgui,tango, many 'length'
which type is 'int' or 'uint',they are D's,many people like
it.but they should migrate to 64 bit.So if 'length' type is
On Tuesday, 18 November 2014 at 13:50:59 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 18 November 2014 at 12:02:01 UTC, Paulo Pinto
wrote:
Nobody were forced to write code in C to target anything, it
was a choice. And a choice that grew out of a focus on
performance and the fact that
On Tuesday, 18 November 2014 at 12:33:52 UTC, FrankLike wrote:
If you migrate your projct from x86 to x64,you will find the
length is error,you must modify it ,such as:
int i= (something).length
to
size_t i = (something).length
but now ,'int' is enough for use,not huge and not small,only
but now ,'int' is enough for use,not huge and not small,only
enough.
'int' is easy to write,and most people are used to it.
Most importantly easier to migrate code,if 'length''s return
value type is 'int'.
How about your idea?
On Tuesday, 18 November 2014 at 14:56:42 UTC, Paulo Pinto wrote:
Since when do developers use a different systems programming
language than the one sold by the OS vendor?
Who has the pleasure to waste work hours writing FFI wrappers
around SDK tools?
All successful systems programming
Am Mon, 17 Nov 2014 19:36:08 +
schrieb GreatEmerald past...@gmail.com:
On Monday, 17 November 2014 at 02:29:54 UTC, Marco Leise wrote:
Exactly a year ago I created a poll[1] about the include path
and 65% voted for dlang over just d. We should stick to
/usr/include/dlang now for a
Am Mon, 17 Nov 2014 23:14:31 +
schrieb Vladimir Panteleev vladi...@thecybershadow.net:
[…]
From
http://eli.thegreenplace.net/2011/09/06/stack-frame-layout-on-x86-64/
-
Preserving the base pointer
The base pointer rbp (and its
On Tuesday, 18 November 2014 at 14:24:18 UTC, FrankLike wrote:
Many excellent projects such as dfl,dgui,tango, many 'length'
which type is 'int' or 'uint',they are D's,many people like
it.but they should migrate to 64 bit.So if 'length' type is
'int',they can work on 64 bit,but now,they must
On Tuesday, 18 November 2014 at 13:18:10 UTC, Steven
Schveighoffer wrote:
On 11/17/14 6:14 PM, Vladimir Panteleev wrote:
I proposed to build Phobos and Druntime with stack frames
enabled:
Sure, why not 3 versions of phobos/runtime in installation?
Space is cheap.
You have to consider the
On Sunday, 16 November 2014 at 21:54:40 UTC, Walter Bright wrote:
Besides, C was designed for the PDP-11, which had no such
instructions.
BTW, this is not entirely correct. It had autoincrement on
registers. This is the example given on Wikipedia:
MOV #MSG,R1
1$: MOVB (R1)+,R0
BEQ DONE
On Tuesday, 18 November 2014 at 16:26:58 UTC, Marco Leise wrote:
ABI differences in source files only apply to druntime/Phobos
and these imports are generally on the default import path. I
was more concerned with GtkD and similar 3rd party libraries,
for which you have to specify the import
On Tuesday, 18 November 2014 at 16:49:55 UTC, Marco Leise wrote:
Without fully understanding the issue, omitting the frame
pointer on GNU amd64 systems is the default and is supposed to
work using DWARF debug information. So there should be no need
for a stack frame pointer, right?
Firstly,
I have to say I mostly settled with Marc Schütz's approach to
lifetime management already, because it allows us to return
scope ref arguments from functions by directly declaring which
arguments the result can be referring to. So you can for
example write sub-string search algorithms that can
On Tuesday, 18 November 2014 at 12:33:52 UTC, FrankLike wrote:
If you migrate your projct from x86 to x64,you will find the
length is error,you must modify it ,such as:
int i= (something).length
to
size_t i = (something).length
but now ,'int' is enough for use,not huge and not small,only
Isn't the purpose of size_t is to be large enough to address all
available memory? A negative value is not only too small but
doesn't make sense when discussing lengths.
Correctness requires using size_t.
On Tue, 18 Nov 2014 17:59:04 +
David Eagen via Digitalmars-d digitalmars-d@puremagic.com wrote:
Isn't the purpose of size_t is to be large enough to address all
available memory? A negative value is not only too small but
doesn't make sense when discussing lengths.
Correctness
Am Tue, 18 Nov 2014 15:01:25 +
schrieb Frank Like 1150015...@qq.com:
but now ,'int' is enough for use,not huge and not small,only
enough.
'int' is easy to write,and most people are used to it.
Most importantly easier to migrate code,if 'length''s return
value type is 'int'.
How
On 11/18/14 12:03 PM, Vladimir Panteleev wrote:
On Tuesday, 18 November 2014 at 13:18:10 UTC, Steven Schveighoffer wrote:
On 11/17/14 6:14 PM, Vladimir Panteleev wrote:
I proposed to build Phobos and Druntime with stack frames enabled:
Sure, why not 3 versions of phobos/runtime in
Am Tue, 18 Nov 2014 17:15:12 +
schrieb Vladimir Panteleev vladi...@thecybershadow.net:
On Tuesday, 18 November 2014 at 16:49:55 UTC, Marco Leise wrote:
Without fully understanding the issue, omitting the frame
pointer on GNU amd64 systems is the default and is supposed to
work using
On Monday, 17 November 2014 at 23:14:32 UTC, Vladimir Panteleev
wrote:
I proposed to build Phobos and Druntime with stack frames
enabled:
https://issues.dlang.org/show_bug.cgi?id=13726
Stack frames add three CPU instructions to each function (two
in the prolog, and one in the epilog). This
On 11/18/14 1:49 PM, Steven Schveighoffer wrote:
I refuse to let the fact that we package every platform's download into
one zip to be some sort of argument :) DMD is the only distribution that
I've ever seen do this.
Note: I can't imagine the build process for this is simple either.
-Steve
Am Tue, 18 Nov 2014 17:10:18 +
schrieb GreatEmerald past...@gmail.com:
On Tuesday, 18 November 2014 at 16:26:58 UTC, Marco Leise wrote:
ABI differences in source files only apply to druntime/Phobos
and these imports are generally on the default import path. I
was more concerned with
Am Tue, 18 Nov 2014 12:22:58 +
schrieb FrankLike 1150015...@qq.com:
I mean projects moved from x86 to x64, 'cast(int)length ' is
better than 'size_t i=(something).length '.
I think the reason for the existence of size_t, is that the C
designers thought that the second way is
On Tuesday, 18 November 2014 at 18:55:43 UTC, Marco Leise wrote:
Is it fair if I argue that fixing DWARF info generation is a
better solution then?
I don't know. Probably. Not all tools may read DWARF info. Also,
I'm not sure if this is related but Phobos/Druntime are currently
built without
Marco Leise:
foreach (i; 0 .. a.length)
{
somework();
}
Better:
foreach (immutable _; 0 .. a.length)
{
somework();
}
Unfortunately this syntax is not yet supported, for unknown
reasons:
foreach (; 0 .. a.length)
{
somework();
}
Bye,
bearophile
On 11/18/2014 4:18 AM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
Never blame the tool for bad management.
To bring up the aviation industry again, they long ago recognized that blame
the pilot and blame the mechanics is not how safe airplanes are made. They
are made, in
On 11/18/2014 3:15 AM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Tuesday, 18 November 2014 at 02:35:41 UTC, Walter Bright wrote:
C is a brilliant language. That doesn't mean it hasn't made serious mistakes
in its design. The array decay and 0 strings have proven to be
On Tue, Nov 18, 2014 at 11:45:13AM -0800, Walter Bright via Digitalmars-d wrote:
[...]
I'm sorry to say this, but these rationalizations as to why C cannot
add a trivial enhancement that takes nothing away and solves most of
the buffer overflow problems leaves me shaking my head.
(C has
Am Sun, 16 Nov 2014 13:39:22 +
schrieb FrankLike 1150015...@qq.com:
Many old projects need move from x86 to x64,but the 'length' type
is size_t,it will change on x64,so a lot of work must to do.but I
find some info which is help for d:
http://www.dotnetperls.com/array-length.
it means:
Am Tue, 18 Nov 2014 19:33:42 +
schrieb bearophile bearophileh...@lycos.com:
Marco Leise:
foreach (i; 0 .. a.length)
{
somework();
}
Better:
foreach (immutable _; 0 .. a.length)
{
somework();
}
Unfortunately this syntax is not yet supported, for unknown
On Saturday, 15 November 2014 at 20:13:47 UTC, deadalnix wrote:
On Saturday, 15 November 2014 at 12:52:33 UTC, Ola Fosheim
Grøstad wrote:
Thanks for the link! I agree ML has some interesting work done
for it, but they make some assumptions:
1. low portion of mutable objects
2. small heap
On Tue, 18 Nov 2014 19:33:42 +
bearophile via Digitalmars-d digitalmars-d@puremagic.com wrote:
Unfortunately this syntax is not yet supported, for unknown
reasons:
foreach (; 0 .. a.length)
{
somework();
}
the same as for `foreach (auto n; ...)` -- cosmetic changes are not
On 11/18/2014 12:10 PM, H. S. Teoh via Digitalmars-d wrote:
On Tue, Nov 18, 2014 at 11:45:13AM -0800, Walter Bright via Digitalmars-d wrote:
I'm sorry to say this, but these rationalizations as to why C cannot
add a trivial enhancement that takes nothing away and solves most of
the buffer
Am Tue, 18 Nov 2014 19:35:06 +
schrieb Vladimir Panteleev vladi...@thecybershadow.net:
On Tuesday, 18 November 2014 at 18:55:43 UTC, Marco Leise wrote:
Is it fair if I argue that fixing DWARF info generation is a
better solution then?
I don't know. Probably. Not all tools may read
On Tuesday, 18 November 2014 at 19:45:12 UTC, Walter Bright wrote:
On 11/18/2014 3:15 AM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Tuesday, 18 November 2014 at 02:35:41 UTC, Walter Bright
wrote:
C is a brilliant language. That doesn't mean it hasn't made
serious
On Tuesday, 18 November 2014 at 15:36:58 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 18 November 2014 at 14:56:42 UTC, Paulo Pinto
wrote:
Since when do developers use a different systems programming
language than the one sold by the OS vendor?
Who has the pleasure to waste work hours writing
On Tuesday, 18 November 2014 at 19:42:20 UTC, Walter Bright wrote:
To bring up the aviation industry again, they long ago
recognized that blame the pilot and blame the mechanics is
not how safe airplanes are made. They are made, in part, by
fixing the tools so mistakes cannot happen, as even
On 11/18/2014 9:01 AM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Sunday, 16 November 2014 at 21:54:40 UTC, Walter Bright wrote:
Besides, C was designed for the PDP-11, which had no such instructions.
BTW, this is not entirely correct. It had autoincrement on registers.
On Tue, Nov 18, 2014 at 12:44:35PM -0800, Walter Bright via Digitalmars-d wrote:
On 11/18/2014 12:10 PM, H. S. Teoh via Digitalmars-d wrote:
On Tue, Nov 18, 2014 at 11:45:13AM -0800, Walter Bright via Digitalmars-d
wrote:
I'm sorry to say this, but these rationalizations as to why C cannot
On 11/18/2014 12:53 PM, Paulo Pinto wrote:
On Tuesday, 18 November 2014 at 19:45:12 UTC, Walter Bright wrote:
(C has added useless enhancements, like VLAs.)
So useless that it became optional in C11.
https://groups.google.com/forum/#!topic/comp.std.c/AoB6LFHcd88
Note the Rationale given:
On Tuesday, 18 November 2014 at 19:45:12 UTC, Walter Bright wrote:
I'm sorry to say this, but these rationalizations as to why C
cannot add a trivial enhancement that takes nothing away and
They can add whatever they want.
I am arguing against the position that it was a design mistake to
On Tuesday, 18 November 2014 at 21:07:22 UTC, Walter Bright wrote:
Those are not dedicated string instructions. Autoincrement was
an addressing mode that could be used with any register and any
instruction, including the stack and program counter (!).
Yes, Motorola 68000 also had those. Very
On Tuesday, 18 November 2014 at 20:34:01 UTC, Ola Fosheim Grøstad
wrote:
Does this mean that you need all threads (which I presume are
the mutators) to be in an eventloop in order to collect?
What you need is for each thread to provide you a list of roots.
You can start tracing while having
On 11/18/2014 1:12 PM, H. S. Teoh via Digitalmars-d wrote:
On Tue, Nov 18, 2014 at 12:44:35PM -0800, Walter Bright via Digitalmars-d wrote:
On 11/18/2014 12:10 PM, H. S. Teoh via Digitalmars-d wrote:
On Tue, Nov 18, 2014 at 11:45:13AM -0800, Walter Bright via Digitalmars-d wrote:
I'm sorry to
On Tue, Nov 18, 2014 at 02:14:20PM -0800, Walter Bright via Digitalmars-d wrote:
On 11/18/2014 1:12 PM, H. S. Teoh via Digitalmars-d wrote:
On Tue, Nov 18, 2014 at 12:44:35PM -0800, Walter Bright via Digitalmars-d
wrote:
On 11/18/2014 12:10 PM, H. S. Teoh via Digitalmars-d wrote:
On Tue, Nov
Am Sat, 15 Nov 2014 02:11:34 +
schrieb Robert burner Schadek rburn...@gmail.com:
On Friday, 14 November 2014 at 23:40:21 UTC, David Nadlinger
wrote:
On Friday, 14 November 2014 at 22:18:41 UTC, Robert burner
Schadek wrote:
Yes, but this way allows to add structured logging in an
On 11/18/2014 2:35 PM, H. S. Teoh via Digitalmars-d wrote:
On Tue, Nov 18, 2014 at 02:14:20PM -0800, Walter Bright via Digitalmars-d wrote:
On 11/18/2014 1:12 PM, H. S. Teoh via Digitalmars-d wrote:
No, I proposed a new syntax that would have different behavior:
void foo(char a[..])
Ah, I
On 11/18/2014 1:23 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
I am arguing against the position that it was a design mistake to keep the
semantic model simple and with few presumptions. On the contrary, it was the
design goal. Another goal for a language like C is ease of
On 11/18/2014 1:56 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
Filenames are easy, just allocate a large fixed size buffer, then fill in.
open(). reuse buffer.
char s[] = filename.ext;
foo(s[0..8]);
But hey, it's simpler, faster, less code, less bug prone,
On Tuesday, 18 November 2014 at 12:18:16 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 18 November 2014 at 08:28:19 UTC, Paulo Pinto
wrote:
This is just one case, the CVE List gets updated every day and
90% of the issues are the usual C suspects regarding pointer
misuse and out of bounds.
On Tuesday, 18 November 2014 at 23:48:27 UTC, Walter Bright wrote:
On 11/18/2014 1:23 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
I am arguing against the position that it was a design mistake
to keep the
semantic model simple and with few presumptions. On the
contrary,
1 - 100 of 142 matches
Mail list logo
