I noticed the calling classinfo on an interface returns the class info
of the static type and not the dynamic type. Is that intentional?
Perhaps because of COM and C++ interfaces?
module main;
import std.stdio;
interface Foo {}
class Bar : Foo {}
void main()
{
Foo f = new Bar;
Is there any way to input such a literal? Both `...` and qEOS...EOS do not
allow escape sequences. I'm on Linux, but I need precisely CRLF, not just
\n.
--
Marek Janukowicz
On Tuesday, 25 August 2015 at 18:29:08 UTC, Vladimir Panteleev
wrote:
I think this is a bug, but is easily worked around with:
auto test(string a) {
return .test(a, b);
}
Thanks, this worked.
Filled it: https://issues.dlang.org/show_bug.cgi?id=14965
On 08/25/2015 08:29 PM, Vladimir Panteleev wrote:
I think this is a bug, but is easily worked around with:
auto test(string a) {
return .test(a, b);
}
I suspect that the reason the error occurs, is that the auto return type
automatically rewrites the function declaration into an
On 08/26/2015 11:59 AM, Adam D. Ruppe wrote:
On Wednesday, 26 August 2015 at 18:53:19 UTC, Jacob Carlborg wrote:
Is that intentional? Perhaps because of COM and C++ interfaces?
Yes, exactly. COM and C++ things won't necessarily have a D TypeInfo
available and since interfaces can be them, it
On 08/26/2015 09:55 PM, Timon Gehr wrote:
On 08/25/2015 08:29 PM, Vladimir Panteleev wrote:
I think this is a bug, but is easily worked around with:
auto test(string a) {
return .test(a, b);
}
I suspect that the reason the error occurs, is that the auto return type
automatically
anonymous wrote:
Is there any way to input such a literal? Both `...` and qEOS...EOS do
not allow escape sequences. I'm on Linux, but I need precisely CRLF, not
just \n.
I'm probably missing the point, but:
Hello\r\nworld
Or if you want to include the \n verbatim:
Hello\r
world
On Wednesday, 26 August 2015 at 18:53:19 UTC, Jacob Carlborg
wrote:
Is that intentional? Perhaps because of COM and C++ interfaces?
Yes, exactly. COM and C++ things won't necessarily have a D
TypeInfo available and since interfaces can be them, it can't be
sure.
What I do there is to just
On Wednesday, 26 August 2015 at 18:28:02 UTC, Marek Janukowicz
wrote:
Is there any way to input such a literal? Both `...` and
qEOS...EOS do not allow escape sequences. I'm on Linux, but I
need precisely CRLF, not just \n.
One way you could do it is to stick a .replace(\n, \r\n) to
the end
On Wednesday 26 August 2015 20:28, Marek Janukowicz wrote:
Is there any way to input such a literal? Both `...` and qEOS...EOS do
not allow escape sequences. I'm on Linux, but I need precisely CRLF, not
just \n.
I'm probably missing the point, but:
Hello\r\nworld
Or if you want to include
Hi, all.
I have a question.
When 'testdic' file does' t exist, something wrong.
---
import std.mmFile;
int main() {
auto x = new MmFile(testdic,MmFile.Mode.readWrite,0,null);
return 0;
}
---
OSX 10.10.3 ,
DMD64 D Compiler v2.069-devel-d0327d9
After testdic file (size=0) was made,
On 08/26/15 14:42, Mike Parker via Digitalmars-d-learn wrote:
This doesn't help me distinguish aliased function names.
[...]
I don't want to put any restrictions on what the user can have in the
module/class/struct that contains the function pointer. It's just that
aliased function names
On Wednesday, 26 August 2015 at 15:49:23 UTC, Junichi Nakata
wrote:
Hi, all.
I have a question.
When 'testdic' file does' t exist, something wrong.
---
import std.mmFile;
int main() {
auto x = new MmFile(testdic,MmFile.Mode.readWrite,0,null);
return 0;
}
---
OSX 10.10.3 ,
DMD64 D
Thanks for the thorough response. I'm aware of some of what you
explained. Maybe I should have asked differently. Rather than asking
what RAII facilities do exist, I guess I was looking for the answer,
Here's what you typically do in C++ RAII that you can't do in D. I
could probably find out
Thanks. I had not looked at some of those yet.
Jim
Thanks for all the info. It's a good comparison of structs and classes
to keep handy. Actually, I'm fine with the GC. I don't mean to avoid it.
I just would like some way to also have non-memory resources
automatically released in a timely, predictable way.
One common thing to do in C++ is to
On Wednesday, 26 August 2015 at 14:29:30 UTC, Andrea Fontana
wrote:
__traits(setAttributes, ...)
It would be useful, for example, if I have a list of functions
to mark. Let's say
enum toExport = [oldFunction, thisToo];
foreach(d; toExport) __traits(setAttributes, ...);
Lots of
On Wednesday, 26 August 2015 at 17:30:29 UTC, Alex Parrill wrote:
On Wednesday, 26 August 2015 at 15:49:23 UTC, Junichi Nakata
wrote:
Hi, all.
I have a question.
When 'testdic' file does' t exist, something wrong.
---
import std.mmFile;
int main() {
auto x = new
On Wed, 26 Aug 2015 08:27:05 +, FreeSlave wrote:
Are there ways to fix this? Should I consider writing my own range type
probably?
Check http://dlang.org/phobos/std_algorithm_iteration.html#.cache
On Wednesday, 26 August 2015 at 08:30:04 UTC, Yazan D wrote:
On Wed, 26 Aug 2015 08:27:05 +, FreeSlave wrote:
Are there ways to fix this? Should I consider writing my own
range type probably?
Check
http://dlang.org/phobos/std_algorithm_iteration.html#.cache
I tried it. It can help
I wonder if there's a way to add UDA to functions at compile-time
(so I can read later from other parts of application).
Andrea
On 08/26/2015 01:27 AM, FreeSlave wrote:
I would want to avoid redundant front evaluations.
Another option is std.functional.memoize:
import std.stdio;
import std.functional;
import std.algorithm;
import std.array;
void main()
{
auto r = [ 1, 2, 1 ]
Example:
import std.stdio;
import std.algorithm;
import std.path;
import std.file;
import std.exception;
import std.getopt;
import std.array;
import std.range;
auto algo(string fileName, string[] dirs, string[] extensions)
{
return dirs.filter!(delegate(dir) {
bool ok;
This would be undefined behavior in c++ due to aliasing rules on
pointers. It appears to work reliably in D when I try it, but
that's obviously no guarantee that it's correct or will continue
to do so.
Is this correct code in D? And if not, what should I do instead
to cleanly and efficiently
On Tuesday, 25 August 2015 at 12:06:08 UTC, Mike Parker wrote:
Is there a way to determine whether a given symbol is an alias?
Consider this:
```
module funcs;
alias FuncPtr = void function();
@ChooseMe FuncPtr funcPtr;
alias anotherName = funcPtr;
```
Handing this module off to
On Tuesday, 25 August 2015 at 16:08:48 UTC, Rikki Cattermole
wrote:
\ While my memory especially at 4am is rusty here:
enum isVarDecl = __traits(compiles, {mixin(GOT ~ got;);});
Where GOT is assumed to be the string that you got from
__traits(allMembers.
It'll be true that it is a variable
On Wednesday, 26 August 2015 at 11:20:40 UTC, Meta wrote:
I've been doing work on this recently. As far as I can tell,
there is no way to do this. The problem is that an alias
behaves exactly like the thing being aliased since it's just a
name replacement, so there are no giveaways like being
On Wednesday, 26 August 2015 at 14:01:00 UTC, Alex Parrill wrote:
On Wednesday, 26 August 2015 at 08:19:04 UTC, Andrea Fontana
wrote:
I wonder if there's a way to add UDA to functions at
compile-time (so I can read later from other parts of
application).
Andrea
What do you mean? UDAs are
On Wednesday, 26 August 2015 at 08:19:04 UTC, Andrea Fontana
wrote:
I wonder if there's a way to add UDA to functions at
compile-time (so I can read later from other parts of
application).
Andrea
What do you mean? UDAs are already specified at compile time.
@(hello)
void
A serious bug affecting RAII is
https://issues.dlang.org/show_bug.cgi?id=14903, but apparently
its importance hasn't been properly acknowledged yet. Improving
the performance of binaries produced by dmd's backend is
obviously way more important than fixing serious bugs or
commenting on
On Wednesday 26 August 2015 14:14, John Burton wrote:
This would be undefined behavior in c++ due to aliasing rules on
pointers. It appears to work reliably in D when I try it, but
that's obviously no guarantee that it's correct or will continue
to do so.
Is this correct code in D? And if
On Wednesday, 26 August 2015 at 20:02:35 UTC, Timon Gehr wrote:
Another workaround is to order the declarations in the opposite
way:
import std.stdio;
import std.range : chain;
auto test(string a,string b) {
return chain(a,b);
}
auto test(string a) {
return test(a,b);
}
void main() {
On Thursday, 27 August 2015 at 02:50:58 UTC, BBasile wrote:
So the Q: Is this difference normal ?
Yes, it is a feature the Windows format supports but the Linux
one doesn't. On Linux, you need to list the libraries on the
command line again.
On Thursday, 27 August 2015 at 03:17:57 UTC, BBasile wrote:
On Thursday, 27 August 2015 at 02:50:58 UTC, BBasile wrote:
So the Q: Is this difference normal ?
the win OMF linux COFF thing maybe ?
If I understand your problem description correctly, the culprit
is likely the order in which
On Thursday, 27 August 2015 at 02:50:58 UTC, BBasile wrote:
So the Q: Is this difference normal ?
the win OMF linux COFF thing maybe ?
On Wednesday, 26 August 2015 at 22:07:01 UTC, rsw0x wrote:
On Wednesday, 26 August 2015 at 17:30:29 UTC, Alex Parrill
wrote:
On Wednesday, 26 August 2015 at 15:49:23 UTC, Junichi Nakata
wrote:
Hi, all.
I have a question.
When 'testdic' file does' t exist, something wrong.
---
import
let's say i have 'libA', 'libB' and 'Project'
- libB uses libA
- Project uses libB
under Windows (32 bit, OMF objects, Digital Mars linker, so the
standard setup):
-
* libA is compiled with: dmd sourceA.d -lib
* libB is compiled with: dmd sourceB.d -lib -IpathToSourceA
* Project
37 matches
Mail list logo
