Re: How to specify an exact template?
On Saturday, 16 January 2021 at 15:41:38 UTC, solidstate1991
wrote:
On Saturday, 16 January 2021 at 14:18:55 UTC, Tove wrote:
probably you can use
https://dlang.org/spec/traits.html#getOverloads
I don't know how to use it with functions outside of
structs/classes.
void foo() {}
void foo(string i) {}
static foreach(overload; __traits(getOverloads,
mixin(__MODULE__), "foo"))
pragma(msg, typeof(overload));
Re: How to specify an exact template?
On Saturday, 16 January 2021 at 14:14:57 UTC, solidstate1991 wrote: On Saturday, 16 January 2021 at 14:13:29 UTC, solidstate1991 wrote: Here's the following line, among many others: return !(ubyte); This generates an error, as this function template matches two instances, but currently I don't know how to choose the one I need, other than write a local function, that looks a bit ugly. Forgot to link the code example: https://github.com/ZILtoid1991/pixelperfectengine/blob/master/pixeperfectengine/src/PixelPerfectEngine/graphics/layers/base.d#L143 probably you can use https://dlang.org/spec/traits.html#getOverloads
reference counting resources but NOT memory
Is there any elegant/smart solution to reference counting resources without ever freeing any objects? When the ref hits 0 it should free some other resource that isn't memory... Resource[10] resources; resources[3].inc; // 1 ref - 0->1 transition enable some feature resources[3].dec; // 0 ref - 1->0 transition disable some feature resources[3].inc; // 1 ref - instantly ready to be used again without any alloc/free Maybe it's best to use normal constructor/destructor with some arena memory allocator that never actually frees anything? Must be a common problem, anyone got experience with a good design?
Re: Symmetry Investments and the D Language Foundation are Hiring
On Sunday, 30 August 2020 at 20:12:41 UTC, Arjan wrote: On Sunday, 30 August 2020 at 14:13:36 UTC, Mike Parker wrote: Looking for a full-time or part-time gig? Not only is Symmetry Investments hiring D programmers, they are also generously funding two positions for ecosystem work under the D Language Foundation. And they've put up a bounty for a new DUB feature. Read all about it here: https://dlang.org/blog/2020/08/30/symmetry-investments-and-the-d-language-foundation-are-hiring/ Fantastic! Thanks Symmetry! Epic, this is a gamechanger!
Re: From the D Blog: A Pattern for Head-mutable Structures
On Sunday, 28 June 2020 at 16:31:35 UTC, Avrina wrote: On Sunday, 28 June 2020 at 02:52:03 UTC, Mike Parker wrote: If that's not good enough for you, then I have nothing else to say on the matter. Replies like this one and andrei are why. You are directing a community around a topic to an article about that topic. What do you think they are going to do? There's a reason why votes don't count when an article is linked directly. They didn't do it by mistake. No worries, I'll post the direct link for you in the future. I got you covered. I have a feature request to the forum engine, automatically delete all posts with hn deeplinks, problem solved.
Store multiple identical objects in a key:ed datastructure?
Consider a complex key that is a combination of multiple
variables.
struct key
{
intfoo = 1;
string bar = "joy";
string baz = "huzza";
}
The value is a very large object.
struct value
{
int[4096] payload;
}
There are 10.000s of different keys.
But typically only ~10 different values.
My first idea was to have an array/set of unique value instances
and store only the index to the array in the key:ed data
structure, this way it's possible to reallocate and extend the
array.
Is there an idiomatic way to solve this in D? Or should I just
get my hands dirty and do the brute force implementation of the
above idea?
Re: Release D 2.067.0
On Tuesday, 24 March 2015 at 17:08:03 UTC, Martin Nowak wrote: Glad to announce D 2.067.0. https://dlang.dawg.eu/downloads/dmd.2.067.0/ -Martin Congrats! Although, I must admit, I was a little saddened to see that multiple alias this didn't make the release, I thought it was finalized... I should have kept a closer watch. https://github.com/D-Programming-Language/dmd/pull/3998
Re: assert semantic change proposal
On Wednesday, 6 August 2014 at 00:47:28 UTC, Walter Bright wrote: If you build dmd in debug mode, and then run it with -O --c, it will give you a list of all the data flow transformations it does. But the list is a blizzard on non-trivial programs. Awesome, thanks! Will give it a whirl, as soon as my vacation is over.
Re: assert semantic change proposal
On Monday, 4 August 2014 at 01:26:10 UTC, Daniel Gibson wrote: Am 04.08.2014 03:17, schrieb John Carter: But that's OK. Because I bet 99.999% of those warnings will be pointing straight at bone fide defects. Well, that would make the problem more acceptable.. However, it has been argued that it's very hard to warn about code that will be eliminated, because that code often only become dead or redundant due to inlining, template instantiation, mixin, ... and you can't warn in those cases. So I doubt that the compiler will warn every time it removes checks that are considered superfluous because of a preceding assert(). Cheers, Daniel It is possible, just not as a default enabled warning. Some compilers offers optimization diagnostics which can be enabled by a switch, I'm quite fond of those as it's a much faster way to go through a list of compiler highlighted failed/successful optimizations rather than being forced to check the asm output after every new compiler version or minor code refactoring. In my experience, it actually works fine in huge projects, even if there are false positives you can analyse what changes from the previous version as well as ignoring modules which you know is not performance critical.
Re: function default arguments depending on other arguments
On Friday, 18 July 2014 at 17:40:23 UTC, Timon Gehr wrote:
On 07/18/2014 12:00 AM, Trass3r wrote:
void foo(int a, int b = a)
{
}
is illegal in C++ because order of evaluation is undefined.
But since D defines the order to be left to right couldn't it
also allow
this?
It could, and I think it is an unnecessary limitation that it
currently does not. (This can also be useful if that parameter
is the hidden 'this' reference.)
This request keeps popping up, I've seen it at least 3 times
before and there's even an enhancement request for it:
https://issues.dlang.org/show_bug.cgi?id=8075
IIRC:
Walter's stance was that he needs compelling examples, which
proves the utility of this new feature.
DMD 2.066.0-b1 feedback
The beta works great this far, just sharing some few initial
surprises.
1) The lookup rules for namespaces seem overly permissive:
extern (C++, A.B.C):
void cpp() { }
All these work:
A.cpp
B.cpp
C.cpp
A.B.cpp
B.C.cpp
A.B.C.cpp
2) We have std.traits.functionLinkage, but no corresponding trait
to get the namespace?
Re: RFC: Value range propagation for if-else
On Monday, 30 June 2014 at 07:47:22 UTC, Lionello Lunesu wrote:
Latest [1] now also supports CTFE:
const i = foo ? -1 : 33;
if (i)
static assert(__traits(intrange, i) == Tuple!(-1, 33));
else
{
static assert(i == 0); // Works now!
static assert(__traits(intrange, i) == Tuple!(0, 0));
}
if (i == 33)
{
static assert(i == 33); // Works now!
static assert(__traits(intrange, i) == Tuple!(33, 33));
}
else
static assert(__traits(intrange, i) == Tuple!(-1, 32));
Next up: support for immutable/const members and if (i) static
assert(i)
L.
[1] https://github.com/lionello/dmd/tree/if-else-range
Fantastic work, although I would prefer Bearophile's
'value_range', is there any reason why the same trait could not
be used for float, etc? (I don't need it for float, just as an
example).
I guess an interval_set would be too complicated, slowing down
the compiler? i.e. multiple ranges, or multiple values, just
thinking out loud... Anyway what you did already is kick ass! :)
Re: DMD 2.066 Alpha
On Friday, 13 June 2014 at 16:49:26 UTC, Andrei Alexandrescu wrote: Virtual by default will not change. Being able to negate the final: label is nice to have but not a must. Adding a keyword for that doesn't scale - it would mean we'd need to add one keyword to undo each label. Andrei Just to try and establish a clear path forwards, if a pull request existed which added support for... final!true final!false ... would it be accepted? Or would a generic negate-x-DIP be required? const!false noexcept!false etc.
Re: Knowledge of managed memory pointers
On Friday, 18 April 2014 at 00:01:25 UTC, Manu via Digitalmars-d
wrote:
On 18 April 2014 04:10, Kagamin via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Thursday, 17 April 2014 at 12:39:59 UTC, Manu via
Digitalmars-d wrote:
void f(void* ptr)
{
// was ptr allocated with malloc, or new?
Then what?
Whatever. inc/dec ref, or not. core.memory.addRoot/Range, or
not. That sort
of thing.
There's a persistent problem when dealing with memory systems
in D that it
must remain backward compatible with C and raw pointers, and
that creates
complications.
Both NaCl and go-lang uses a trick to reserve a huge amount of
continuos virtual memory...
Re: DIP60: @nogc attribute
On Tuesday, 15 April 2014 at 19:44:39 UTC, John Colvin wrote: On Tuesday, 15 April 2014 at 19:40:50 UTC, Walter Bright wrote: On 4/15/2014 12:14 PM, Steven Schveighoffer wrote: On Tue, 15 Apr 2014 14:41:36 -0400, Steven Schveighoffer schvei...@yahoo.com wrote: On Tue, 15 Apr 2014 13:01:40 -0400, Walter Bright newshou...@digitalmars.com wrote: http://wiki.dlang.org/DIP60' Wow, that's quite underspecified. What specifically is prevented? All calls to the GC. What about GC calls that cannot cause a collection? Do they even exist? Yes, please all, even harmless calls. This way you are guaranteed that you can include @nogc modules in projects which doesn't even link with a GC.
Re: DIP60: @nogc attribute
On Tuesday, 15 April 2014 at 20:40:05 UTC, Walter Bright wrote: I had a PR for that, but nobody liked it. https://github.com/D-Programming-Language/dmd/pull/1877 If I correctly understand the reservations raised against this PR, the people objecting might have agreed to attribute inference for *private* functions, would this be worth pursuing?
Re: Specifying C++ symbols in C++ namespaces
On Sunday, 6 April 2014 at 02:33:38 UTC, Walter Bright wrote: On 4/5/2014 6:26 PM, Michel Fortin wrote: What if you also have a C++ foo at global scope? It'll work exactly the same as import does. module cpptest; extern (C++) void foo(); extern (C++, namespace = A) void foo(); foo(); // ambiguous A.foo(); // works .foo(); // works? Yes. cpptest.foo(); // works? Yes. Does these two last lines make sense? Just as much sense as: module bar; void foo(); .foo(); // works bar.foo(); // works Namespace lookup rules would be exactly the same as for imports and mixin templates. My main reservation against the new suggestion is that one would be forced to open a new nested namespace even when it's detrimental, because in some cases the namespace structure is already reflected in the filesystem(just like for D:s module system). I can't assess how widespread this is globally, but at least some high-quality projects already have guidelines to use file/namespace mappings. A random example from boost: boost::asio::ip::multicast boost/asio/ip/multicast.hpp One can of course workaround this issue with an extra alias for every imported symbol, or use compile-time reflection to auto-generate all alias statements... (or heaven forbid, put entire boost in one file ;)) I assume the namespace = xxx syntax is some sort of named parameter, would it be possible to add another similar param, which only changes mangling and doesn't actually create a new scope?
Re: Specifying C++ symbols in C++ namespaces
On Saturday, 5 April 2014 at 20:47:29 UTC, Walter Bright wrote:
On 4/2/2014 3:07 PM, Walter Bright wrote:
One downside of this proposal is that if we ever (perish the
thought!) attempted
to interface to C++ templates, this design would preclude that.
Yes, this seems to be a fatal flaw. Another design that has
evolved from these discussions and my discussions with Andrei
on it:
extern (C++, namespace = A.B) { void foo(); void bar(); }
extern (C++, namespace = C) void foo();
bar(); // works
A.B.bar(); // works
foo(); // error: ambiguous
C.foo(); // works
alias C.foo foo;
foo(); // works, calling C.foo()
I really think the namespace semantics should be attached to
the extern(C++) rather than be a separate pragma. Having the
namespace= thing means that namespace isn't a keyword, and
provides a general mechanism where we can add language specific
information as necessary.
How could this common pattern look?
std::string
boost::fun(std::string arg)
alias cpp= extern (C++, namespace = std);
alias boost = extern (C++, namespace = boost);
cpp.string
boost.fun(cpp.string arg)
?
Re: Specifying C++ symbols in C++ namespaces
On Friday, 4 April 2014 at 19:43:56 UTC, Walter Bright wrote:
C++:
namespace S { namespace T {
int foo();
namespace U {
int foo();
}
} }
D:
extern (C++, S::T) {
int foo();
extern (C++, U) {
int foo();
}
}
foo(); // error, ambiguous, which one?
S.T.foo(); // S undefined
Why would we need new ways of declaring scopes in D? Overriding
the external mangling should be sufficient? If there are
collisions you can use any type of scope you prefer to avoid the
issue, modules, structs, templates, even functions or blocks...
void fun1() { extern (C++, S::T) int foo();}
void fun2() { extern (C++, S::T::U) int foo();}
extern (C++, S::T::U) int foo();
struct test { extern (C++, S::T) int foo();}
Re: Table lookups - this is pretty definitive
On Tuesday, 1 April 2014 at 18:35:50 UTC, Walter Bright wrote: Try this benchmark comparing various classification schemes: - Original program... 3 4 1 10x as many iterations... 36 47 19 I think this benchmark is flawed... 1) Apparently there are rounding issues... assuming linear scaling, 1.9 ms yields ~1ms? Probably better to use usecs... 2) Table lookups will nearly always win in isolated 1 function tests... but not necessarily in real apps.
Re: warp: a fast C and C++ preprocessor
On Monday, 31 March 2014 at 17:11:48 UTC, dennis luehring wrote: Am 28.03.2014 19:27, schrieb Andrei Alexandrescu: Facebook is open-sourcing warp, a fast C and C++ preprocessor written by Walter Bright. currently any ideas why clang could be 40% faster? https://news.ycombinator.com/item?id=7489724 SIMD and virtual-file-system?
Re: warp: a fast C and C++ preprocessor
On Monday, 31 March 2014 at 21:16:47 UTC, Walter Bright wrote:
On 3/31/2014 2:06 PM, bearophile wrote:
Walter Bright:
Since then, I've fixed a handful of bugs, but that didn't
amount to much time.
Have you kept a list of such bugs/mistakes of yours for warp?
It is an
interesting list.
It's on github, though currently in a private repository. They
were the usual mix of stupid coding mistakes and adjustments
needed to match cpp's behavior.
I gave it a whirl on OSX Mavericks, Xcode 5.1
Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn)
a.cc contains only:
#include stdlib.h
$ ./warpdrive_clang3_4 -I /usr/include a.cc ~/a.pp
/usr/include/stdlib.h(92) : identifier expected after 'defined'
#if !__DARWIN_NO_LONG_LONG -- line 92
typedef struct {
long long quot;
long long rem;
} lldiv_t;
#endif /* !__DARWIN_NO_LONG_LONG */
Accelerating domain-specific languages in CTFE
Projects such as Pegged and our CTFE regex engine often serve as
poster-children of what is possible in D and many agree they are
among the more important projects.
I was thinking, after std.lexer is accepted, we have a stable
interface, but no matter how great the code is and even if it
beats the already superlative DMD lexer, it will _NOT_ be fast
during CTFE.
It is also often stressed in this very forum that it's paramount
for a lexer to be beyond fast.
For the above reasons, I propose that the compiler would offer an
interface to retrieve an already lexed buffer, similar in concept
to the existing token string q{...}
Token strings open with the characters q{ and close with the
token }. In between must be valid D tokens.
By definition they contain only valid tokens... the compiler
would only have to create a range compatible with std.lexer...
Re: DIP56 Provide pragma to control function inlining
On Sunday, 23 February 2014 at 12:07:40 UTC, Walter Bright wrote: http://wiki.dlang.org/DIP56 Manu has needed always inlining, and I've needed never inlining. This DIP proposes a simple solution. yay, all for it! The DIP should probably specify what happens if inlining fails, i.e. generate a compilation error. Could we consider adding flatten in the same dip? quote from gcc Flatten Generally, inlining into a function is limited. For a function marked with this attribute, every call inside this function is inlined, if possible. Whether the function itself is considered for inlining depends on its size and the current inlining parameters.
Re: DIP56 Provide pragma to control function inlining
On Sunday, 23 February 2014 at 12:57:00 UTC, Walter Bright wrote: On 2/23/2014 4:25 AM, Tove wrote: The DIP should probably specify what happens if inlining fails, i.e. generate a compilation error. I suspect that may cause problems, because different compilers will have different inlining capabilities. I think it should be a 'recommendation' to the compiler. Would assert be feasible or difficult to implement with the current compiler design? static assert(pragma(inline, true));
Re: DIP56 Provide pragma to control function inlining
On Sunday, 23 February 2014 at 21:53:43 UTC, Walter Bright wrote:
I'm aware of that, but once you add the:
version(BadCompiler) { } else pragma(inline, true);
things will never get better for BadCompiler. And besides, that
line looks awful.
If I need to support multiple compilers and if one of them is not
good enough, I would first try to figure out which statement
causes it to fail, if left with no other alternatives: Manually
inline it in the common path for all compilers, _not_ create
version blocks.
Inspecting asm output doesn't scale well to huge projects.
Imagine simply updating the existing codebase to use a new
compiler version.
Based on my experience, even if we are profiling and benchmarking
a lot and have many performance based KPI:s, they will still
never be as fine-grained as the functional test coverage.
Also not forgetting, some performance issues may only be detected
in live usage scenarios on the other side of the earth as the
developers doesn't even have access to the needed
environment(only imperfect simulations), in those scenarios you
are quite grateful for every static compilation error/warning you
can get...
You are right in that there is nothing special about inlining,
but I'd rather add warnings for all other failed optimisation
opportunities than not to warn about failed inlining. RVCT for
instance has --diag_warning=optimizations, which gives many
helpful hints, such as alias issues: please add restrict, or
possible alignment issues etc.
Re: D as A Better C?
On Wednesday, 12 February 2014 at 20:10:42 UTC, Jacob Carlborg wrote: (First off, I hate the name better C, any suggestions?) -no-runtime good choice and even if Walter is blocked on higher prio issues, we can still make it happen as a community.
Re: Two Questions
On Wednesday, 12 February 2014 at 20:23:55 UTC, Kagamin wrote: On Sunday, 9 February 2014 at 21:12:57 UTC, Jonathan M Davis wrote: And you get more memory out of the deal even if you have as little as 4GB in the box. I wish that everything would move to 64-bit so that we wouldn't have to even worry about 32-bit anymore. What's the advantage of having 64-bit OS on 4gb RAM? x32 is the obvious solution, best of both worlds: http://en.wikipedia.org/wiki/X32_ABI ... I really wonder why it has not yet gone mainstream.
Re: More Illuminating Introductory Code Example on dlang.org
On Wednesday, 12 February 2014 at 20:49:54 UTC, Nordlöw wrote: I believe the first code example a newbie sees when he/she first visits dlang.org should be some variation of Walter's showcase on Component Programming including all the bells and whistles of lazy evaluted ranges. IMHO, this would increase the probability of the newbie staying a bit further on the site trying to figure out the details of what make this intriguing D code example tick. And, as a result, be more convinced about D's unique and powerful features. What do you think, fellow D programmers? Absolutely and there is a process in place for this already, feel free to suggest something: [your code here] Got a brief example illustrating D? Submit your code to the digitalmars.D forum specifying [your code here] in the title. Upon approval it will be showcased on a random schedule on D's homepage.
Re: D as A Better C?
On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote: I've toyed with this idea for a while, and wondered what the interest there is in something like this. The idea is to be able to use a subset of D that does not require any of druntime or phobos - it can be linked merely with the C standard library. To that end, there'd be a compiler switch (-betterC) which would enforce the subset. (First off, I hate the name better C, any suggestions?) The subset would disallow use of any features that rely on: 1. moduleinfo 2. exception handling 3. gc 4. Object I've used such a subset before when bringing D up on a new platform, as the new platform didn't have a working phobos. What do you think? It's a Delightful(dlite?) idea, I long considered doing something like this as it would facilitate using D at work.
Re: Scott Meyers will deliver a keynote talk at DConf 2014
On Tuesday, 4 February 2014 at 20:34:29 UTC, Andrei Alexandrescu wrote: I'm happy to announce that Scott Meyers will deliver a keynote talk at the upcoming DConf 2014. Details of the talk are forthcoming. wow, this is fantastic news! *cheer*
Re: Disallow null references in safe code?
On Sunday, 2 February 2014 at 09:56:06 UTC, Marc Schütz wrote:
auto x = *p;
if(!p) {
do_something(x);
}
In the first step, the if-block will be removed, because its
condition is known to be false. After that, the value stored
into x is unused, and the dereference can get removed too.
With a good static analyzer, such as coverity, this program would
be rejected anyway with check_after_deref, if the compiler is
smart enough to do the optimization, it could be smart enough to
issue a warning as well!
Re: Range-Based Graph Search in D (blog post)
On Saturday, 11 January 2014 at 09:51:57 UTC, Peter Alexander wrote: On Thursday, 9 January 2014 at 22:53:02 UTC, qznc wrote: For the visitation API design: Your map approach (bool[Vertex] m_visited) is probably the most generic one. A variant, where the nodes store the flag internally is more efficient, though. Unless the graph is infinite ;-) But yes, for most graphs that would likely be more efficient than a hash lookup. I'll keep note of that. Thanks! I love the design, only some few minor tweaks needed(as already highlighted in this thread). Even without any changes, it fits my current needs and I'd like to use it already, am I right in assuming that it's Boost licensed?
Re: another cool RTInfo trick - i want in runtime
On Thursday, 16 January 2014 at 15:57:05 UTC, Adam D. Ruppe wrote: S yeah, this is pretty much a pure win all around to my eyes. Am I blind to the suck? Wow, great trick! I'd love to see this merged.
Re: dmd 2.064.2
On Thursday, 7 November 2013 at 16:25:47 UTC, Brad Anderson wrote: On Thursday, 7 November 2013 at 08:58:50 UTC, tester wrote: how do make that comiler work? [Issue 11457] New: Cannot compile 64bit apps with Visual Studio 2013 this is a desaster for me. was that release tested? if i amand the pathes and run as admin or not - it will not find the libs (user32) windoes8.1, visual studio2013, 64bit This never worked automatically before so I don't know how this could suddenly be a disaster. In this release the installer makes an attempt to detect your VC++ and SDK installation and fix up sc.ini to point to them. It's brand new and only a few people responded to my call for help testing it. Post your sc.ini and the paths to your Windows 8.1 SDK and Visual C++ 2013 installation. I run 32bit win7 with VS2013 so I normally do not test cross-compiling with -m64. The installer correctly found my installation directories: VCINSTALLDIR=C:\Program Files\Microsoft Visual Studio 12.0\VC\ WindowsSdkDir=C:\Program Files\Windows Kits\8.1\ But I needed to add the follwing to PATH(in order to find mspdb120.dll) %VCINSTALLDIR%\bin And the following to LIB, in order to find shell32.lib LIB=%LIB%;%WindowsSdkDir%\Lib\winv6.3\um\x64 Hope it helps.
Re: Programming in D book is about 95% translated
On Sunday, 3 November 2013 at 21:21:04 UTC, Joseph Rushton Wakeling wrote: On Saturday, 2 November 2013 at 22:45:13 UTC, Ali Çehreli wrote: I spent considerable amount of time on those names. Like you, I am not happy with Inverse. :) I'm not a native English speaker, but FWIW I would have chosen: http://en.wiktionary.org/wiki/numeric_complement
Re: More on C++ stack arrays
On Monday, 21 October 2013 at 01:48:56 UTC, Walter Bright wrote:
On 10/20/2013 5:59 PM, Jonathan M Davis wrote:
If that paradigm is frequent enough, it might be worth
wrapping it in a
struct. Then, you'd probably get something like
StaticArray!(int, 10) tmp(n);
int[] a = tmp[];
which used T[10] if n was 10 or less and allocated T[]
otherwise. The
destructor could then deal with freeing the memory.
Sounds like a good idea - and it should fit in with Andrei's
nascent allocator design.
Hmmm, it gave me a weird idea...
void smalloc(T)(ushort n, void function(T[]) statement)
{
if(n = 256)
{
if(n = 16)
{
T[16] buf = void;
statement(buf[0..n]);
}
else
{
T[256] buf = void;
statement(buf[0..n]);
}
}
else
{
if(n = 4096)
{
T[4096] buf = void;
statement(buf[0..n]);
}
else
{
T[65536] buf = void;
statement(buf[0..n]);
}
}
}
smalloc(256, (int[] buf)
{
});
Re: More on C++ stack arrays
On Sunday, 20 October 2013 at 19:42:29 UTC, Walter Bright wrote:
On 10/20/2013 12:23 PM, bearophile wrote:
Walter Bright:
No. But I do know that alloca() causes pessimizations in the
code generation, and it costs many instructions to execute.
Allocating fixed size things on the stack executes zero
instructions.
1) Alloca allows allocating in the parent context, which is
guaranteed to elide copying, without relying on a sufficiently
smart compiler.
ref E stalloc(E)(ref E mem = *(cast(E*)alloca(E.sizeof)))
{
return mem;
}
2) If only accessing the previous function parameter was
supported(which is just an arbitrary restriction), it would be
sufficient to create a helper-function to implement VLA:s.
3) Your fixed size stack allocation could be combined with
alloca also, in which case it likely would be faster still.
Re: std.d.lexer : voting thread
On Thursday, 3 October 2013 at 11:04:26 UTC, Dicebot wrote: Yes. ( I have not found any rules that prohibit review manager from voting :) ) I'd love to say yes, since I've been dreaming of the day when we finally have a lexer... but I decided to put my yes under the condition that it can lex itself using ctfe. My first attempt with adding a import(__FILE__) unittest failed with v2.063.2: Error: memcpy cannot be interpreted at compile time, because it has no available source code lexer.d(1966): called from here: move(lex) lexer.d(454):called from here: r.this(lexerSource(range), config) Maybe this is this fixed in HEAD though?
link-time codegen assert?
A very minimal example:
template ctfe(alias any)
{
alias ctfe = any;
}
double ms(double val) pure nothrow @property
{
if(__ctfe)
return val / 1000.0;
else
assert(false);
}
The above allows for writing...
ctfe!(10.ms)
... which is in natural reading order as opposed to...
ms!10
... but one would have to guard against users accidentally
writing...
10.ms
... which would be a catastrophic hidden performance bug.
I was not able to find a way to use static assert only when there
is code-generated for the function, so my question is. Do you see
a generic need for a 3rd type of assert or can you find a way to
solve the above issue in another way?
Re: link-time codegen assert?
On Tuesday, 1 October 2013 at 11:42:20 UTC, Tove wrote:
A very minimal example:
template ctfe(alias any)
{
alias ctfe = any;
}
double ms(double val) pure nothrow @property
{
if(__ctfe)
return val / 1000.0;
else
assert(false);
}
Turns out it was quite easy to solve...
void link_assert() pure nothrow; link_assert();
Re: Debug information for enumerator values
On Tuesday, 17 September 2013 at 09:52:37 UTC, Iain Buclaw wrote:
(gdb) print ('test.enum_ulong')3
$11 = (test.enum_ulong.kE2 | test.enum_ulong.kE3)
(gdb) print ('test.enum_ulong')2
$12 = test.enum_ulong.kE3
What do you think? Is module.name.member too verbose, or
just right? :-)
Regards
Iain
Kickass! I think it's just right... _BUT_ in case of multiple
values, I would prefer something like this:
$11 = test.enum_ulong(kE2 | kE3)
Re: std.d.lexer: pre-voting review / discussion
On Wednesday, 11 September 2013 at 15:02:00 UTC, Dicebot wrote: std.d.lexer is standard module for lexing D code, written by Brian Schott I remember reading there were some interesting hash-advances in dmd recently. http://forum.dlang.org/thread/kq7ov0$2o8n$1...@digitalmars.com?page=1 maybe it's worth benchmarking those hashes for std.d.lexer as well.
Re: VisualD now on github.com/d-programming-language
On Tuesday, 10 September 2013 at 06:42:06 UTC, Walter Bright wrote: https://github.com/D-Programming-Language/visuald Congratulations to Rainer Schuetze and collaborators for this great work! Horray! Great news. Some initial nit-picking: According to http://www.dsource.org/projects/visuald/wiki/Installation Visual Studio Shell 2012 is supported. But https://github.com/D-Programming-Language/visuald only mentions: * Supported Visual Studio versions - VS.NET 2003 (some limitations apply) - VS 2005 - VS 2008 - VS 2010 1) I assume that the full non express 2012 is supported also? 2) VS Shell 2010 link @ http://www.dsource.org/projects/visuald/wiki/Installation is broken. 3) Preferably the two links to The Visual Studio Shell 2012 should be visible in the github readme.
Re: VisualD now on github.com/d-programming-language
On Tuesday, 10 September 2013 at 18:10:33 UTC, Rainer Schuetze wrote: Thanks for pointing these out. The README didn't receive a lot of attention lately, most of the documentation and news is on the web site. I agree, with it being displayed on the front github page it should be updated. No problem, I thought of one additional idea to enhance first impressions... Is this stable enough to be made default enabled in future releases? Use Alexander Bothe's D parsing engine for semantic analysis writing '.' I only found it because I remember reading about it on this very forum, it is my fear that other new users won't find it and hence consider the intellisense-experience lacking. After enabling this tiny checkbox,... wow, I love it! Thanks again!
Re: new DIP47: Outlining member functions of aggregates
On Sunday, 8 September 2013 at 09:24:52 UTC, Michael wrote: On Sunday, 8 September 2013 at 09:15:52 UTC, Namespace wrote: I'm against it. More important than such a gimmick are the many open bugs, auto ref, AA, scope, etc. And don't forget the implementation of the virtual keyword. +1 I strongly dislike DIP47, I found many unintended discrepancies in our C code-base at work... precisely because of lax rules, even cases with wrong linkage as result! Parameter names need not match. If there is a default parameter value, it may only appear in the member function declaration. This forces indexing of source and jump to declaration features in the IDE, the current way is more friendly to simpler text-editors, the problem which DIP47 is trying to solve is anyway solved by IDE:s Class View feature etc. i.e. For people using IDE:s(class view, or ddoc) nothing changes with DIP47. For people using plain editors, DIP47 makes it worse. Even if DIP47 is implemented, I hope this feature is strongly discouraged in the standard library.
Re: new DIP47: Outlining member functions of aggregates
Wouldn't this style be an acceptable compromise instead? with
both declaration and definition 100% identical.
struct S
{
// member function declarations
static int mfunc1(int a, int b = 5) pure;
static int mfunc2(int a, int b = 5) pure;
static int mfunc3(int a, int b = 5) pure;
// member function definitions
static int mfunc1(int a, int b = 5) pure
{
}
static int mfunc2(int a, int b = 5) pure
{
}
static int mfunc3(int a, int b = 5) pure
{
}
}
Re: new DIP48: Interface specifications for aggregate types
On Sunday, 8 September 2013 at 18:13:52 UTC, Simen Kjaeraas wrote: In response to Walter's DIP47 I have created my own take on what I see as the main problem: http://wiki.dlang.org/DIP48 Destroy! I like it but would prefer @interface instead of interface Since using interface in this way, reminds me too much of nameless struct:s/union:s.
Re: param2 = param1
On Tuesday, 27 August 2013 at 21:21:31 UTC, Timon Gehr wrote: - Safe alloca wrapper using the alloca default argument hack together with this. (i.e. bearophile's dynamically-sized strongly typed stack-based arrays.) Oh Yes please! I've been waiting for this for a long time, there even was an enhancement request written to facilitate the alloca default argument hack! http://d.puremagic.com/issues/show_bug.cgi?id=8075
Re: std.serialization: pre-voting review / discussion
On Wednesday, 14 August 2013 at 08:48:23 UTC, Jacob Carlborg
wrote:
On 2013-08-14 10:19, Tyler Jameson Little wrote:
- Typo: NonSerialized example should read NonSerialized!(b)
No, it's not a typo. If you read the documentation you'll see
that:
If no fields or this is specified, it indicates that the
whole class/struct should not be (de)serialized.
I understand the need for Orange to be backwards compatible, but
for std.serialization, why isn't the old-style mixin simply
removed in favor of the UDA.
Furthermore for template NonSerialized(Fields...) there is an
example, while for the new style struct nonSerialized; there
isn't!
I find the newstyle both more intuitive and you also more dry not
duplicating the identifier: int b; mixin NonSerialized!(b)
@nonSerialized struct Foo
{
int a;
int b;
int c;
}
struct Bar
{
int a;
int b;
@nonSerialized int c;
}
Re: xdc: A hypothetical D cross-compiler and AST manipulation tool.
On Friday, 19 July 2013 at 13:38:12 UTC, Chad Joan wrote: Even with a conservative target like C89-only, there are still an incredibly large number of extremely useful D features (OOP, templates, scope(exit), CTFE, mixins, ranges, op-overloading, etc) that DO come for free. I love the idea behind xdc, but I would go with C99 instead, even MS as the last vendor(?), with VS2013 now finally committed to supporting C99, variable length arrays alone would make it worth it.
Re: The state of core.simd
On Saturday, 1 June 2013 at 10:18:27 UTC, Benjamin Thaut wrote: I've taken a look at core.simd and I have to say is unuseable. In a very small test program I already found 3 bugs 1) Using debug symbols together with core.simd will cause a ICE http://d.puremagic.com/issues/show_bug.cgi?id=10224 2) The STOUPS instruction is not correctly implemented: http://d.puremagic.com/issues/show_bug.cgi?id=10225 3) The XMM register allocation is catastrophic: http://d.puremagic.com/issues/show_bug.cgi?id=10226 Whats the current state of core.simd? Is it still beeing worked on? Because it its current state its pretty much unuseable. Kind Regards Benjamin Thaut does this generate better code? float4 v = __vector([1.0f, 2.0f, 3.0f, 4.0f]);
Re: The state of core.simd
On Saturday, 1 June 2013 at 10:57:03 UTC, Benjamin Thaut wrote: Am 01.06.2013 12:52, schrieb Tove: does this generate better code? float4 v = __vector([1.0f, 2.0f, 3.0f, 4.0f]); That doesn't even compile. You can try it out yourself using: http://dpaste.dzfl.pl/ Kind Regards Benjamin Thaut OK, sorry about that... this compiles, but the 'Disassembly' button is not functional for me... http://dpaste.dzfl.pl/1e0407c3
Re: I was wrong
On Friday, 31 May 2013 at 08:45:08 UTC, Dicebot wrote: On Thursday, 30 May 2013 at 18:06:03 UTC, Walter Bright wrote: about the changelog. Andrej Mitrovic has done a super awesome job with the changelog, and it is paying off big time. I am very happy to be proven wrong about it. It is so good I could not have even expected to see something like that. Andrej, awesome! I agree the changelog is awesometastic, but the run button could need some tweaks...
Re: I want to add a Phobos module with template mixins for common idioms.
On Friday, 10 May 2013 at 21:04:32 UTC, Idan Arye wrote: On Wednesday, 8 May 2013 at 20:11:34 UTC, Idan Arye wrote: OK, so I'm gonna go ahead and implement it, so I can show by example that the string solution can be typesafe, scalable and elegant. OK, this is a basic implementation: https://gist.github.com/someboddy/5557358 Before I can make the pull request, I still need to do documentation, add some asserts to make sure users don't declare methods or subtypes in the property declarations string, add some more unit tests, and add the other idiom(the singleton). But, it's still enough for demonstrating that strings are not evil, and that their usage here does not brake type safety, scope, or anything else. kickass technique, hope this get included soon, keep up the good work!
Re: Rvalue references - The resolution
On Sunday, 5 May 2013 at 07:22:06 UTC, Jonathan M Davis wrote: Now, I argued that pure's primary benefit isn't really in optimizations but rather in the fact that it guarantees that your code isn't accessing global state, but there's still the general concern that there's a lot of new attributes to worry about, whether you choose to use them or not. I don't think that it was a deal-breaker for Don or anything like that, but it was one of his concerns and one more item on the list of things that makes it more costly for them to move to D2, even if it alone doesn't necessarily add a huge cost. - Jonathan M Davis Assuming: 1. functioning attribute inference 2. attributes are expanded in the *.di file Then, it would be trivial to create a tool which, upon request, merges a defined set of attributes back to the original d source file, this would reduce some of the burden and with full IDE integration even more so.
Re: Rvalue references - The resolution
On Saturday, 4 May 2013 at 18:33:04 UTC, Walter Bright wrote: Runtime Detection There are still a few cases that the compiler cannot statically detect. For these a runtime check is inserted, which compares the returned ref pointer to see if it lies within the stack frame of the exiting function, and if it does, halts the program. The cost will be a couple of CMP instructions and an LEA. These checks would be omitted if the -noboundscheck compiler switch was provided. Thanks for taking the time to detail the solution, I was quite curious. Runtime Detection and opt-out with -noboundscheck is a stroke of genius! couple of CMP instructions should be possible to reduce to only one with the normal unsigned range check idiom, no? Looking forwards to hear more cool news. :)
Re: 1 matches bool, 2 matches long
On Friday, 26 April 2013 at 21:01:17 UTC, Brian Schott wrote: On Friday, 26 April 2013 at 06:01:27 UTC, Walter Bright wrote: The real issue is do you want to have the implicit conversions: 0 = false 1 = true or would you require a cast? The idea of a true number and a false number doesn't make sense, so yes. I find the current implementation perfectly intuitive and I wouldn´t want it any other way... it models the underlying hardware, just the way it should be. Sometimes due to bad coding standards I´m forced to write... if((.long expression with not immediately apparent operator precedence)!=0) ... absolutely appalling, kills readability with extra () etc. doesn´t matter how many years, I was forced to do it, I still cringe every time I see a line like that and itch to rewrite it more readable. I also dont know any book(including Knuth), nor online article, which doesn´t clearly define it as 0,1... am very confused by the reactions in this thread, is my background so different from everyone elses?
Re: Mixin template parameters / mixin template literals
On Wednesday, 24 April 2013 at 02:18:07 UTC, Luís Marques wrote:
Consider:
sort!(a b)(array);
how about?
sort!(q{a b})(array);
http://dlang.org/lex.html#TokenString
Re: rvalue references
On Wednesday, 24 April 2013 at 12:38:19 UTC, Andrei Alexandrescu wrote: On 4/24/13 6:27 AM, Diggory wrote: Anyway, it seems in general that everyone thinks DIP25A should be implemented, or am I mistaken? I'd like to work a bit more on it before a formal review. Andrei If you find the time one day, please revisit the Taking address section. I'm convinced that the goal of DIP25 could be fully realized even with some of the restrictions relaxed/lifted, with less code-breakage as result. In particular: Allowing '' for non-ref parameters and Stack-allocated locals in @system. It encourages bad programming style where heap is preferred over stack, just to silence the compiler. Yes '' is dangerous but it's a separate issue, why conflate a Sealed references DIP with restrictions on normal non ref C-style systems programming? Thanks for reading this far...
Re: rvalue references
On Tuesday, 23 April 2013 at 07:18:41 UTC, Diggory wrote: I'd still like someone to explain how exactly scope ref would differ from ref if DIP25/DIP35 were implemented. If the only difference is that scope ref can accept rvalues then why would you ever use normal ref? There are no extra restrictions needed on scope ref over and above normal ref under the assumption of DIP25/DIP35. DIP25 imposes a number of code-breaking restrictions even in @system code, if DIP36 was in place, one could consider imposing the DIP25 restrictions only in SafeD. Furthermore if one day the compiler would be sufficiently smart to infer scope automatically, there still would be an important difference between 'ref' and 'scope ref'. ref rvalue ref would only work if the compiler succeeds in inferring scope, it could take a conservative approach to make sure it always err:s in the harmless direction... i.e. any '' or any asm block is an automatic failure. scope ref Works unless the compiler can prove it wrong(also usable from SafeD if marked with @trusted).
Re: rvalue references
On Tuesday, 23 April 2013 at 09:06:52 UTC, deadalnix wrote: On Tuesday, 23 April 2013 at 08:41:16 UTC, Tove wrote: DIP25 imposes a number of code-breaking restrictions even in @system code, if DIP36 was in place, one could consider imposing the DIP25 restrictions only in SafeD. Furthermore if one day the compiler would be sufficiently smart to infer scope automatically, there still would be an important difference between 'ref' and 'scope ref'. That is the important issue to solve. Many solution can jeopardize DIP36, which is why it must be delayed. Usually conflating issue in adhoc solution ends up in crap that must be sorted out later. I see it as a future proof feature, not an issue. You want it to be a difference, so you can override the default compiler behavior.
Re: DIP 36: Rvalue References
On Monday, 22 April 2013 at 20:02:12 UTC, Andrei Alexandrescu wrote: 4. Above all this is a new language feature and again we want to resort to adding new feature only if it is clear that the existing features are insufficient and cannot be made sufficient. In particular we are much more inclined to impart real, demonstrable safety to ref and to make auto ref work as a reference that can bind to rvalues as well as lvalues. Why isn't DIP36 scope ref be future compatible with a future safe auto ref? ... and if in the future the compiler would be able to infer scope ref from auto ref, this entire DIP could be reused, with the benefit that people could start using this functionality already today(there is a full pull request with a very small delta), before the auto inference is in place.
Re: Vote for std.process
On Friday, 12 April 2013 at 15:43:27 UTC, Steven Schveighoffer wrote: On Fri, 12 Apr 2013 04:14:15 -0400, Manu turkey...@gmail.com I'd use string[]. You mean with format a=b? I suppose that's possible, though horrible to work with before passing in. Plus what happens if you have [a=b, a=c] ? AA's prevent these kinds of mistakes/contradictions. I prefer Manu's idea with the API accepting string[], it's closer to the native format. Then you could simply provide a convenience conversion from a map... ex env![foo : bar] which would convert it to [foo=bar]. This also has the added benefit of being self documenting(considering the lack of named parameters). But most importantly So the user has a free choice of constructing the env parameter manually in the most efficient way or using the lazy convenience function.
Re: Vote for std.process
On Friday, 12 April 2013 at 20:24:05 UTC, Steven Schveighoffer wrote: On Fri, 12 Apr 2013 15:26:12 -0400, Tove t...@fransson.se wrote: So for the most convenient/common case, you want to add an allocation? with the original proposal there is one anyway... But with my suggested approach you could create many processes reusing the same env... only paying the conversion/allocation cost once(outside of the loop).
Re: Vote for std.process
On Friday, 12 April 2013 at 20:52:55 UTC, Steven Schveighoffer wrote: On Fri, 12 Apr 2013 16:32:37 -0400, Tove t...@fransson.se wrote: On Friday, 12 April 2013 at 20:24:05 UTC, Steven Schveighoffer wrote: On Fri, 12 Apr 2013 15:26:12 -0400, Tove t...@fransson.se wrote: So for the most convenient/common case, you want to add an allocation? with the original proposal there is one anyway... I meant add an additional allocation to what is there. There needs to be one allocation to collect all the variables into one long string (on Windows), and with your suggestion, it has to go through an intermediate key=value format. But with my suggested approach you could create many processes reusing the same env... only paying the conversion/allocation cost once(outside of the loop). This would be attractive. But I still want a indexable object. Having to generate a=b strings is awkward. It could be something that does the right thing on POSIX (generate a=b under the hood) or Windows (Probably can cache the generated environment string). -Steve Hmhm, I see your point. Could our custom indexable object have 'alias this' to an 'union env'? which is the in param to the process api?
Re: optional parens everywhere except last position of function chain.
On Wednesday, 27 February 2013 at 18:55:37 UTC, timotheecour wrote: Please let me know what you think. spontaneously... I love it!
Re: Java binaries
On Sunday, 17 February 2013 at 03:26:13 UTC, js.mdnq wrote: Would it ever be possible to compile D source directly to java to take advantage of what java offers. (e.g., the ability to run d code inside a browser) I'm not talking about necessarily fully fledged functionality(obviously stuff like asm isn't going to work) but basically the ability to use D's syntax and some of it's compiler features(mixins, templates, etc). depends on what you mean with run inside a browser, I would use NaCl instead, if I wanted to run D in a browser, but of course it requires Chrome. http://code.google.com/p/nativeclient/
Re: DIP23 draft: Fixing properties redux
On Wednesday, 6 February 2013 at 01:40:37 UTC, Andrej Mitrovic
wrote:
On 2/6/13, Jonathan M Davis jmdavisp...@gmx.com wrote:
That's why some of us have suggested
making it so that you can mark variables with @property.
What Jonathan means is this:
struct S
{
int var; // modifiable, can take address
}
Now suppose later you want to turn var into a property:
struct S
{
@property int var();
@property void var(int);
}
This potentially breaks code if the user-code was using a
pointer to
the public var field in the previous version of your library.
So instead we should have the ability to annotate fields with
@property:
struct S
{
@property int var; // modifiable, can *not* take address
}
There's no run-time cost, but it disallows taking the address
of var,
and it allows you to introduce property functions in the future
without breaking user-code.
It is also possible to first start with setters/getters and then
switch to a public field(!)
Which leads to the conclusion, in order for the property
abstraction to be complete, address taking of *anything*
annotated with @property should either NOT be allowed...
@property int var(); // can *not* take address
@property void var(int); // can *not* take address
@property int var; // can *not* take address
... or we have to guarantee that the type remains unchanged...
which is problematic due to different types of the getter and
setter, which would force one to always specify the expected type
rather than relying on auto.
@property int var;
int delegate()d_get = var;
void delegate(int) d_set = var;
Re: Alias syntax removal
On Sunday, 10 February 2013 at 14:42:50 UTC, kenji hara wrote:
2013/2/10 kenji hara k.hara...@gmail.com
Why I argue that the syntax `alias this = sym;` is wrong?
Because:
Benefits of the proposed syntax are:
2a. It is consistent with class inheritance syntax `class C : B
{}`.
2b. It is scalable for multiple alias this feature, as like
`alias this
: sym1, sym2, ...;` .
2a. I agree.
2b. I always assumed multiple alias would be introduced like
this...
alias this = sym1;
alias this = sym2;
... which also is needed if you use a 3rd party library mixin
in your struct(which internally uses alias this), so even with
the ':' syntax it's anyway required to support being able to use
it multiple times:
alias this : sym1;
alias this : sym2;
So I don't think 2b speaks in favor of the new syntax.
Re: DIP25 draft available for destruction
On Wednesday, 6 February 2013 at 21:40:00 UTC, Andrei
Alexandrescu wrote:
On 2/6/13 3:02 PM, Andrej Mitrovic wrote:
Also the DIP argues that addressOf solves the @property issue
w.r.t.
return values. I've proposed we use an .addressOf property
which only
works on @property functions, and I saw no arguments against
it.
There aren't, but a library approach is better than a magic
work, all other things being equal.
Andrei
struct S
{
@property int var();
@property void var(int);
}
The .addressOf property gave me the idea of solving the
getter/setter issue, by having two properties...
var.getter
var.setter
maybe it could be added to your library approach though?
Re: DIP26: properties defined
On Saturday, 9 February 2013 at 03:13:47 UTC, Michel Fortin wrote: It's really great to not have to write boilerplate functions when default behaviour is perfectly fine. I've been using Objective-C for a while now and the recent changes where it automatically synthesize a variable, a getter, and a setter when declaring a property (unless you provide your own) are truly delightful. @property int a; I would prefer if @property simply disallows '' then it doesn't have to be lowered into anything and can stay a field... if you later decide to add a real getter/setter, it still would be source compatible and you wouldn't have to refactor the source.
Re: DIP23 draft: Fixing properties redux
On Monday, 4 February 2013 at 16:01:45 UTC, Steven Schveighoffer wrote: @property int foo(); auto x = foo; // error int delegate() x = foo; // ok -Steve I was going to submit the same suggestion, but didn't find time to until just now. gets my vote.
Re: Request for comments: std.d.lexer
On Friday, 1 February 2013 at 11:06:02 UTC, Walter Bright wrote: On 1/30/2013 8:44 AM, Dmitry Olshansky wrote: In allocation scheme I proposed that ID could be a 32bit offset into the unique identifiers chunk. That only works if you know in advance the max size the chunk can ever be and preallocate it. Otherwise, you have no guarantee that the next allocated chunk will be within 32 bits of address of the previous chunks. This can easily be archived by preallocating file.size bytes... it will be x orders of magnitude too much, but it doesn't matter, as in the end only the cache locality matters.
Re: Implementing Half Floats in D
On Monday, 28 January 2013 at 23:58:40 UTC, Walter Bright wrote: On 1/28/2013 3:30 PM, Era Scarecrow wrote: On Monday, 28 January 2013 at 23:11:11 UTC, Walter Bright wrote: http://www.drdobbs.com/cpp/implementing-half-floats-in-d/240146674 Anyone care to do the reddit honors? [quote] and crushed back down to 16 bytes for storage. [/quote] Should be bits. Otherwise it looks really well done. thank you. Sorry that didn't get caught in review! HalfFloat h = hf!1.3f; Maybe you could also demonstrate that it's possible to implement another literal syntax? HalfFloat h = 1.3.hf; some people will prefer that for sure.
Re: dmd json file output
On Tuesday, 22 January 2013 at 08:02:26 UTC, Rainer Schuetze
wrote:
type : {
mangled : PPPi,
pretty : int***,
}
I would favour plain type : int***.
Consider it will be parsed from many different languages, C#,
Java... etc and the generic tools may be able to handle json from
multiple languages, and in this context have no reason to use
differently mangled types for different languages.
int*** is both compact and easy enough to parse anyway.
Even for pure D-based tools, for unit-test reasons it could be
useful to have the pretty name to compare against, thus Rainer's
proposal is a reasonable compromise.
Re: manual memory management
On Wednesday, 9 January 2013 at 20:16:04 UTC, Andrei Alexandrescu wrote: On 1/9/13 12:09 PM, Mehrdad wrote: It's memory-safe too. What am I missing here? What you're missing is that you define a store that doesn't model object references with object addresses. That's what I meant by references are part of the language. If store is modeled by actual memory (i.e. accessing an object handle takes you to the object), you must have GC for the language to be safe. If store is actually indirected and gives up on the notion of address, then sure you can implement safety checks. The thing is everybody wants for references to model actual object addresses; indirect handles as the core abstraction are uninteresting. Andrei Quote from OpenBSD's malloc implementation: On a call to free, memory is released and unmapped from the process address space using munmap. I don't see why this approach is less safe than a GC... in fact, I claim it's safer, because it's far simpler to implement, and thus less likely to contain bugs and in addition it's easy to make performance vs safety trade-offs, simply by linking with another memory-allocator.
Re: Accessing UDA of private field
On Monday, 7 January 2013 at 10:19:45 UTC, Jacob Carlborg wrote:
On 2013-01-06 23:33, Philippe Sigaud wrote:
Good thinking. It's not pretty but it works. Thanks.
Maybe it can be hidden inside a template?
Yeah, I'll see what I can do.
in which context does private fail? I'm using something like this:
struct my_struct
{
private:
@(1) int t1;
@(2) int t2;
@(3) int t3;
}
foreach(m; __traits(allMembers, my_struct))
with(my_struct.init)
pragma(msg, __traits(getAttributes, mixin(m)));
Re: Accessing UDA of private field
On Monday, 7 January 2013 at 13:36:47 UTC, Jacob Carlborg wrote:
On 2013-01-07 12:59, Tove wrote:
in which context does private fail? I'm using something like
this:
struct my_struct
{
private:
@(1) int t1;
@(2) int t2;
@(3) int t3;
}
foreach(m; __traits(allMembers, my_struct))
with(my_struct.init)
pragma(msg, __traits(getAttributes, mixin(m)));
Using a mixin works.
but this seems to work too?
import std.traits;
struct my_struct
{
private:
@(1) int t1;
@(2) int t2;
@(3) int t3;
}
void main()
{
foreach(m; __traits(allMembers, my_struct))
pragma(msg, __traits(getAttributes, __traits(getMember,
my_struct, m)));
}
Re: [OT] Three Optimization Tips for C++
On Friday, 21 December 2012 at 16:28:35 UTC, Andrei Alexandrescu wrote: use text based formats for performance sensitive data! Of course, maybe the 15% claim was pure exaggeration. I really hope that's the case. Text representation has its own advantages. Andrei interesting, does it have to be base 10? would it not be feasible to use hex strings in some scenarios? possible with bswap, or bitscan etc?
Re: Fixing cyclic import static construction problems
On Friday, 30 November 2012 at 14:09:48 UTC, foobar wrote:
Why not simplify?
static this()
{
import std.stdio, a, c; // existing syntax
...
}
static this()
{ // no imports - no dependencies
...
}
The current behavior should just be dropped.
+2
Simple Elegant.
Re: User Defined Attributes
On Thursday, 15 November 2012 at 22:04:27 UTC, David Nadlinger
wrote:
On Thursday, 15 November 2012 at 08:45:49 UTC, Tove wrote:
I disagree, you can always fallback to using user defined
types... but it _allows_ for native types also, i.e. more
flexible.
You are missing the point: In your proposal, if you want to use
two libraries together which are expecting you to provide e.g.
'int' annotations, you are screwed. This is a big, BIG problem.
David
no, I implied the solution already... actually there are many
different ways to solve it... some possible today, some require
new minor support features(like sending the annotated symbol as a
template alias parameter to the annotation)... but could give us
compile time errors when ambiguity is detected.
In the common case there are no collisions, so most of the time
we can use the nice user-friendly syntax!
[lib1.x]
struct User
{
[1] int uid;
}
But we _can_ disambiguate when needed...
[lib1.x, lib2.y]
struct User
{
[lib!1, lib2!2] int uid; // ok
[1, lib2!2] int uid; // ok
[lib1!1, 2] int uid; // ok
[1,2] int uid; // not supported
[1] int uid; // not supported
}
lib2 doesn't have to know about lib1.
lib1 doesn't have to know about lib2.
Because they just have to check the annotation in _prioritized_
order.
1. find my unique lib2.y symbol
2. if there is a lib2!uint on a nested symbol, use it...
3. if not check for a native int.
Re: User Defined Attributes
On Friday, 16 November 2012 at 10:41:44 UTC, Walter Bright wrote:
The whole point of my example was no, you do not necessarily
know the meaning of a user-defined type that is used as an
attribute.
Agree. Imagine we have 3 generic libs/modules...
Optimized CTFE Polygon Primitive Lib, Math, Gfx
... and then the end user, creates a program.
Both Math and Gfx, want to use the optimized Polygon in their
modules...
[Polygon(...)]
struct SpaceShip
{
}
This is just as ambiguous as if you had used a built-in int:s...
and it can be solved in the exact same way which I outlined in
the other thread.
Re: User Defined Attributes
On Wednesday, 14 November 2012 at 23:57:38 UTC, David Nadlinger wrote: Also, your solution is more complex than simply using types, yet less flexible: What if you want to use uint attributes from two libraries on the same type? David I disagree, you can always fallback to using user defined types... but it _allows_ for native types also, i.e. more flexible.
Re: User Defined Attributes
On Wednesday, 14 November 2012 at 11:08:04 UTC, Leandro Lucarella
wrote:
Can you provide one concrete case where it makes sense NOT to
restrict UDAs to
types and it's different from restricting exception to classes
derived from
Exception?
Thank you.
There was the example with Thrift...
struct UserProfile {
1: i32 uid,
2: string name,
3: string blurb
}
service UserStorage {
void store(1: UserProfile user),
UserProfile retrieve(1: i32 uid)
}
You could use a user defined type for the struct... but for the
members it would make sense to use the native type directly...
and if you traverse the annotation in sequence rather than as
standalone entities.. it's perfectly safe to use 1,2,3 as
annotation...
i.e. first scan for the Thrift symbol, then scan for native typed
int:s...
Re: User Defined Attributes
On Wednesday, 14 November 2012 at 12:33:58 UTC, Jacob Carlborg
wrote:
I assume you mean something like:
struct UserProfile {
[1] i32 uid;
[2] string name;
[3] string blurb;
}
In that case I would much rather prefer this:
struct UserProfile {
@Id(1) i32 uid;
@Id(2) string name;
@Id(3) string blurb;
}
Where Id is thrift.attributes.Id or something similar.
well, similar... but beginning with a symbol...
[thrift.attributes.Definition]
struct UserProfile
{
[1] i32 uid;
[2] string name;
[3] string blurb;
}
Re: User Defined Attributes
On Wednesday, 14 November 2012 at 13:03:18 UTC, David Nadlinger
wrote:
On Wednesday, 14 November 2012 at 11:18:28 UTC, Tove wrote:
There was the example with Thrift...
struct UserProfile {
1: i32 uid,
2: string name,
3: string blurb
}
service UserStorage {
void store(1: UserProfile user),
UserProfile retrieve(1: i32 uid)
}
You could use a user defined type for the struct... but for
the members it would make sense to use the native type
directly... and if you traverse the annotation in sequence
rather than as standalone entities.. it's perfectly safe to
use 1,2,3 as annotation...
But what if you want to use that struct with another library as
well, for which you might also want to tack some ids on the
fields? I'm the author of the current D implementation in
Thrift, and if/when user defined attributes become stable and
I'll amend it to take advantage of UDAs, I'll definitely not go
for raw literals…
David
// in this nested scope, all uints are interpreted as belonging
to the thrift module.
[std.attributes(uint, thrift)]
struct UserProfile
...
// error detected at compile-time
[std.attributes(uint, thrift), std.attributes(uint, thrift2)]
struct UserProfile
...
Re: function overload on full signature?
On Wednesday, 14 November 2012 at 06:52:57 UTC, Rob T wrote:
On Wednesday, 14 November 2012 at 02:01:56 UTC, Jonathan M
Davis wrote:
Is there anything like C++ conversion operators in D? I have
used conversion ops in C++ and may want to use a similar
feature in D if available.
--rt
it would be a very useful feature to allow overload on void and 1
other type... as sometimes the return is very expensive to
calculate... I have seen this trick used by compiler build-in
functions.
struct A
{
int i;
string s;
alias i this;
alias s this;
}
but... 2 alias this are not currently allowed.
Re: User Defined Attributes
On Wednesday, 7 November 2012 at 08:41:48 UTC, Walter Bright wrote: New version up now with a couple reported problems with UDA fixed. I may have found a little glitch...? mixin([1] int a;); [[2] int b;] int c; mixin(__traits(getAttributes, c)[0]); pragma(msg, __traits(getAttributes, a)); = tuple() pragma(msg, __traits(getAttributes, b)); = tuple() The use-case for this is parsing a foreign language which will be compiled to mixed in d-code.
Re: User Defined Attributes
On Tuesday, 6 November 2012 at 07:55:51 UTC, Walter Bright wrote: References: http://www.digitalmars.com/d/archives/digitalmars/D/Custom_attributes_again_163042.html http://www.digitalmars.com/d/archives/digitalmars/D/custom_attribute_proposal_yeah_another_one_163246.html Inspired by a gallon of coffee, I decided to get it implemented. It's simple, based on what D already does (CTFE [*drool*, totally perfect awesomeness] Thanks!
Re: User Defined Attributes
Tooo much fun! Argh, _must_ _stop_ _playing_ and actually work ;(
[int a;]
class A
{
}
class B : A
{
mixin(__traits(getAttributes, typeof(super))[0]);
}
can't wait to see all the creative uses this will enable!
Re: User Defined Attributes
On Tuesday, 6 November 2012 at 13:14:50 UTC, Adam D. Ruppe wrote:
On Tuesday, 6 November 2012 at 07:55:51 UTC, Walter Bright
wrote:
User Defined Attributes (UDA) are compile time expressions
that can be attached to a declaration.
Hmmm, it didn't work on the most important place for my use
case, function parameters:
void a([test] int foo) {
pragma(msg, __traits(getAttributes, foo));
}
Hmmm, actually it doesn't work in plain function/block scope
either.
void a()
{
[test] int foo;
pragma(msg, __traits(getAttributes, foo));
}
Error: found 'int' when expecting ';' following statement
Re: User Defined Attributes
On Tuesday, 6 November 2012 at 15:19:53 UTC, Walter Bright wrote: On 11/6/2012 7:14 AM, Tove wrote: Hmmm, actually it doesn't work in plain function/block scope either. Right, I don't see a compelling purpose for that, either. Hmm, what about library based GC annotations? [GC.NoScan] int* local_p;
Re: Remus
On Sunday, 7 October 2012 at 19:41:30 UTC, Jacob Carlborg wrote: On 2012-10-07 19:32, Namespace wrote: amazing, good work...! what license is this under, is it allowed to be used commercially?
Re: Feature request: extending comma operator's functionality
On Friday, 5 October 2012 at 13:47:00 UTC, monarch_dodra wrote:
On Friday, 5 October 2012 at 00:22:04 UTC, Jonathan M Davis
wrote:
On Friday, October 05, 2012 02:08:14 bearophile wrote:
[SNIP]
Regarding definition of variables in D language constructs,
there
is one situation where sometimes I find D not handy. This code
can't work:
do {
const x = ...;
} while (predicate(x));
You need to use:
T x;
do {
x = ...;
} while (predicate(x));
Yeah. That comes from C/C++ (and is the same in Java and C#, I
believe). I
don't know why it works that way. It's definitely annoying.
[SNIP]
- Jonathan M Davis
Because it's the only way to guarantee that x exits when you
reach the end of the loop.
do {
if(true) continue; //Yawn... skip.
const x = ... ;
} while (predicate(x)); //What's x?
Basic goto limitations. Unlike goto though, inserting a
continue should never create a compile error, so the compiler
*has* to guarantee that the if condition references nothing
inside its own block.
It is annoying, but nothing that can't be fixed with a scope
bloc.
There is a simple way around this... which addresses both
concerns raised...
1. Semantics of old code is unchanged.
2. no issue with 'continue'
do(const x = ...)
{
}
while(predicate(x));
Re: Feature request: extending comma operator's functionality
On Friday, 5 October 2012 at 00:22:04 UTC, Jonathan M Davis wrote:
On Friday, October 05, 2012 02:08:14 bearophile wrote:
Tommi:
Maybe we forget about commas then, and extend if-clauses so
that you can properly define variables at the beginning of
it.
Separated by semicolons.
Regarding definition of variables in D language constructs,
there
is one situation where sometimes I find D not handy. This code
can't work:
do {
const x = ...;
} while (predicate(x));
You need to use:
T x;
do {
x = ...;
} while (predicate(x));
Don't forget the with statement, it's not just for switches! In
many cases it's actually even better than the proposed changes
_and_ it works today!
import std.stdio;
struct d_is_beautiful
{
int a=1;
int b=2;
}
void main()
{
with(d_is_beautiful()) if(a==1)
writeln(ok);
else
writeln(ko:, a);
with(d_is_beautiful()) do
{
++a;
writeln(iter);
}
while(a!=b);
}
Re: Review of Andrei's std.benchmark
On Friday, 21 September 2012 at 04:44:58 UTC, Andrei Alexandrescu wrote: Andrei Alexandrescuseewebsiteforem...@erdani.org wrote: My claim is unremarkable. All I'm saying is the minimum running time of an algorithm on a given input is a stable and indicative proxy for the behavior of the algorithm in general. So it's a good target for optimization. I reached the same conclusion and use the same method at work. Considering min will converge towards a stable value quite quickly... would it not be a reasonable default to auto detect when the min is stable with some degree of statistical certainty...?
Re: Formatted read consumes input
On Friday, 24 August 2012 at 11:18:55 UTC, Dmitry Olshansky wrote: C's scanf is a poor argument as it uses pointers instead of ref (and it can't do ref as there is no ref in C :) ). Yet it doesn't allow to read things in a couple of calls AFAIK. In C scanf returns number of arguments successfully read not bytes so there is no way to continue from where it stopped. BTW it's not documented what formattedRead returns ... just ouch. Actually... look up %n in sscanf it's wonderful, I use it all the time.
Re: Example of Rust code
On Friday, 10 August 2012 at 12:32:28 UTC, bearophile wrote:
This second D version uses the same class definitions, but
allocates the class instances on the stack. The code is bug
prone and ugly. The other disadvantages are unchanged:
void main() {
import std.stdio;
import std.conv: emplace;
import core.stdc.stdlib: alloca;
enum size_t size_Val = __traits(classInstanceSize, Val);
enum size_t size_Plus = __traits(classInstanceSize, Plus);
enum size_t size_Minus = __traits(classInstanceSize, Minus);
Val e1 = emplace!Val(alloca(size_Val)[0 .. size_Val], 5);
Val e2 = emplace!Val(alloca(size_Val)[0 .. size_Val], 3);
Val e3 = emplace!Val(alloca(size_Val)[0 .. size_Val], 1);
Plus e4 = emplace!Plus(alloca(size_Plus)[0 .. size_Plus],
e2, e3);
Minus ex2 = emplace!Minus(alloca(size_Minus)[0 ..
size_Minus], e1, e4);
writeln(Val: , eval(ex2));
}
Probably there are ways to improve my D versions, or to write
better versions.
Bye,
bearophile
I think version 2 would be the easiest one to improve, by
including a combined emplace/alloca convenience function in
Phobos for this common use-case.
See the technique used in:
http://www.digitalmars.com/d/archives/digitalmars/D/run-time_stack-based_allocation_166305.html
auto Create(void* buf=alloca(frame_size))
Re: Destructor nonsense on dlang.org
On Thursday, 24 May 2012 at 15:43:57 UTC, Alex Rønne Petersen wrote: We just need a dispose pattern whereby explicit dispose() instructs the GC to not finalize. So I'm curious, what resource are we trying to free here? None. I just came across it in the docs and found it completely insane. Hmm... well, as long as it's optional behavior... as in my case I actually want to go in the opposite direction... short-lived tool which claims x resources and is run once for every file... So in this case, resources should be free:ed _unless_ it's at program termination... as then it just slows down the shutdown procedure, the OS reclaim it faster anyway.
