Re: D game engine -- Any suggestions?
Feel free to take a look at https://github.com/hpohl/ext/. Maybe you can find something useful.
Re: Qt Creator and D
On Wednesday, 18 September 2013 at 14:49:27 UTC, Joseph Rushton Wakeling wrote: Hello all, Several of us have been talking about Qt Creator and D in various subthreads of the current IDE-related discussions going on right now, so I thought it might be worth raising as a matter of general interest. My general impression is that this is a fast, light cross-platform IDE which is (as its name indicates) state-of-the-art for C++ and Qt development. Currently it has fairly good D/Ddoc syntax highlighting (it literally copies the latest d.xml syntax definition file from KDE's text editor Kate). However, I wasn't able to get things like auto-indent working, and haven't yet put any serious effort into investigating build/compiler or debugging support. It also has a FakeVim mode that enables vim-like editing and should be able to operate from the local .vimrc settings, but my brief experiments weren't so far able to get it to reproduce my current vim behaviour. The last related discussion that I'm aware of is from about 3 years back, when several D users discussed implementing Qt Creator support: http://www.digitalmars.com/d/archives/digitalmars/D/ide/Qt_Creator_with_D_707.html ... but I'm not aware of any follow-up since then. I'm just wondering how many people would be interested in seeing better D support in this IDE, and how many people have more experience or can offer insight into how to proceed. Best wishes, -- Joe It's the best IDE for C++ development I have encountered so far. And it's the only drawback of DMD making the change to D: I cannot use it to fix bugs anymore.
Re: [:] as empty associative array literal, plus warning for null
On Thursday, 4 July 2013 at 00:52:13 UTC, Timon Gehr wrote: Also, I think [] should have a singleton type as well. Currently it is a void[] with special implicit conversion rules. +1
Where should the destruction of aggregate members take place?
a) In the so-called whole dtor which calls the dtors of all
members including the dtor declared (if any). The attributes of
the whole dtor are deduced.
b) Everything takes place in the dtor declared (if any). If the
dtor is pure/nothrow/safe, it is guaranteed that the object can
be destructed purely/without throwing/safely. This will break
existing code.
-
struct S { ~this() { } }
struct SX { S s; pure ~this() { } }
-
a) Compiles.
b) Error: S.s.~this is impure
Both behaviors are available on github:
a) https://github.com/D-Programming-Language/dmd/pull/2006
b) https://github.com/D-Programming-Language/dmd/pull/2003
You can apply this to postblit, too.
dlang.org frontpage example shows incorrect results
According to the example on the frontpage the default input: The D programming language. Modern convenience. Modeling power. Native efficiency. Has an average line length of 1.
private/package methods cannot be virtual
Documentation: Member functions which are private or package are never virtual, and hence cannot be overridden. I was about to write a bug report about this, because in my code there are tons of overridden methods which actually should be private/package. Can anyone tell me why this decision has been made? To inline them? Do I really need to write interfaces to be able to override these methods?
Re: trusted purity?
I've been working on a pull request and came up with something
like this:
private void initialize(A...)(auto ref A args)
{
auto m = cast(void* function(size_t size) pure)malloc;
_store = cast(Impl*) enforce(m(Impl.sizeof));
auto r = cast(void function(in void* p, size_t sz) nothrow
pure)GC.addRange;
static if (hasIndirections!T)
r(_store._payload, T.sizeof);
emplace(_store._payload, args);
_store._count = 1;
}
The purity of emplace depends on the purity of the ctor called.
I'm not sure how to fix that.
Re: trusted purity?
By the way, my post is related to the impurity of RefCounted: http://d.puremagic.com/issues/show_bug.cgi?id=9998
Re: trusted purity?
On Monday, 29 April 2013 at 11:32:33 UTC, monarch_dodra wrote: I'm still worried about what it means for a pure function to throw... (I'm thinking about the enforce(malloc) scheme) If malloc returns null, we are out of memory. In D this is not an exception, it is an error. So I guess we just need to check the pointer returned by malloc and throw an OutOfMemoryError on failure. Thus if the ctor called is nothrow, it can be marked as nothrow, too. So in this case, there should be no problem making it pure.
Re: trusted purity?
On Monday, 29 April 2013 at 12:08:58 UTC, monarch_dodra wrote: I've hit this issue before: In D, if the *managed* memory runs out, then it is an error (since then *everything* crumbles: arrays, GC. etc). The reason it is an error is that since the memory is managed by the language, there is nothing the user can do anyway, so throwing is pointless. for unmanaged memory, on the otherhand, the user *can* do something about it, so throwing is better. I myself am not sure I 100% agree with this, but that was the conclusion last time I tried to transform an malloc=Exception into a malloc=Error+Nothrow What about using allocators the user can specify? The default one would be malloc + Error + nothrow. All the signatures of RefCounted have to change depending on the allocator's ones, though. This is where attribute inference is rather needed.
Re: Order of destruction when garbage collection kicks in
On Tuesday, 9 April 2013 at 20:46:12 UTC, Steven Schveighoffer
wrote:
No. You are not allowed to access any GC-managed resources
inside a destructor.
Okay, I finally found it:
http://dlang.org/class.html#destructors. But it's not listed
here: http://dlang.org/garbage.html.
And it won't be null, because that would be extremely costly.
Consider if 300 objects had a pointer to a block of memory.
Now those 300 objects all go away. By your expectation, if the
targeted block of memory was collected, the GC would have to
spend time going through all those 300 pointers, setting them
to null. When they are about to all be destroyed. 99.99% of
the time, that would be wasted, as those 300 objects may not
even have destructors that care.
I thought about the case when the user sets the reference to null
before the destructor was even called.
A destructor is ONLY for destroying non-GC managed resources,
nothing else. Like an OS file handle for instance.
Imagine this case:
// External C library.
extern(C) {
alias void* a_handle;
alias void* b_handle;
a_handle create_a();
void destroy_a(a_handle);
b_handle create_b(a_handle);
void destroy_b(b_handle);
}
class A {
this() {
// An a_handle owns multiple b_handles.
handle = create_a();
}
~this() {
// Destroys all bs connected with this a.
destroy_a(handle);
}
private a_handle handle;
}
class B {
this(A a) {
this.a = a;
// Creates a b_handle connected to the given a_handle.
handle = create_b(a.handle);
}
~this() {
// a already destroyed - segfault
// a still alive - works
destroy_b(handle);
}
private A a;
private b_handle handle;
}
Any instance of B always needs to be destructed _before_ the A
it's connected to. How do you express this in D?
Order of destruction when garbage collection kicks in
In fact there is no order of destruction. And this is one of the most annoying D problems I recently had to deal with. Look at this example: http://dpaste.dzfl.pl/f3f860b0. This time, it segfaulted. Next time it may (in theory) not, because the dtor of a is called before the one of b. A holds a reference to a B. In the destructor of A I expect b either to be null or a valid instance of B (which has not been destroyed yet). You get a kind of undefined behavior instead. This is IMO a huge drawback towards reference counting with strong/weak references. Is there right now any way to arrange things?
No subclass member loopup in derived class, bug?
struct S {
int value() {
return 1;
}
}
class Base {
S s;
alias s this;
}
class Derived : Base {
void func() {
int i = value();
}
}
Fails with main.d(14): Error: undefined identifier value.
Explicitly casting this to Base works:
void func() {
int i = (cast(Base)this).value();
}
Is this intended or a bug?
Re: object states
On Monday, 8 October 2012 at 08:53:39 UTC, simendsjo wrote:
You can create a wrapper struct that includes an invariant:
import std.stdio;
struct Image
{
int width;
void doSomething()
{
}
void modifiesWidth()
{
--width;
}
}
void func(Image img)
{
struct ImgWrapper
{
Image* img;
this(ref Image img)
{
this.img = img;
}
invariant()
{
assert(img.width == 512);
}
void opDispatch(string s)()
{
mixin(img.~s~(););
}
}
auto wrapper = ImgWrapper(img);
wrapper.doSomething();
wrapper.modifiesWidth(); // assertion failure
}
void main()
{
Image img = { 512 };
func(img);
}
There is a difference between invariants and what I call states.
States clear things up when you actually need to do a runtime
check and when not. Invariants are always checked, because you
don't care about performance in debug mode. A Numberpositive is
positive already and will stay positive while you can access it.
De facto you cannot change a Numberpositive to a negative
number.
object states
Imagine you want an image to keep the width of 512:
void func(Image img) {
assert(img.width == 512);
img.doSomething();
assert(img.width == 512);
while (img.somethingElse()) {
assert(img.width == 512)
someFunc(img);
assert(img.width == 512);
}
}
In theory, every call to a function can change the width of the
image. What do you think about this:
https://dl.dropbox.com/u/34762907/temp/prop1.html
I do know it can be implemented in D4 only.
Re: object states
On Sunday, 7 October 2012 at 20:18:15 UTC, Ali Çehreli wrote: Sounds good. Thanks. You haven't mentioned the invariant keyword, so perhaps you are not aware of that feature? http://dlang.org/class.html#Invariant http://dlang.org/dbc.html Although the docs seem to favor classes, invariant is available for structs as well. Ali How would you resolve the issue I wrote in my first post using invariants? You cannot add/remove checks from invariants while using the object. That's what I made different. But there are still some limits given by the language. Look at point 7 for instance. The problem about contract programming in general is you cannot use it in public library code. Distinction between logic and user input is a very important thing, we really need to improve this. You may have noticed that I did not make use of either assert or enforce. I didn't want to specify this.
Re: References in D
On Friday, 5 October 2012 at 13:57:13 UTC, bearophile wrote:
void foo1(C1 c1, C2 c2)
in {
assert(c1 !is null);
assert(c2 !is null);
} body {
...
}
And in public library code, you can't even use assert. You have
to throw an error/exception. Runtime checks guaranteed even in
release mode.
Re: References in D
On Wednesday, 3 October 2012 at 08:11:32 UTC, Franciszek Czekała wrote: Agreed. Nullable types are a feature not a bug. There is no need to change it. Bugs occur when you do not know the language rules and make assumptions instead. This can happen whith any language and any rules. As to an example use of nullable references: consider a board game (for example chess). The boards has cells which can be empty or occupied. Model this with an array of class objects representing pieces. null reference means a cell is not occupied. If you want to remove a piece from the board assign null to it and GC will take care of the rest. Now, doing this with full objects representing empty cells would require needless work to define such null objects and would be wasteful of memory (typically boards are sparsely populated). Now imagine a really big board and every cell holding references to useless objects simulating null references. It would not make sense. Saying that null references are evil is just propaganda. Let's keep D a sane language. There is a related question at stackoverflow: http://stackoverflow.com/questions/693325/non-nullable-reference-types As you can see the nullable references are great guy has been voted down. I've written like 5k lines of code in D and never felt the need of using null. C++'s std::shared_ptr has the same issue, but at least it is called pointer.
Re: References in D
On Wednesday, 3 October 2012 at 16:11:53 UTC, Franciszek Czekała wrote: As my comments indicated : the presence of a value does not guarantee a valid value by itself. The C++ declaration int n; introduces a value, good luck using it. auto c = new Class(); Tell me, does c contain an invalid value now? In short, having null references is useful (a value outside of the type cannot be introduced easily unless the language gives a hand, check eof() in C++ character_traits), Null references are useful, that's right. Nobody wants to take them away. Just put something like a questionmark behind the reference type to indicate that it's nullable. while forcing non-null references hardly offers any significant advantage. 1) Performance, no or very few null-checks. 2) Code is shorter, looks better, less duplications. 3) Clarity. User of functions know, whether a function can return null at compile time. Not enough to justify complicating the syntax of the language to have it both ways. Not really. It's all about one question mark for example.
Re: References in D
On Wednesday, 3 October 2012 at 16:58:52 UTC, Maxim Fomin wrote: How much code would be broken by moving nullable references from current state to question mark notation? That's another question :] I expect that non-nullable class objects (called references here) addition (if there is no objections to idea in general) would not break much code and would not request vast syntax changes. And it likely can be done by still defaulting to nullable references. For example, it can be done with the help of @nonnullable (like immutable) type qualifier and semantic check of operations involving references with such qualifier. Sounds like a deal for now, but @nonnullable will only work with class references and anything else will be an error. So directly attaching it to the type (like the questionmark) makes more sense. Anyway, my estimation of probability of accepting constructions like type, type*?, etc and defaulting to non-null references is very low, at least for D2. That's right, but let's use the youth of the language to change this. I guess many will hate me if we do so.
Re: References in D
On Wednesday, 3 October 2012 at 16:58:52 UTC, Maxim Fomin wrote: How much code would be broken by moving nullable references from current state to question mark notation? That's another question :] I expect that non-nullable class objects (called references here) addition (if there is no objections to idea in general) would not break much code and would not request vast syntax changes. And it likely can be done by still defaulting to nullable references. For example, it can be done with the help of @nonnullable (like immutable) type qualifier and semantic check of operations involving references with such qualifier. Sounds like a deal for now, but @nonnullable will only work with class references and anything else will be an error. So directly attaching it to the type (like the questionmark) makes more sense. Anyway, my estimation of probability of accepting constructions like type, type*?, etc and defaulting to non-null references is very low, at least for D2. That's right, but let's use the youth of the language to change this. I guess many will hate me if we do so.
Re: References in D
On Wednesday, 3 October 2012 at 16:58:52 UTC, Maxim Fomin wrote: How much code would be broken by moving nullable references from current state to question mark notation? That's another question :] I expect that non-nullable class objects (called references here) addition (if there is no objections to idea in general) would not break much code and would not request vast syntax changes. And it likely can be done by still defaulting to nullable references. For example, it can be done with the help of @nonnullable (like immutable) type qualifier and semantic check of operations involving references with such qualifier. Sounds like a deal for now, but @nonnullable will only work with class references and anything else will be an error. So directly attaching it to the type (like the questionmark) makes more sense. Anyway, my estimation of probability of accepting constructions like type, type*?, etc and defaulting to non-null references is very low, at least for D2. That's right, but let's use the youth of the language to change this. I guess many will hate me if we do so.
Re: References in D
On Wednesday, 3 October 2012 at 17:37:14 UTC, Franciszek Czekała
wrote:
No, it is meaningless. If you have a class which is supposed to
hold a prime number and you pass it to a function are you going
to check each time that the value is indeed prime? That would
kill the efficiency of your program guaranteed. So you would be
happy to know that the reference is non-null but you would take
it for granted the value is indeed prime? Does it make any
sense?
You have to decide which information should be available at
compile- and runtime. And that is not easy. In general, it's
always better to have information present at compile time. To
come back to your example:
class Number {
this(int i) {
this.i = i;
}
const int i;
}
class PrimeNumber : Number {
this(int i) {
// Check whether i is a prime number or not...
super(i);
}
}
void func(PrimeNumber num);
That's a way to check this at compile time and pass the number
without runtime checks between prime number functions. But it
requires i to be constant throughout the lifetime of Number.
It always depends on the context if the use of an extra class
makes sense.
I maintain that this non-null advantage does not warrant to
make the language more complicated even by a tiny bit. It is
dwarfed by normal considerations related to program correctness.
With default null references:
A)either null is an expected non-value for the type (like in
the chess example), checking for it is part of normal
processing then
Great, use a question mark.
B) or null is not a valid value, then there is no need to check
for it. If you get a null reference it is a bug. It is like
getting a 15 for your prime number. You do not put checks like
that in your code. You test your prime generation routine not
the consumers. If your function gets a null reference when it
should not, some other part of your program is buggy. You do
not process bugs in your code - you remove them from it.
Contract programming comes into play. But still, you have to
write contracts containing all those assertions. In libraries you
can't even use contracts in most cases.
However with D, dereferencing an uninitialized reference is
well defined - null is not random data: you get a well-defined
exception and you know you are dealing with unitialized data.
This is easy to fix. You just go up the stack and check where
the reference comes from. Much easier probably than finding out
why your prime numbers turn out to be divisible by 3. How about
introducing some syntax that will rule this out?
If you write an application, indeed, it's easy to fix.
To quote (loosely) Mr. Walter Bright from another discussion:
how many current bugs in dmd are related to default null
references?
DMD is an application, not a library.
References in D
The way D is dealing with classes reminds me of pointers because you can null them. C++'s references cannot (of course you can do some nasty casting). So you can be sure to have a valid well-defined object. But then there is always the ownership problem which renders them more dangerous as they seem to be. D resolves this problem using a garbage collector. So why not combine the advantages of C++ references always there guarantee and D's garbage collector and make D's references not nullable? If you want it to be nullable, you can still make use of real pointers. Pointers can be converted to references by implicitly do a runtime check if the pointer is not null and references can be converted back to pointers. I guess you had good reasons about choosing the nullable version of D references. Explain it to me, please.
Re: References in D
On Saturday, 15 September 2012 at 12:49:23 UTC, Russel Winder wrote: On Sat, 2012-09-15 at 14:44 +0200, Alex Rønne Petersen wrote: […] Anyway, it's too late to change it now. I disagree. There are always opportunities to make changes to things, you just have manage things carefully. I don't know if people really use the ability of references being null. If so, large amounts of code will be broken. The best way to stay tuned for that change is to always pray references to be valid, thus to do no explicit runtime checks. Are you using reference runtime checks in your current code?
Re: References in D
On Saturday, 15 September 2012 at 13:36:00 UTC, Maxim Fomin wrote:
On Saturday, 15 September 2012 at 12:43:22 UTC, Alex Rønne
Petersen wrote:
But this being said, I agree that references being nullable by
default is hurtful. It allows any object reference to have an
invalid state even though in 99% of cases, that doesn't make
sense. It's a giant hole in the type system that many new
languages have gotten rid of very early (forcing the
programmer to use explicit option/nullable types).
Are speaking about classes? Then how they can be initialized
(except for null and other existing object)?
When you want it to be initialized with null, use a pointer. Else
you can use something like this:
class AClass {
this(BClass bclass = new BClass) {
_class = bclass;
}
BClass _class;
}
By the way, a pointer holds two pieces information:
1) If there is an object available
2) If so, the object itself
In most cases, you only need the second one and the if is
redunant.
Re: References in D
On Saturday, 15 September 2012 at 14:36:33 UTC, Maxim Fomin wrote:
On Saturday, 15 September 2012 at 14:17:53 UTC, Simen Kjaeraas
wrote:
And in real code it could crash after dereferencing and
before passing to bar, if accessed (meaning that problem is
in erroneous pointer usage, not accepting ints through
reference in bar). Certainly, it is possible to break even in
such cases, as well as in other parts of the language which
doesn't necessarily mean that such parts of the language are
broken. What I was talking about is:
void bar( ref int n ) {
n = 3;
}
void main( ) {
int* p = null;
bar(p); // error
bar(null); //error
}
But that's like saying bar(int n) doesn't accept null as a
parameter - of
course it doesn't - int and int* are different types.
What I'm saying is references may be a bit safer than
pointers, but the
'guarantee' that they're not null pointers in disguise is a
lie.
Again, what is the talk about? References in function
parameters or class objects? In the first case ref parameter
has nothing to do with whether was a valid object passed to
function or not (as like in your case). It only means that
function works with actual object, not a copy. Obviously, it is
impossible to pass a pointer or null when other type is
expected.
If you speaking about class objects, than certainly it may
reference a valid region of memory or null (in bad and rare
cases, to random memory).
It is just about references to class objects.
Finally, will references to class objects in D stay nullable in
future versions (D3)? What do you think?
Re: References in D
On Saturday, 15 September 2012 at 17:12:23 UTC, Jonathan M Davis wrote: Of course people use it. Having nullable types is _highly_ useful. It would suck if references were non-nullable. That would be _horrible_ IMHO. Having a means to have non-nullable references for cases where that makes sense isn't necessarily a bad thing, but null is a very useful construct, and I'd _hate_ to see normal class references be non-nullable. - Jonathan M Davis And many usages of null as a state leads to really bad design. There are functions which behaviour is completly different if you pass null instead of a valid pointer/reference. An example would be: http://www.khronos.org/registry/cl/sdk/1.1/docs/man/xhtml/clGetDeviceIDs.html
Re: References in D
On Saturday, 15 September 2012 at 18:05:55 UTC, Jonathan M Davis wrote: I'd argue that using null for indicating something other than the lack of a value is bad design. But there are plenty of cases where being able to indicate that there is no value is useful. I agree. And if a function requires that a pointer or reference or array or whatever have a value, then there's always DbC or exceptions. So why not clear this up at compile time if possible? Then you can also easily distinguish between really there and maybe there objects by passing either a reference or a pointer. Just because someone can misuse a feature doesn't mean that a feature shouldn't be there. Why not set the non-nullable references, which cannot be misused, as default and still enable the nullable references feature as optional by passing a pointer.
Re: References in D
On Saturday, 15 September 2012 at 21:30:03 UTC, Walter Bright wrote: On 9/15/2012 5:39 AM, Henning Pohl wrote: The way D is dealing with classes reminds me of pointers because you can null them. C++'s references cannot (of course you can do some nasty casting). Doing null references in C++ is simple: int *p = NULL; int r = *p; r = 3; // crash Next time I think before I write.
Recursive expansion
I've ended up with a TypeTuple storing 1230 auto-generated types. Now the compiler claims there is a recursive template expansion. How to stir him from his resolve?
Re: Recursive expansion
On Friday, 17 August 2012 at 22:01:42 UTC, Jonathan M Davis wrote: On Friday, August 17, 2012 23:45:49 Henning Pohl wrote: I've ended up with a TypeTuple storing 1230 auto-generated types. Now the compiler claims there is a recursive template expansion. How to stir him from his resolve? I believe that if a particular template is ever instantiated more than 50 times recursively, the compiler will error out on the assumption that it's hit infinite recursion (it has to bottom out eventually, or would just end up running until it ran out of memory if it actually does hit infinite recursion; I don't know how arbitrary the choice of 50 was). So, the TypeTuple itself shouldn't be a problem (e.g. you should be able to use foreach on it just fine), but template instantiations will be a problem if you try and go through the whole TypeTuple recursively. - Jonathan M Davis Damn, I just ran out of memory using ~ 550 types. DMD was flooding my 8GB RAM like in 5 seconds. Fortunately I could kill DMD just in time. So there have to be another solution. I want to store lots (~615) dynamically loaded function pointers in a class and call them using opDispatch. To provide a type-safe function call, the types of the functions have to be stored somewhere, in a TypeTuple. Maybe you can help me how this could be done.
Re: Recursive expansion
On Friday, 17 August 2012 at 22:28:12 UTC, bearophile wrote: Henning Pohl: I want to store lots (~615) dynamically loaded function pointers in a class and call them using opDispatch. To provide a type-safe function call, the types of the functions have to be stored somewhere, in a TypeTuple. Function pointers in a TypeTuple? Do you mean a Tuple? Can't you use an array? Bye, bearophile Sorry, I meant function types like void function(int i, string s)
Re: Specialize mixin templates
On Sunday, 12 August 2012 at 02:32:30 UTC, Timon Gehr wrote:
On 08/11/2012 11:42 PM, Henning Pohl wrote:
A struct takes a mixin template as argument:
struct S(alias Mixin) {
mixin Mixin;
}
How to specialize a mixin template like this one to pass to S?
mixin template MixinTemplate(T) {
}
S(MixinTemplate!float); // Something like this
This is a way to do it:
struct S(alias Mixin){
mixin Mixin;
}
mixin template MixinTemplate(T){
}
mixin template MixinTemplateFloat(){
mixin MixinTemplate!float;
}
S!MixinTemplateFloat s;
I've already found another way, but I think this proposal seems
cleaner, thank you.
Check whether a type is a instantiated by a template struct
So the struct is defined as:
struct S(T) {
}
template isS(T) {
// ...
}
static assert(isS(S!float));
static assert(!isS(float));
There may be some nasty ways using fullQualifiedName!T and so on
but I guess there is a better way, isn't it?
Re: Check whether a type is a instantiated by a template struct
On Saturday, 11 August 2012 at 19:06:22 UTC, Chris Cain wrote:
Same idea, but doing it with just one template and using static
ifs...
struct S(T) {}
template isS(T) {
static if(is(T _ : S!U, U))
enum isS = true;
else
enum isS = false;
}
static assert(isS!(S!float));
static assert(!isS!float);
Thank you two. Did not know about the great abilities of is.
Specialize mixin templates
A struct takes a mixin template as argument:
struct S(alias Mixin) {
mixin Mixin;
}
How to specialize a mixin template like this one to pass to S?
mixin template MixinTemplate(T) {
}
S(MixinTemplate!float); // Something like this
Access template parameters at runtime
A struct is meant to take only integers as parameters:
struct SomeStruct(intergers...) {
int opIndex(size_t idx) /* ... */ {
return integers[idx]; // Error ...
}
}
alias SomeStruct!(1, 2, 3) ss;
But it results in:
Error: undefined identifier integers, did you mean tuple
intergers?
How can this problem be solved?
Re: Access template parameters at runtime
On Friday, 10 August 2012 at 14:02:08 UTC, Andrei Alexandrescu
wrote:
On 8/10/12 9:55 AM, Henning Pohl wrote:
A struct is meant to take only integers as parameters:
struct SomeStruct(intergers...) {
int opIndex(size_t idx) /* ... */ {
return integers[idx]; // Error ...
}
}
alias SomeStruct!(1, 2, 3) ss;
But it results in:
Error: undefined identifier integers, did you mean tuple
intergers?
How can this problem be solved?
By fixing the typo?
Andrei
Oups, sorry, imagine there isn't one.
So the error is: variable idx cannot be read at compile time.
Re: Access template parameters at runtime
On Friday, 10 August 2012 at 14:10:38 UTC, Vladimir Panteleev wrote: On Friday, 10 August 2012 at 14:10:02 UTC, Vladimir Panteleev wrote: On Friday, 10 August 2012 at 14:05:16 UTC, Henning Pohl wrote: Oups, sorry, imagine there isn't one. So the error is: variable idx cannot be read at compile time. You can't index a tuple during compilation. Sorry, meant to say - during runtime. Thats it, thank you :]
Re: Access template parameters at runtime
On Friday, 10 August 2012 at 14:35:29 UTC, trav...@phare.normalesup.org (Christophe Travert) wrote: Henning Pohl , dans le message (digitalmars.D:174569), a écrit : On Friday, 10 August 2012 at 14:10:38 UTC, Vladimir Panteleev wrote: On Friday, 10 August 2012 at 14:10:02 UTC, Vladimir Panteleev wrote: On Friday, 10 August 2012 at 14:05:16 UTC, Henning Pohl wrote: Oups, sorry, imagine there isn't one. So the error is: variable idx cannot be read at compile time. You can't index a tuple during compilation. Sorry, meant to say - during runtime. Thats it, thank you :] Note that if your design makes that you must have a tuple, you may build the array at compile time, so that you can index it at run time. That is what I was trying first, but I could not make it work. Maybe you can show me how it's done?
Re: Access template parameters at runtime
Great, thank you :] The solution provided by David seems to be shortest. You can even pass the ints directly.
Closed source D libraries
Most closed source C and C++ libraries provide headers and binaries. It seems to me that there is no way to do this in D, because the source files always have to be available to import their modules. I'm not going to write something proprietary or closed source, but i wonder if others can do so.
Re: Closed source D libraries
On Sunday, 15 July 2012 at 12:21:23 UTC, Gor Gyolchanyan wrote:
On Sun, Jul 15, 2012 at 4:05 PM, Henning Pohl
henn...@still-hidden.dewrote:
Most closed source C and C++ libraries provide headers and
binaries. It
seems to me that there is no way to do this in D, because the
source files
always have to be available to import their modules.
I'm not going to write something proprietary or closed source,
but i
wonder if others can do so.
It's quite possible. All you have to do is make a module, which
doesn't
contain any function bodies. The imported modules aren't
compiled with the
code. Most of the time it's easier to have a single module to
have both the
code to compile and symbols to import. In other cases they can
be separated.
Okay, so it works just like in C:
// The header file
module lib;
void printHelloWorld();
// The source file
module lib
import std.stdio;
void printHelloWorld() {
writeln(Hello world!);
}
Re: Closed source D libraries
On Sunday, 15 July 2012 at 13:26:19 UTC, Benjamin Thaut wrote:
Am 15.07.2012 15:06, schrieb Gor Gyolchanyan:
On Sun, Jul 15, 2012 at 4:33 PM, Henning Pohl
henn...@still-hidden.de
mailto:henn...@still-hidden.de wrote:
On Sunday, 15 July 2012 at 12:21:23 UTC, Gor Gyolchanyan
wrote:
On Sun, Jul 15, 2012 at 4:05 PM, Henning Pohl
henn...@still-hidden.de
mailto:henn...@still-hidden.de__wrote:
Most closed source C and C++ libraries provide
headers and
binaries. It
seems to me that there is no way to do this in D,
because
the source files
always have to be available to import their modules.
I'm not going to write something proprietary or
closed
source, but i
wonder if others can do so.
It's quite possible. All you have to do is make a
module, which
doesn't
contain any function bodies. The imported modules aren't
compiled with the
code. Most of the time it's easier to have a single
module to
have both the
code to compile and symbols to import. In other cases
they can
be separated.
Okay, so it works just like in C:
// The header file
module lib;
void printHelloWorld();
// The source file
module lib
import std.stdio;
void printHelloWorld() {
writeln(Hello world!);
}
Exactly. Not defining a function body is perfectly fine for
precisely
these reasons. And, just like in C, forgetting to link with
the missing
body will result in a linker error.
--
Bye,
Gor Gyolchanyan.
The compiler can even generate those files for using the -H
option. It will generate .di files. Although any formatting
will get lost during that process.
Kind Regards
Benjamin Thaut
All right, thank you for the clarification.
