On Wednesday, 5 August 2015 at 16:44:03 UTC, jmh530 wrote:
On Wednesday, 5 August 2015 at 08:53:39 UTC, Benjamin Thaut
wrote:
Regarding D's GC and Games written in D you can also take a
look at a old project of mine and the results that came out of
it.
http://3d.benjamin-thaut.de/?p=20
On Thursday, 30 July 2015 at 13:44:41 UTC, deadalnix wrote:
On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:
D is really cool and makes a good candidate for developing a
game. Are there any guys out there using D for indie games?
For some time I have been seeing some cool game
On Friday, 17 July 2015 at 17:18:16 UTC, roaming wrote:
On Friday, 17 July 2015 at 13:48:25 UTC, anonymous wrote:
On Friday, 17 July 2015 at 13:42:33 UTC, roaming wrote:
On Thursday, 16 July 2015 at 12:06:46 UTC, Kagamin wrote:
http://rainers.github.io/visuald/visuald/StartPage.html
On Monday, 20 July 2015 at 14:51:57 UTC, Jonathan M Davis wrote:
On Monday, 20 July 2015 at 14:18:33 UTC, David Nadlinger wrote:
Am I missing something here, or is this a major bug in struct
lifetime handling?
I understand why this happens from the DMD source, but it
almost seems like it was
This talk is really good and contains a lot of usefull
information very densly packed:
https://www.youtube.com/watch?v=vzzABBxo44g
The speaker has 30 years of experience working on javas hotspot
vm and shares his opinions on what you should do. My takeaways
from this talk are:
GC:
-You want
On Thursday, 16 July 2015 at 17:52:33 UTC, rsw0x wrote:
On Thursday, 16 July 2015 at 17:30:06 UTC, Benjamin Thaut wrote:
This talk is really good and contains a lot of usefull
information very densly packed:
https://www.youtube.com/watch?v=vzzABBxo44g
[...]
Treating D's GC the same as a
On Thursday, 16 July 2015 at 17:37:44 UTC, Justin Whear wrote:
On Thu, 16 Jul 2015 17:30:05 +, Benjamin Thaut wrote:
The speaker has 30 years of experience working on javas
hotspot vm
How is this possible? Time travel?
I confused that one. He actually states that he has 35 years of
On Friday, 12 June 2015 at 14:39:55 UTC, Chris wrote:
I wish it were an error in the Python code so I could fix it,
but it works on all other machines (at least those with Intel).
It's only on the HP625 with AMD that this error occurs. Another
DLL (which isn't mine) also failed to load,
On Monday, 1 June 2015 at 18:14:40 UTC, Andrei Alexandrescu wrote:
On 6/1/15 11:11 AM, Andrei Alexandrescu wrote:
What other large topics for 2.068?
I'm still working on Windows DLL support whenever I find time,
and I hope to get it done for 2.068 or 2.069
Kind Regards
Benjamin Thaut
On Wednesday, 13 May 2015 at 11:27:18 UTC, Logan Capaldo wrote:
Yes it won't happen for explicit LoadLibrary's and
GetProcAddresses, but COM or other plugin systems is an example
of a situation where many DLLs may expose the same named
symbols with different definitions, and there may be
On Wednesday, 13 May 2015 at 08:53:10 UTC, Kagamin wrote:
There was no word about windows, but process explorer shows
page faults and cycles per process from unprivileged account,
so I guess, this information is available through some API. Not
sure is such system-wide statistics is available
On Wednesday, 13 May 2015 at 12:05:48 UTC, Timon Gehr wrote:
On 05/13/2015 12:51 PM, iackhtak wrote:
There was discussion about broken contract programing. One
broken
thing was in contract within inheritance. If you add
different
in-contract in overridden parent and derived function only
one
On Wednesday, 13 May 2015 at 12:57:35 UTC, Logan Capaldo wrote:
a.dll provides symbol s1
b.dll provides symbol s1
c.dll imports symbol s1 from a.dll, provides symbol s2
d.dll imports symbol s1 from b.dll, provides symbol s3
e.exe imports symbol s2 from c.dll, imports symbol s3 from
d.dll.
On Wednesday, 13 May 2015 at 13:50:52 UTC, Logan Capaldo wrote:
I _think_ if you only do this for D-mangled symbols you'll get
99% of the benefits (doing the right things for templates etc.)
without causing problems for the corner cases.
Yes, that's the plan. I might even do it only for D
On Wednesday, 13 May 2015 at 12:54:52 UTC, Timon Gehr wrote:
This will accept the same arguments as Base. Only one
in-contract in the inheritance chain must pass in order for the
call to go through.
But wasn't exactly that the problem about the current
implementation? Shouldn't all 'in'
On Tuesday, 12 May 2015 at 17:48:50 UTC, Logan Capaldo wrote:
q could be a completely different type in a.dll vs. c.dll.
Please correct me if I am wrong, but my understanding of how
import libs get used you can't detect this at build time and
disallow it. Linking d.exe we have no reason to
On Wednesday, 13 May 2015 at 03:38:33 UTC, Maxime
Chevalier-Boisvert wrote:
I was wondering if anyone has written D code to access the x86
performance counters, to get information such as the number of
cache misses and cycle count.
I considered doing that at one point. So I looked for
On Wednesday, 13 May 2015 at 07:41:27 UTC, Logan Capaldo wrote:
If my program only links against DLLs written in D, sure this
is no worse than the static library/version flag situation. But
one of D's features is C and C++ interop. For instance if I
link against a DLL that happens to provide
On Sunday, 10 May 2015 at 21:44:59 UTC, Dicebot wrote:
Well choice between two presented options seems obvious so I
suspect a catch :)
Well, exactly like with the shared library visibility the only
catch might be Walter's and Andrei's opinion.
Why did Microsoft go with that approach,
Maybe they didn't know better back then. Historically DLLs
initially didn't support data symbols at all, only functions
where supported. For functions its not a problem if they are
duplicated because usually you don't compare pointers to
functions a
On Monday, 11 May 2015 at 14:57:46 UTC, Marco Leise wrote:
Is that what would happen?
Yes, that's exactly what would happen. You could go one step
further and not do it for all symbols, instead you make the
compiler emit a additional section with references to all
relevant data symbols.
Am 11.05.2015 um 16:21 schrieb Martin Nowak:
Can you elaborate a bit on that?
How would you run into such an ODR violation, by linking against
multiple import libraries that contain the same symbol?
I will post some code examples later. Code usually shows the issue best.
Last time we
Am 11.05.2015 um 21:39 schrieb Laeeth Isharc:
On Monday, 11 May 2015 at 12:54:09 UTC, Benjamin Thaut wrote:
and why does it not map well to D ?
D uses tons of templates everywhere. Even type information for non
templated types is generated on demand and stored in comdats which can
lead to
Am 10.05.2015 um 21:51 schrieb Dicebot:
On Friday, 8 May 2015 at 05:26:01 UTC, Benjamin Thaut wrote:
Pro:
- Its the plain windows shared library mechanism in all its uglyness.
I wonder if anyone can provide more Pro input :)
I described both implementations of shared libaries. From the
Does nobody have a opinion on this?
On Friday, 8 May 2015 at 08:04:20 UTC, Kagamin wrote:
As I understand, if SomeClass is in some dll, it will be there
and be unique. If typeid(SomeClass) loads the symbol address
from IAT, it will be the same address as in dll.
No, you don't understand. TypeInfos are stored in comdats. And
Am 08.05.2015 um 13:34 schrieb Kagamin:
bool checkIfSomeClass(Object o)
{
return typeid(o) is typeid(SomeClass);
}
Doesn't typeid(o) extract TypeInfo from the object? If it's stored as a
physical value in the object, how can it change transparently for const
class?
As I understand, C++
To implement shared libraries on a operating system level
generally two steps have to be taken
1) Locate which shared library provides a required symbol
2) Load that library and retrieve the final address of the symbol
Linux does both of those steps at program start up time. As a
result all
On Wednesday, 29 April 2015 at 19:04:11 UTC, extrawurst wrote:
On Wednesday, 29 April 2015 at 13:55:46 UTC, Benjamin Thaut
wrote:
On Monday, 27 April 2015 at 21:19:02 UTC, extrawurst wrote:
here is the shortened version of the returned class CSteamID:
On Monday, 27 April 2015 at 21:19:02 UTC, extrawurst wrote:
here is the shortened version of the returned class CSteamID:
https://gist.github.com/Extrawurst/936f56ceaa87cf287257
this is the shortened interface (no destructors in the rest of
the code either):
On Monday, 27 April 2015 at 13:08:33 UTC, extrawurst wrote:
Don't ask me about the compiler, like stated above I have no
control over the binaries, it is proprietary.
Thats bad to start with.
the C++ class basically is:
```
class S
{
union SteamID_t
{
struct
On Monday, 27 April 2015 at 11:00:23 UTC, extrawurst wrote:
Thought about that too and tried uint aswell. does not work
either..
Please post the c++ declarations as well. Which c++ compiler do
you use for win32? (dmc or msvc)
Kind Regards
Benjamin
Am 27.04.2015 um 17:16 schrieb extrawurst:
On Monday, 27 April 2015 at 13:14:21 UTC, Benjamin Thaut wrote:
On Monday, 27 April 2015 at 13:08:33 UTC, extrawurst wrote:
Don't ask me about the compiler, like stated above I have no control
over the binaries, it is proprietary.
Thats bad to
- what are potential factors that might make D a bad choice in this
scenario? I would like to use D certainly - but it is of course much
more important that the client gets the best result, however it is done.
You would have to asess if the analysis you should create is time
critical. If
On Monday, 6 April 2015 at 02:11:08 UTC, Daniel Murphy wrote:
Yes, exactly. If I get my way, the conversion tool will be put
into the dmd repository for a while, and it should be possible
to automatically upgrade a pull request with
rebase+convert+rebase. This method will be properly
Am 03.04.2015 00:44, schrieb Andrei Alexandrescu:
switching to ddmd, hopefully with 2.068.
Andrei
That sounds nice, I just hope that there is going to be some nice
migration path for people currently working on Pull-Requests for the C++
Version of dmd. I would prefer to not redo all the
On Sunday, 5 April 2015 at 18:30:16 UTC, Andrei Alexandrescu
wrote:
On 4/5/15 10:32 AM, Benjamin Thaut wrote:
Am 03.04.2015 00:44, schrieb Andrei Alexandrescu:
switching to ddmd, hopefully with 2.068.
Andrei
That sounds nice, I just hope that there is going to be some
nice
migration path
Am 22.03.2015 um 04:40 schrieb Martin Nowak:
Why would export make private functions public?
Following problem:
// public template
void foo(T)(T arg)
{
bar(T.sizeof);
}
// private implementation helper
private void bar(size_t size) { ... }
Because bar is used from foo, bar has to be
On Wednesday, 18 March 2015 at 18:48:53 UTC, Walter Bright wrote:
I'm fed up with this problem. It is actively hurting us every
day.
https://issues.dlang.org/show_bug.cgi?id=14307
Anyone want to take this on? Shouldn't be particularly
difficult.
This is going to be a lot of fun as soon as
On Thursday, 19 March 2015 at 12:58:42 UTC, Robert M. Münch wrote:
On 2015-03-18 21:50:39 +, Adam D. Ruppe said:
It will not work because a function with an auto return value
is actually a template, and unused templates won't be put into
a dll.
Ok, that makes it clear. Thanks.
On Thursday, 19 March 2015 at 11:47:37 UTC, Namal wrote:
On Wednesday, 18 March 2015 at 15:52:33 UTC, Benjamin Thaut
wrote:
On Wednesday, 18 March 2015 at 14:50:21 UTC, Namal wrote:
Can you help me show how to compile and link it together
please, thank you.
What platform are you on,
On Wednesday, 18 March 2015 at 14:17:13 UTC, Namal wrote:
Hello, as in the title. How can I call D functions from C++ (If
my main() is in a c++ file).
Thanks alot!
D:
extern(C++) void SomeDFunction()
{
doSomething();
}
C++:
void SomeDFunction();
void main()
{
SomeDFunction();
}
On Wednesday, 18 March 2015 at 14:50:21 UTC, Namal wrote:
Can you help me show how to compile and link it together
please, thank you.
What platform are you on, windows, linux, osx? What c++ compiler
do you use? msvc, clang, gcc?
On Wednesday, 18 March 2015 at 14:40:48 UTC, krzaq wrote:
I'm pretty sure the OP wanted to call D functions from C++, not
C++ functions from D.
If you look very closely you will notice that my example does
exactly what the OP wanted.
On Monday, 9 March 2015 at 14:39:34 UTC, Carl Sturtivant wrote:
Please confirm or deny that this is a real bug, as its getting
in the way of a genuine project. How should I proceed?
I'm working on a 64-bit Windows port of the following.
http://www.cs.arizona.edu/icon/
Here's the 32-bit Windows
On Friday, 6 March 2015 at 15:36:47 UTC, anon wrote:
Hi,
I can't figure this out.
struct Pair(T)
{
T x;
T y;
alias x c;
alias y r;
}
What would like is that the x and y to be initialized to
different values depending on type eg:
struct Container
{
Pair!double sample1; //
Am 05.03.2015 um 21:00 schrieb Taylor Hillegeist:
How to I cast a Int to float without changing its binary representation?
int someValue = 5;
float sameBinary = *(cast(float*)cast(void*)someValue);
On Thursday, 5 March 2015 at 07:28:12 UTC, Jacob Carlborg wrote:
On 2015-03-03 18:49, Benjamin Thaut wrote:
Sounds like you want to test an application that uses Phobos as
a DLL. To me that sounds like a more higher level test than a
unit test, i.e. integration tests. I would put those tests
On Thursday, 5 March 2015 at 03:24:05 UTC, TheFlyingFiddle wrote:
Finding out if a unittest only accesses public symbols could be
done by analyzing the ast of the method. Either inside the
compiler of via one of the third party D parsers currently in
use.
I thought about writing a tool
On Thursday, 5 March 2015 at 07:42:10 UTC, Jacob Carlborg wrote:
On 2015-03-05 08:38, Benjamin Thaut wrote:
I don't want to write new tests. I want to use the tests for
phobos
which are already there. And I want to use them in a way, that
if new
tests are added to phobos they are also tested
I'm currently in the process of annotating all of phobos with export
and its quite cumbersome. To verify that I annoted all relevant
functions and types with export I would like to run the unitests against
the shared version of phobos. There is a problem with this though. The
unittests are
Am 27.02.2015 um 00:05 schrieb deadalnix:
Note that in D, you have union and all kind of crap like that, so what
is writing a pointer is non obvious and so the tradeof is very different
than it is in other languages.
To have any chance of implementing a better GC in D I would simly start
of
Am 26.02.2015 um 20:58 schrieb Walter Bright:
It was a generational gc, I described earlier how it used page faults
instead of write barriers. I eventually removed the page fault system
because it was faster without it.
Page faults are inferrior to compiler generated write barriers. Because
Am 26.02.2015 um 21:39 schrieb Walter Bright:
On 2/25/2015 1:27 PM, Benjamin Thaut wrote:
You seeing this completely one sided. Even if write barries make code
slower by
10% its a non issue if the GC collections get faster by 10% as well.
Then in
average the program will run at the same speed.
Am 24.02.2015 um 10:53 schrieb Walter Bright:
On 2/24/2015 1:30 AM, Tobias Pankrath wrote:
Are the meaningful performance comparisons
between the two pointer types that would enable us to estimate
how costly emitting those barriers in D would be?
Even 10% makes it a no-go. Even 1%.
D has to
Am 26.02.2015 um 05:08 schrieb Walter Bright:
On 2/25/2015 7:27 PM, deadalnix wrote:
On Thursday, 26 February 2015 at 02:48:15 UTC, Walter Bright wrote:
Writing a generational collector for D is possible right now with no
language
changes, it's just that nobody has bothered to do it. Don't
Am 21.02.2015 um 15:02 schrieb Daniel Murphy:
https://auto-tester.puremagic.com/?projectid=10
This is a pretty big milestone for the project. For the first time, an
unpatched dmd can build ddmd, and that ddmd can build druntime and
phobos and pass all the test suites.
Hopefully in the next
Am 22.02.2015 um 10:48 schrieb Russel Winder via Digitalmars-d:
On Sun, 2015-02-22 at 10:21 +0100, Benjamin Thaut via Digitalmars-d
wrote:
Am 22.02.2015 um 03:13 schrieb Walter Bright:
Nobody thinks GC is suitable for hard realtime.
I think you should know manu good enough by now that you
Am 22.02.2015 um 03:13 schrieb Walter Bright:
Nobody thinks GC is suitable for hard realtime.
I think you should know manu good enough by now that you know he is not
talking about hard realtime but soft realtime instead. (e.g. games)
There are GCs which handle this situation pretty well but
Am 21.02.2015 um 11:30 schrieb Marc =?UTF-8?B?U2Now7x0eiI=?=
schue...@gmx.net:
For C++, you can just use the newly added namespace support:
extern(C++, nobody.uses.this.name) myFunc() {}
Thats actually a good idea. Thanks.
On Thursday, 19 February 2015 at 21:34:57 UTC, John Colvin wrote:
I would duplicate the declaration, once without extern(C++),
once with, the use the .mangleof from the 1st to set the mangle
of the 2nd with pragma(mangle
Yes that would work. But using pragma(mangle) feels so hacky...
On Friday, 20 February 2015 at 13:00:39 UTC, John Colvin wrote:
I agree. Wrap it in a mixin / mixin template?
Why do you need this? Presumably it'll be hidden in the depths
of some library / bindings where beauty is somewhat optional?
Using the .mangleof from an extern(D) function should
Is it possible to declare a function in D which gets the C++ calling
convetion but not the C++ mangling?
Kind Regards
Benjamin Thaut
Am 17.02.2015 um 09:13 schrieb Walter Bright:
On 2/16/2015 10:54 PM, Benjamin Thaut wrote:
Am 17.02.2015 um 02:21 schrieb Daniel Murphy:
struct X(T) { pragma(msg, X.stringof); }
void main()
{
X!(typeof(*(void function()).init)) x;
}
Error: ICE: Unsupported type void()
So close...
So i looked at the Dll Test within the dmd test framework and when I
make export an attribute, like I suggested, this perticular test will
compile run without any code changes. This is another reason why I
suspect that making export an attribute will only break very little if
any code at all.
On Tuesday, 17 February 2015 at 08:16:37 UTC, Walter Bright wrote:
True, it might be easier to adjust the C++ side so it takes a
pointer to a function type.
In this case it would be really ugly
ezDelegatevoid() vs ezDelegatevoid(*)()
I will do a pull request later today fixing this
On Tuesday, 17 February 2015 at 11:39:06 UTC, Guillaume Chatelet
wrote:
We'll also have to provide a new pragma to allow correct
mangling of types on Windows. Maybe something like :
extern(C++, std) {
pragma(mangleAs, class)
struct basic_string()
{
...
}
}
Yes please. I'm running into the
Am 16.02.2015 um 18:55 schrieb Jonathan Marler:
Why is the 'in' operator nogc but the index operator is not?
void main() @nogc
{
int[int] a;
auto v = 0 in a; // OK
auto w = a[0]; // Error: indexing an associative
// array in @nogc function main may
I have a c++ struct:
template typename retval
struct ezDelegateretval ()
{
}
void DelegateTest(ezDelegatevoid () func) { ... }
And I want to match that on the D side, unfortunately it does not work:
D:
struct ezDelegate(Signature) {}
alias delegate_t = ezDelegate!(void function());
Am 17.02.2015 um 02:21 schrieb Daniel Murphy:
struct X(T) { pragma(msg, X.stringof); }
void main()
{
X!(typeof(*(void function()).init)) x;
}
Error: ICE: Unsupported type void()
So close...
Hi,
you can also take a look at my implementation:
https://github.com/Ingrater/druntime/blob/master/src/core/allocator.d
Look at AllocatorNew and AllocatorDelete
Especially important is, that you correctly handle the
constructor throwing an exception. You have to catch that
exception in
On Monday, 16 February 2015 at 08:08:17 UTC, Walter Bright wrote:
At this point I suggest simply making those private helper
functions public and export them. It gets your project moving
without waiting for language changes (and this is a breaking
change).
This is in fact not a breaking
On Monday, 16 February 2015 at 09:59:07 UTC, Walter Bright wrote:
--
Here is a list of all things wrong with export:
32 64 bit issues:
1) Exporting a global variable leads to a linker error
2) Exporting thread local variables should be an error (at
least it is in c++)
3) The module
Am 13.02.2015 um 19:40 schrieb Daniel Murphy:
Benjamin Thaut wrote in message
news:mzgymsfzrxbvffgcf...@forum.dlang.org...
There are currently two problems with binding c++ value types and c++
value type templates.
1. Semantics are somewhat different. Copying / constructor /
destructing /
Am 15.02.2015 um 13:59 schrieb Daniel Murphy:
Benjamin Thaut wrote in message news:mbq03u$2h5v$1...@digitalmars.com...
Well, it doesn't work for anything that is within an C++ namespace.
If I remove the Test namespace everything works as expected.
I think what you want is something along
Am 15.02.2015 um 17:25 schrieb Andrei Alexandrescu:
On 2/15/15 5:33 AM, Benjamin Thaut wrote:
Maybe this should be documented on the Interfacing to C++ page.
Pull request pliz pliz -- Andrei
Honestly, I'm currentyl preparing a really huge pull request for D (Dll
support for windows) and
There are currently two problems with binding c++ value types and
c++ value type templates.
1. Semantics are somewhat different. Copying / constructor /
destructing / operator overloading is a issue.
2. Only templates which are instantiated on the c++ side can be
used.
Now it would be nice
On Thursday, 12 February 2015 at 12:59:39 UTC, Steven
Schveighoffer wrote:
I think given the necessity of the above (which was not
discussed or noticed in that bug report), we should add a way
to call the true destructor properly in the compiler.
-Steve
Yes please. Its also going to
When binding C++ value types you might want to use them by placing them
on the D-Stack. This however seems to be not supported as the mangling
for the constructor is completely wrong. Is this supposed to work?
Kind Regards
Benjamin Thaut
Am 01.02.2015 um 11:26 schrieb Vladimir Panteleev:
The Delphi programming language allows specifying the DLL name right on
the declaration of extern symbols:
function GetVersion: DWORD; stdcall; external 'kernel32.dll';
I would like to suggest adding something similar to D:
extern(Windows,
Am 31.01.2015 um 23:42 schrieb deadalnix:
On Wednesday, 28 January 2015 at 13:48:45 UTC, Dicebot wrote:
Isn't that what your first proposed solution is about? That was my
understanding and I liked that understanding :) To be 100% clear :
export void foo(T : int)(T x)
{
bar(x);
}
private
And lets just say it is required to link against druntime correctly. I
don't want to give you a 4 page text explanation why.
So you expect us to just trust you, then?
No, you just need to wait like everyone else until I do the PR for dmd /
druntime / phobos for a full explanation. If you
Am 01.02.2015 um 14:27 schrieb Vladimir Panteleev:
On Sunday, 1 February 2015 at 12:09:56 UTC, Benjamin Thaut wrote:
http://wiki.dlang.org/DIP45
OK, so I understand it's mostly about D DLLs.
Yes of course. Because they are still not supported.
This bit though:
In an import library the
Am 01.02.2015 um 11:45 schrieb Vladimir Panteleev:
On Sunday, 1 February 2015 at 10:40:06 UTC, Benjamin Thaut wrote:
Please no. Import libraries are the way it was designed
Delphi does without them just fine.
C++ does with them just fine.
I'm currently implementing D-Dll support for
Am 01.02.2015 um 13:02 schrieb Vladimir Panteleev:
But I haven't heard of this project before. In a few words, what does
this do? Or a link to a DIP or existing discussion?
The last discussion is over a year old, the resulting DIP was DIP 45:
http://wiki.dlang.org/DIP45
The currently
Am 01.02.2015 um 17:15 schrieb ketmar:
On Sun, 01 Feb 2015 16:07:58 +, John Chapman wrote:
On Sunday, 1 February 2015 at 08:37:23 UTC, ketmar wrote:
seems that my idea of using D to write a simple windows utility was
very wrong. ok, another attempt to use D for our windows developement
Am 31.01.2015 um 06:11 schrieb Dicebot:
On Friday, 30 January 2015 at 19:10:06 UTC, Martin Nowak wrote:
It has a serious drawback of increasing attribute noise even more
though. First approach allows for more automatic inference.
But with D restrictions it seems the least bad option.
Well,
Am 31.01.2015 um 13:07 schrieb Martin Nowak:
That's probably how it should behave, though an attribute applying only
to public members unless explicitly added is unprecedented. Still seems
like the right choice here, but might require some additional compiler
logic.
Well you don't have to
Am 30.01.2015 um 11:39 schrieb Martin Nowak:
If you mean float, then it
will instatiate the template when compiled individually and use b's
instantiation when b and c are compiled together.
If this is true, then please explain this behavior:
module a; // -- a.dll
struct Storage(T)
{
T
On Thursday, 29 January 2015 at 10:21:25 UTC, Walter Bright wrote:
On 1/28/2015 5:19 AM, Benjamin Thaut wrote:
On Wednesday, 28 January 2015 at 11:01:09 UTC, Walter Bright
wrote:
The example had marked the template itself as 'export'. This
raises the
specter of which binary the template
On Thursday, 29 January 2015 at 11:50:29 UTC, FG wrote:
@property auto info() @safe @nothrow @pure @return const {
return this; }
It is mesmerizing... (@ _ @)
And soon its gong to look like this:
export @property auto info() @safe @nothrow @pure @return const {
return this; }
Why don't you simply store references to the TraceInfo objects
until you want to print them?
On Wednesday, 28 January 2015 at 11:01:09 UTC, Walter Bright
wrote:
The example had marked the template itself as 'export'. This
raises the specter of which binary the template instantiation
exists in.
Also sorry for the harsh answer, this was a classical double
misunderstanding.
On Wednesday, 28 January 2015 at 11:01:09 UTC, Walter Bright
wrote:
The example had marked the template itself as 'export'. This
raises the specter of which binary the template instantiation
exists in.
The export in this context actually means export all
instanciations of this template.
On Wednesday, 28 January 2015 at 11:42:19 UTC, Dicebot wrote:
2) first proposed solution does not allow to mark private
functions as export. It implicitly exports those if they are
needed for actual public/export template function to work. This
is not the same - those functions still can't
On Wednesday, 28 January 2015 at 13:48:45 UTC, Dicebot wrote:
Isn't that what your first proposed solution is about? That was
my understanding and I liked that understanding :) To be 100%
clear :
export void foo(T : int)(T x)
{
bar(x);
}
private void bar(int x) { }
I'd expect `bar` to
On Tuesday, 27 January 2015 at 22:29:41 UTC, Rainer Schuetze
wrote:
I would not mind if we export all symbols on Windows aswell. It
doesn't seem to bother a lot of people for the linux version,
even though it's unsafer and slower than on Windows (at least
that was my experience more than 10
On Wednesday, 28 January 2015 at 16:18:18 UTC, Andrei
Alexandrescu wrote:
We have a really nice script:
https://github.com/D-Programming-Language/tools/blob/master/update.sh
And once again this only works for linux...
DMDs test framework is also a hell to use on Windows. It takes 5
times as
On Wednesday, 28 January 2015 at 14:45:04 UTC, david wrote:
BTW: The code of the 'ctor generates the calltrace - so it's
not lazy!
No, getting the pointers of the stack trace is not lazy.
Translating them into a string via debug symbols is lazy. Btw
what platform are you on?
On Wednesday, 28 January 2015 at 14:31:54 UTC, Dicebot wrote:
Yes, I see the problem now. static if isn't even the worst
offender, any kind of string mixins that generate the call to
`bar` are impossible to detect without having actual `foo`
instance. Sorry for misinterpretation.
With
101 - 200 of 253 matches
Mail list logo
