c.add(2);
c.writeln; // x + 2 +
// with constructor:
c = Calculate("x");
c.add(2);
c.writeln; // x + 2 +
}
```
There is a simple struct like the one above that is not related
to reality. There can be more than 2 function overloading in
it, but in our example there
On Thursday, 2 November 2023 at 11:17:42 UTC, Salih Dincer wrote:
On Wednesday, 1 November 2023 at 20:04:52 UTC, Basile B. wrote:
Yes. D constructors are not named but the current
implementation adds a name that is `__ctor`, so add
```d
alias add = __ctor;
```
to you struct.
Yeah, it wor
On Wednesday, 1 November 2023 at 20:04:52 UTC, Basile B. wrote:
Yes. D constructors are not named but the current
implementation adds a name that is `__ctor`, so add
```d
alias add = __ctor;
```
to you struct.
Yeah, it works! Thanks...:)
SDB@79
On Tuesday, 31 October 2023 at 20:09:44 UTC, Salih Dincer wrote:
[...]
is it possible to do something like `alias add = this;`?
```d
struct Calculate
{
int memory;
string result;
auto toString() => result;
// alias add = this;
import std.string : format;
this(stri
c = Calculate("x");
c.add(2);
c.writeln; // x + 2 +
}
```
There is a simple struct like the one above that is not related
to reality. There can be more than 2 function overloading in it,
but in our example there are only 2. Without implementing a
similar function again for each c
On Wednesday, 22 June 2022 at 12:42:48 UTC, Steven Schveighoffer
wrote:
On 6/22/22 2:05 AM, monkyyy wrote:
On Monday, 20 June 2022 at 13:20:51 UTC, Steven Schveighoffer
wrote:
And you can also use an inner struct to define overloaded
functions.
I believe templates make a better bandaid
```d
v
On 6/22/22 2:05 AM, monkyyy wrote:
On Monday, 20 June 2022 at 13:20:51 UTC, Steven Schveighoffer wrote:
And you can also use an inner struct to define overloaded functions.
I believe templates make a better bandaid
```d
void main(){
template bar(){
void bar_(int){}
void
On Monday, 20 June 2022 at 13:20:51 UTC, Steven Schveighoffer
wrote:
And you can also use an inner struct to define overloaded
functions.
I believe templates make a better bandaid
```d
void main(){
template bar(){
void bar_(int){}
void bar_(float){}
On 6/17/22 8:09 AM, Chris Katko wrote:
I don't need this functionality, but I wanted to be sure.
Does function overloading not work with nested functions? I got a
compiler error (something like "function already defined") when I tried it.
Correct, it's not allowed.
Howev
On Friday, 17 June 2022 at 13:04:47 UTC, Chris Katko wrote:
On Friday, 17 June 2022 at 12:19:33 UTC, bauss wrote:
On Friday, 17 June 2022 at 12:09:33 UTC, Chris Katko wrote:
I don't need this functionality, but I wanted to be sure.
Does function overloading not work with nested functio
On Friday, 17 June 2022 at 12:19:33 UTC, bauss wrote:
On Friday, 17 June 2022 at 12:09:33 UTC, Chris Katko wrote:
I don't need this functionality, but I wanted to be sure.
Does function overloading not work with nested functions? I
got a compiler error (something like "functi
On Friday, 17 June 2022 at 12:09:33 UTC, Chris Katko wrote:
I don't need this functionality, but I wanted to be sure.
Does function overloading not work with nested functions? I got
a compiler error (something like "function already defined")
when I tried it.
According t
I don't need this functionality, but I wanted to be sure.
Does function overloading not work with nested functions? I got a
compiler error (something like "function already defined") when I
tried it.
On Thursday, 22 February 2018 at 21:12:45 UTC, JN wrote:
Is this expected behaviour?
bar.d
---
void foo(string s)
{
}
app.d
---
import std.stdio;
import bar;
void foo(int x)
{
}
void main()
{
foo("hi");
};
===
Error: function app.foo (int x) is not callable using argument
types (string
JN wrote:
same idea?
absolutely the same. non-qualified imports (be it template, or function)
won't take part in overload resoultion.
On Thursday, 22 February 2018 at 21:19:12 UTC, ketmar wrote:
yes. this is done so unqualified won't silently "steal" your
functions. this can cause some unexpected (and hard to find)
bugs.
if you want it to work, you can either do qualified import
import bar : foo;
or manuall bring
JN wrote:
Is this expected behaviour?
bar.d
---
void foo(string s)
{
}
app.d
---
import std.stdio;
import bar;
void foo(int x)
{
}
void main()
{
foo("hi");
};
===
Error: function app.foo (int x) is not callable using argument types
(string)
yes. this is done so unqualified won't si
Is this expected behaviour?
bar.d
---
void foo(string s)
{
}
app.d
---
import std.stdio;
import bar;
void foo(int x)
{
}
void main()
{
foo("hi");
};
===
Error: function app.foo (int x) is not callable using argument
types (string)
On Thursday, 10 November 2016 at 20:12:10 UTC, Jonathan M Davis
wrote:
On Thursday, November 10, 2016 17:41:02 Picaud Vincent via
Digitalmars-d- learn wrote:
It is certainly a compiler problem: I used gdc -> compile
error, but with dmd it compiles and runs fine. Full details in
the git repo.
On Thursday, November 10, 2016 17:41:02 Picaud Vincent via Digitalmars-d-
learn wrote:
> It is certainly a compiler problem: I used gdc -> compile error,
> but with dmd it compiles and runs fine. Full details in the git
> repo.
Don't bother with gdc at this point. Unless there's a development vers
On Thursday, November 10, 2016 14:32:28 Steven Schveighoffer via
Digitalmars-d-learn wrote:
> On 11/10/16 12:12 PM, Jonathan M Davis via Digitalmars-d-learn wrote:
> > On Thursday, November 10, 2016 15:46:11 Picaud Vincent via
> > Digitalmars-d-
> >
> > learn wrote:
> >> ---> What am I missing
On 11/10/16 12:12 PM, Jonathan M Davis via Digitalmars-d-learn wrote:
On Thursday, November 10, 2016 15:46:11 Picaud Vincent via Digitalmars-d-
learn wrote:
---> What am I missing? What is the right way to do that?
Honestly, I'm surprised that the compiler let you alias
std.algorithm.compa
On Thursday, 10 November 2016 at 17:12:32 UTC, Jonathan M Davis
wrote:
On Thursday, November 10, 2016 15:46:11 Picaud Vincent via
Digitalmars-d- learn wrote:
[...]
Honestly, I'm surprised that the compiler let you alias
std.algorithm.comparison.min, because it's a templated
function, and in t
On Thursday, November 10, 2016 15:46:11 Picaud Vincent via Digitalmars-d-
learn wrote:
> ---> What am I missing? What is the right way to do that?
Honestly, I'm surprised that the compiler let you alias
std.algorithm.comparison.min, because it's a templated function, and in the
case of templat
Hi All,
In my adventure to learn a little bit of D coming from C++ I am
now faced with the following problem:
I have read about "cross-module overloading", §5.5.2 page 146 of
Andrei Alexandrescu book.
That makes sense to me and this is interesting.
As a concrete example here the scenario: I
On Saturday, 18 July 2015 at 13:16:26 UTC, Adam D. Ruppe wrote:
On Saturday, 18 July 2015 at 10:06:07 UTC, Tamas wrote:
Compile & execute:
$ dmd positive0.d; ./positive0; echo $?
$ ldc2 positive0.d; ./positive0; echo $?
Try adding the automatic optimize flags in all your cases. For
dmd, `-O -
On Saturday, 18 July 2015 at 10:06:07 UTC, Tamas wrote:
Compile & execute:
$ dmd positive0.d; ./positive0; echo $?
$ ldc2 positive0.d; ./positive0; echo $?
Try adding the automatic optimize flags in all your cases. For
dmd, `-O -inline`. Not sure about ldc but I think it is `-O` as
well.
Sorry, the main function of positive0.d correctly looks like this:
int main() {
return !((abs(-16) == 16)
&& (abs(3) == 3)
&& (square(5).absPositive == 25)
&& (square(-4).absPositive == 16));
}
But this does not affect the results, the asm file sizs or the
asm abs function bodies.
I made a thorough comparison using multiple compilers and a
summary of the findings. In short, there is a runtime overhead.
I reduced the code to cut out the imports and made two versions
with equivalent semantic content.
positive0.d contains the hand written specializations of the abs
functio
On Friday, 17 July 2015 at 23:44:25 UTC, Tamas wrote:
I used DMD, BTW.
what compile flags?
On Friday, 17 July 2015 at 21:20:41 UTC, Tamas wrote:
Although this code is fully operational, presents nice api and
compile-time optimizations, the extra Struct wrapper is not
without runtime penalty.
Is there a solution that results the same static optimizations,
but has no runtime penalty,
On Friday, 17 July 2015 at 23:16:51 UTC, ZombineDev wrote:
On Friday, 17 July 2015 at 23:15:31 UTC, ZombineDev wrote:
On Friday, 17 July 2015 at 21:20:41 UTC, Tamas wrote:
Is there a solution that results the same static
optimizations, but has no runtime penalty, i.e. the functions
just operat
On Friday, 17 July 2015 at 23:15:31 UTC, ZombineDev wrote:
On Friday, 17 July 2015 at 21:20:41 UTC, Tamas wrote:
Is there a solution that results the same static
optimizations, but has no runtime penalty, i.e. the functions
just operates with ints? (At least when compiled)
Did you try looking
On Friday, 17 July 2015 at 21:20:41 UTC, Tamas wrote:
Is there a solution that results the same static optimizations,
but has no runtime penalty, i.e. the functions just operates
with ints? (At least when compiled)
Did you try looking at assembly generated by GDC or LDC with full
optimization
I got inspired by Andrei's "Generic Programming Must Go" talk:
https://www.youtube.com/watch?v=mCrVYYlFTrA
I.e. writing functions with static if-s, based on what we know
about the input.
So the question is how to annotate the input variables?
Adam showed an excellent solution for this, by wrap
On 4/26/14, Jonathan M Davis via Digitalmars-d-learn
wrote:
> No. That's expected.
I wonder whether a better diagnostic could help. But then again, maybe
the hiding would be intentional and the diagnostic would be
spurious/invalid. Not sure..
On Sat, 26 Apr 2014 06:55:38 +
Domain via Digitalmars-d-learn
wrote:
> module test;
>
> public interface I
> {
> void foo();
> void foo(int);
> }
>
> public abstract class A : I
> {
> public void bar()
> {
> foo();
> }
>
> public void foo(int i)
>
module test;
public interface I
{
void foo();
void foo(int);
}
public abstract class A : I
{
public void bar()
{
foo();
}
public void foo(int i)
{
}
}
public class C : A
{
public void foo()
{
}
public void bar2()
{
foo(1);
On Monday, 14 April 2014 at 10:35:20 UTC, Jonathan M Davis wrote:
On Sunday, April 13, 2014 08:40:17 Philpax wrote:
Is not being able to overload functions in local scope intended
behaviour?
Yes. IIRC, I complained about it at one point, and Walter
didn't like the idea
of having overloaded ne
On Sunday, April 13, 2014 08:40:17 Philpax wrote:
> Is not being able to overload functions in local scope intended
> behaviour?
Yes. IIRC, I complained about it at one point, and Walter didn't like the idea
of having overloaded nested functions. I don't remember what his reasoning
was, but I do
Thanks! I used the static struct solution.
I did some quick research, and I think that the reason why the
original code doesn't work is because the two functions have the
same identifier, which results in Dsymboltable::insert rejecting
the second function. I haven't tested this hypothesis, but
On 4/12/14, monarch_dodra wrote:
> I know you can workaround it by putting
> your functions a static members of a dummy struct
You can also use a mixin template:
class A {}
class B {}
mixin template M()
{
void func2(A a) { }
void func2(B b) { }
}
void main()
{
mixin M!();
func
On Saturday, 12 April 2014 at 16:45:02 UTC, Philpax wrote:
While trying to overload a function in local/function scope, I
ran into this behaviour: http://dpaste.dzfl.pl/b4e8b9ddf78a and
I was wondering what the cause was.
As far as I can tell, this should be fine in global scope (and
it is),
While trying to overload a function in local/function scope, I
ran into this behaviour: http://dpaste.dzfl.pl/b4e8b9ddf78a and I
was wondering what the cause was.
As far as I can tell, this should be fine in global scope (and it
is), but I'm curious as to why it doesn't work inside a function.
== Quote from Stanislav Blinov (bli...@loniir.ru)'s article
> In C++ I sometimes have similar problems, especially with multiple
> inheritance. Though, as Jonathan mentioned, those problems are even more
> annoying because of hijacking: you don't always immediately notice them.
> Long ago I've deci
09.01.2011 15:22, %u пишет:
== Quote from bearophile (bearophileh...@lycos.com)'s article
%u:
func(cast(I2)(new C()));
That code smells a bit (http://en.wikipedia.org/wiki/Code_smell ).
Bye,
bearophile
Extract the construction and you get:
module main;
interface I1{}
interface I2 :
%u:
> What is the deeper problem in this little snippet?
> Or do you mean there is something wrong if you encounter this pattern.
You are right, sorry :-)
Bye,
bearophile
== Quote from bearophile (bearophileh...@lycos.com)'s article
> %u:
> > func(cast(I2)(new C()));
> That code smells a bit (http://en.wikipedia.org/wiki/Code_smell ).
> Bye,
> bearophile
Extract the construction and you get:
module main;
interface I1{}
interface I2 : I1{}
class C : I2{
%u:
> func(cast(I2)(new C()));
That code smells a bit (http://en.wikipedia.org/wiki/Code_smell ).
Bye,
bearophile
== Quote from Jonathan M Davis (jmdavisp...@gmx.com)'s article
> On Saturday 08 January 2011 22:01:11 %u wrote:
> > Isn't it possible to have a hierarchy in interface definitions such that it
> > is possible to overload according to best interface match?
> >
> > This now won't compile due to multip
On Saturday 08 January 2011 22:01:11 %u wrote:
> Isn't it possible to have a hierarchy in interface definitions such that it
> is possible to overload according to best interface match?
>
> This now won't compile due to multiple matches.
>
>
> module main;
>
> interface I1{}
> interface I2
Isn't it possible to have a hierarchy in interface definitions such that it is
possible to overload according to best interface match?
This now won't compile due to multiple matches.
module main;
interface I1{}
interface I2 : I1{}
class C : I2{
this(){}
}
void func(I1 i){}
void func(I2
52 matches
Mail list logo
