So I changed it into 'ref&'.
Quick example:
[code]
void bar1(ref& A a) { } // OK
void bar2(ref &A a) { } // OK
void bar21(&A a) { } // Error: '&' can only be used in
combination with 'ref'.
void bar22(& A a) { } // Error: '&' can only be used in
combination with 'ref'.
void bar3(ref const& A
On Wednesday, 27 March 2013 at 09:10:35 UTC, Minas Mina wrote:
auto in?
in ref?
in ref was suggested by Kenji and rejected by Jonathan.
What should auto in mean? auto const scope?
I have to say that I like ref&, it's the best of two worlds. :)
We need a clear statement so someone ca
auto in?
in ref?
I tried the last few hours to implement something like 'A&' but
it's horrible if you haven't complete knowledge and want to
implement something that comes after the type...
But what's wrong with '@ref'? If I had knowledge how you could
implement new properties I could start a trial.
Afte
"Thats the reason why all following declarations behave as const:"
should be
"Thats the reason why all following declarations behave as
const&:"
On Tuesday, March 26, 2013 18:11:42 Jonathan M Davis wrote:
> On Tuesday, March 26, 2013 22:55:56 Minas Mina wrote:
> > Why is "const ref" not a good choice?
>
> I really don't want to get into that again. There have been a number of
> discussions on it in the main newsgroup which you can search f
of C++ that const& accepts rvalues, and he
does not want to repeat that in D. So, just like ref, const ref in D accepts
only lvalues (they're just const instead of mutable), and that's not going to
change.
auto ref was introduced specifically to solve the problem of having a
Why is "const ref" not a good choice?
On Tuesday, March 26, 2013 10:02:32 Timothee Cour wrote:
> how about '&' :
>
> void fun(int & x);
>
> which is same as C++ syntax, hence familiar. I thought someone had
> proposed that a few weeks ago
That would be a much larger change, and I'd be surprised if Walter or Andrei
went for that. Pi
how about '&' :
void fun(int & x);
which is same as C++ syntax, hence familiar. I thought someone had
proposed that a few weeks ago
On Tue, Mar 26, 2013 at 9:56 AM, Jonathan M Davis wrote:
> On Tuesday, March 26, 2013 17:22:29 Namespace wrote:
>> On Tuesday, 26 March 2013 at 11:41:13 UTC, Names
On Tuesday, March 26, 2013 17:22:29 Namespace wrote:
> On Tuesday, 26 March 2013 at 11:41:13 UTC, Namespace wrote:
> > I wonder, if someone has already thought about "immutable ref".
> > I can not imagine that many use it, so it wouldn't break (much)
> > code.
>
> immutable ref works (for me) very
On Tuesday, 26 March 2013 at 11:41:13 UTC, Namespace wrote:
I wonder, if someone has already thought about "immutable ref".
I can not imagine that many use it, so it wouldn't break (much)
code.
immutable ref works (for me) very well. Are there any pitfalls
that I can not see?
I wonder, if someone has already thought about "immutable ref". I
can not imagine that many use it, so it wouldn't break (much)
code.
You make me curious about this new attribute. Maybe I could then
help to implement this along with its task.
I do not think anyone else has the time to do it.
I hope that you will find the link.
On Tuesday, March 26, 2013 00:52:56 Namespace wrote:
> Forgot to ask:
> Wouldn't it be better to publish this decision?
> Many still believe the nonsense (like me) that 'auto ref' is
> still the solution.
An official decision would mean that Walter had been invol
Forgot to ask:
Wouldn't it be better to publish this decision?
Many still believe the nonsense (like me) that 'auto ref' is
still the solution.
I appreciate your efforts and look forward to the link. :)
But I never heard anything about that. How long has it been since
that was suggested?
But that's honestly sad to hear. I thought I would contribute to
the solution of this problem. Then we'll have to wait and
continue to hope.
On Monday, March 25, 2013 23:35:06 Namespace wrote:
> > Because the number of instantiations of the template could grow
> > exponentially
> > as the number of auto ref parameters grows. Being able to use
> > the trick with
> > the temporary with templated func
Because the number of instantiations of the template could grow
exponentially
as the number of auto ref parameters grows. Being able to use
the trick with
the temporary with templated functions could really help reduce
template bloat
when the current meaning of auto ref is not necessary, but
do it. It's just that
> > there's a high
> > risk that the pull request would languish for a while. And it
> > would probably
> > need to be implemented with a name other than auto ref in order
> > to avoid the
> > aforementioned problems, and having
while. And it
would probably
need to be implemented with a name other than auto ref in order
to avoid the
aforementioned problems, and having to agree on that could
cause further
delay.
I am currently working in the required part of the compiler, but
I need help and other opinions.
So far
The only thing I'm aware of which explains anything about the
compiler outside
of the compiler's code itself is this page here:
http://prowiki.org/wiki4d/wiki.cgi?DMDSourceGuide
- Jonathan M Davis
Alright, It seems as if my knowledge is too limited to somehow
contribute to a solution.^^
On Saturday, March 16, 2013 14:41:37 Namespace wrote:
> > Basically, someone needs to implement it and then talk Walter
> > into accepting
> > it. That'll be easier for someone like Kenji, who's already a
> > major
> > contributor, but in theory, anyone can do it.
>
> Are there any tutorials or so
Basically, someone needs to implement it and then talk Walter
into accepting
it. That'll be easier for someone like Kenji, who's already a
major
contributor, but in theory, anyone can do it.
Are there any tutorials or something similar, which make you a
bit familiar with the compiler front-en
So first of all we have to find a new syntax/name?
AFAIK Kenji made a pull request for a new implementation of
'auto ref' a few months ago. If that was already in the proposed
manner of Jonathan, we need not to discuss with Walter, because
the pull is open for months.
On Friday, March 15, 2013 18:15:21 Namespace wrote:
> And it is planned to change the functionality of 'auto ref' to
> the proposed variant of Jonathan? Or was his proposal rejected?
I don't think that there was any official decision of any kind. IIRC, Kenji was
looking
On Fri, 15 Mar 2013 13:15:21 -0400, Namespace
wrote:
And it is planned to change the functionality of 'auto ref' to the
proposed variant of Jonathan? Or was his proposal rejected?
I have no idea. All I know is that Jonathan's proposal is really what
Andrei wanted origin
And it is planned to change the functionality of 'auto ref' to
the proposed variant of Jonathan? Or was his proposal rejected?
On Fri, 15 Mar 2013 12:32:35 -0400, Namespace
wrote:
But it works already for templates.
So if it's confusing, then, why was it introduced?
The way it works for templates is to generate two separate functions, one
which takes ref and one which takes by value.
The proposed aut
But it works already for templates.
So if it's confusing, then, why was it introduced?
l, we need definitely a solution
for this problem.
It seems that the other pull isn't finished in the next two
release cycles.
We know that your code works partially, that is better than
further releases without an auto ref...
still there. Will the pull merged in the near
future or not?
I'm asking because I'm afraid that it takes several months until
D has 'auto ref'.
It turns out there already was a pull request that does this:
https://github.com/D-Programming-Language/dmd/pull/1019
The pull request is still unmerged. Isn't this important enough
or is the pull invalid?
On Sunday, 6 January 2013 at 11:32:40 UTC, Jacob Carlborg wrote:
On 2013-01-05 23:40, michaelc37 wrote:
i was trying to make a D template to mimic auto-implemented
properties in c#.
I think i got it to work but when i tried to give the template
a
more meaning full name like
On 2013-01-05 23:40, michaelc37 wrote:
i was trying to make a D template to mimic auto-implemented
properties in c#.
I think i got it to work but when i tried to give the template a
more meaning full name like AutoImplementedProperty i get a
compile error "a.title is not an lvalue".
On 01/05/2013 04:32 PM, Ali Çehreli wrote:
> I confirm this: Any name other than the seemingly magical autoproperty
> causes the following errors:
>
> Error: a.title is not an lvalue
> Error: expression has no value
I retract that! :) That happens when I replace only the two
"autoproperty" with
On 01/05/2013 03:25 PM, michaelc37 wrote:
On Saturday, 5 January 2013 at 22:53:44 UTC, Philippe Sigaud wrote:
Hi Michael,
your code works for me (DMD 2.061, Linux), with a semicolon after the
alias
in class Bar.
Also, use writeln, not writefln, because writefln assumes the first
parameter is t
On Saturday, 5 January 2013 at 23:00:48 UTC, monarch_dodra wrote:
On Saturday, 5 January 2013 at 22:53:44 UTC, Philippe Sigaud
wrote:
Hi Michael,
your code works for me (DMD 2.061, Linux), with a semicolon
after the alias
in class Bar.
Also, use writeln, not writefln, because writefln assume
On Saturday, 5 January 2013 at 22:53:44 UTC, Philippe Sigaud
wrote:
Hi Michael,
your code works for me (DMD 2.061, Linux), with a semicolon
after the alias
in class Bar.
Also, use writeln, not writefln, because writefln assumes the
first
parameter is the formatting string.
Thanks for the
On Saturday, 5 January 2013 at 22:53:44 UTC, Philippe Sigaud
wrote:
Hi Michael,
your code works for me (DMD 2.061, Linux), with a semicolon
after the alias
in class Bar.
Also, use writeln, not writefln, because writefln assumes the
first
parameter is the formatting string.
Why would you w
Hi Michael,
your code works for me (DMD 2.061, Linux), with a semicolon after the alias
in class Bar.
Also, use writeln, not writefln, because writefln assumes the first
parameter is the formatting string.
i was trying to make a D template to mimic auto-implemented
properties in c#.
I think i got it to work but when i tried to give the template a
more meaning full name like AutoImplementedProperty i get a
compile error "a.title is not an lvalue".
Is this a bug?
Is there a more suita
On Wednesday, 2 January 2013 at 01:05:09 UTC, Namespace wrote:
Maybe it's best to just make a pull request and let others
inspect the changes and discuss the semantics of auto ref. Or
maybe it would be better to make a thread in digitalmars.D
first?
In my opinion you should do both, t
In my opinion you should do both, thread and also pull request.
I thank you again for your work. I'm using it already.
I have opened a pull request now and replied to the thread about
auto ref on digitalmars.D.
Maybe it's best to just make a pull request and let others
inspect the changes and discuss the semantics of auto ref. Or
maybe it would be better to make a thread in digitalmars.D
first?
In my opinion you should do both, thread and also pull request.
I thank you again for your work. I&#x
So it is ready to merge?
I honestly don't know. I don't know enough about the DMD code
base to be confident that there aren't some serious problems with
my changes.
Another problem is that it isn't entirely clear how auto ref is
supposed to work. Should auto ref on
I took over your changes into my current project (which isn't
that small) and it works very well.
On Tuesday, 1 January 2013 at 11:17:36 UTC, jerro wrote:
On Tuesday, 1 January 2013 at 01:10:20 UTC, Namespace wrote:
On Sunday, 30 December 2012 at 16:11:44 UTC, jerro wrote:
On Sunday, 30 December 2012 at 16:00:22 UTC, Namespace wrote:
Just hope for the best. Did you create a pull request?
On Tuesday, 1 January 2013 at 01:10:20 UTC, Namespace wrote:
On Sunday, 30 December 2012 at 16:11:44 UTC, jerro wrote:
On Sunday, 30 December 2012 at 16:00:22 UTC, Namespace wrote:
Just hope for the best. Did you create a pull request?
No. I need to first make it work correctly with const at
On Tuesday, 1 January 2013 at 08:49:29 UTC, Era Scarecrow wrote:
On Monday, 24 December 2012 at 19:09:35 UTC, Jonathan M Davis
wrote:
On Monday, December 24, 2012 20:03:24 monarch_dodra wrote:
Snap. You got me.
It wouldn't matter if the function accepted its argument by
value. You'd still be
On Monday, 24 December 2012 at 19:09:35 UTC, Jonathan M Davis
wrote:
On Monday, December 24, 2012 20:03:24 monarch_dodra wrote:
Snap. You got me.
It wouldn't matter if the function accepted its argument by
value. You'd still be returning a reference to a variable that
doesn't exist anymore.
On Sunday, 30 December 2012 at 16:11:44 UTC, jerro wrote:
On Sunday, 30 December 2012 at 16:00:22 UTC, Namespace wrote:
Just hope for the best. Did you create a pull request?
No. I need to first make it work correctly with const at the
very least.
Sorry if I seem intrusive, but how does it
On Sunday, 30 December 2012 at 16:11:44 UTC, jerro wrote:
On Sunday, 30 December 2012 at 16:00:22 UTC, Namespace wrote:
Just hope for the best. Did you create a pull request?
No. I need to first make it work correctly with const at the
very least.
You should hurry up, it seems that Walter w
On Sunday, 30 December 2012 at 16:00:22 UTC, Namespace wrote:
Just hope for the best. Did you create a pull request?
No. I need to first make it work correctly with const at the very
least.
Just hope for the best. Did you create a pull request?
On Sunday, 30 December 2012 at 13:57:26 UTC, Namespace wrote:
I've played with this a bit today. The code is at
https://github.com/jerro/dmd/tree/auto-ref. I know next to
nothing about DMD, so it could be all kinds of wrong, but it
does at least seem to work.
What do you think should h
I've played with this a bit today. The code is at
https://github.com/jerro/dmd/tree/auto-ref. I know next to
nothing about DMD, so it could be all kinds of wrong, but it
does at least seem to work.
What do you think should happen in this case:
void foo(auto ref int a){}
void foo(
plementing it right now AFAIK, that pretty much puts
the chances at
zero.
I've played with this a bit today. The code is at
https://github.com/jerro/dmd/tree/auto-ref. I know next to
nothing about DMD, so it could be all kinds of wrong, but it does
at least seem to work.
What do you thi
On Saturday, December 29, 2012 19:43:36 Minas Mina wrote:
> So when it will be fixed I will be able to write:
>
> void foo(auto ref Vector3 v);
>
> and it will pass copies or references depending on the situation?
For templated functions, it currently generates either
void fo
On Saturday, 29 December 2012 at 18:43:37 UTC, Minas Mina wrote:
So when it will be fixed I will be able to write:
void foo(auto ref Vector3 v);
and it will pass copies or references depending on the
situation?
Yes. The compiler generates the function for the specific
situation.
So you
So when it will be fixed I will be able to write:
void foo(auto ref Vector3 v);
and it will pass copies or references depending on the situation?
On Friday, December 28, 2012 23:29:38 Namespace wrote:
> Spontaneous question: why was the behavior altered from lvalue to
> rvalue if there is still no replacement with "auto ref" and so a
> lot of code becomes invalid?
> I know of course that the change was necessary, but
Spontaneous question: why was the behavior altered from lvalue to
rvalue if there is still no replacement with "auto ref" and so a
lot of code becomes invalid?
I know of course that the change was necessary, but as long as
there is no fix I don't understand such ruthless chang
On Friday, December 28, 2012 22:21:09 Namespace wrote:
> > 2.061 is beta. I think that the chances of it having something
> > like this in it
> > are very close to zero.
> >
> > - Jonathan M Davis
>
> You know how to give a suffering hope. :D
LOL. Yeah, well. It's not like I'm going to lie about
2.061 is beta. I think that the chances of it having something
like this in it
are very close to zero.
- Jonathan M Davis
You know how to give a suffering hope. :D
On Friday, December 28, 2012 13:19:01 Namespace wrote:
> In consideration that Andrei said that the implementation of
> "auto ref" for none-template functions are relatively easy and
> that until now only the first beta of 2.061 came out: How likely
> is it that "auto re
I wrote a workaround for me: I implement it in Romulus. So for
these functions:
[code]
void foo(auto ref const Foo f) {
// do something with f
}
const(int[42]) bar(auto ref const Foo a, auto ref const Foo b)
pure nothrow {
// do something with a and b
}
const(int[42]) quatz
On Friday, 28 December 2012 at 12:47:03 UTC, Namespace wrote:
On Friday, 28 December 2012 at 12:28:01 UTC, bearophile wrote:
Namespace:
How likely is it that "auto ref" will implemented in this
release?
Walter wants to release 2.061 "soon". So maybe that's for
On Friday, 28 December 2012 at 12:28:01 UTC, bearophile wrote:
Namespace:
How likely is it that "auto ref" will implemented in this
release?
Walter wants to release 2.061 "soon". So maybe that's for the
successive (unstable?) version of the compiler.
Bye,
bear
Namespace:
How likely is it that "auto ref" will implemented in this
release?
Walter wants to release 2.061 "soon". So maybe that's for the
successive (unstable?) version of the compiler.
Bye,
bearophile
In consideration that Andrei said that the implementation of
"auto ref" for none-template functions are relatively easy and
that until now only the first beta of 2.061 came out: How likely
is it that "auto ref" will implemented in this release? Maybe an
official sta
On Wednesday, 26 December 2012 at 22:33:38 UTC, Jonathan M Davis
wrote:
On Wednesday, December 26, 2012 10:43:53 Namespace wrote:
Quick question: what is the state of things with dmd 2.061
AFAIK, it's exactly the same as it was in 2.060.
- Jonathan M Davis
I mean, when it comes out. But tha
On Wednesday, December 26, 2012 10:43:53 Namespace wrote:
> Quick question: what is the state of things with dmd 2.061
AFAIK, it's exactly the same as it was in 2.060.
- Jonathan M Davis
Quick question: what is the state of things with dmd 2.061 and I
see that right, that "auto ref" is more complicated than first
thought? :/
assed by value or if
it was a local variable inside one of those functions which was returned by
ref, then we're in trouble. And auto ref will have exactly the same problem.
The fact that you can both pass by ref screws things up. If that were illegal,
then we'd be okay, but it's not
On 12/24/12 2:46 PM, anonymous wrote:
On Monday, 24 December 2012 at 18:50:12 UTC, Jonathan M Davis wrote:
const int& i = foo(bar(min(5, 7)));
which would allow a reference to be kept around, which D disallows.
Does it?
const(int)* i = &foo(bar(min(5, 7)));
We plan to forbid that.
Andrei
On 12/24/12 1:49 PM, Jonathan M Davis wrote:
On Monday, December 24, 2012 13:45:10 Andrei Alexandrescu wrote:
The very binding of rvalues to const ref would allow that breakage. We
can't allow that to happen.
But it's only bound for the length of the statement. After that, the binding
can no l
On Monday, December 24, 2012 21:42:09 monarch_dodra wrote:
> Side question, is this legal?
>
> "int a = min(min(1,2), min(3,4));"
>
> How long do those temps last? I like this piece of code, because
> the previous had that fishy "const int&", which raises eyebrows,
> but I think this example coul
On Monday, 24 December 2012 at 19:09:35 UTC, Jonathan M Davis
wrote:
On Monday, December 24, 2012 20:03:24 monarch_dodra wrote:
Hum... Indeed, it takes by ref *and* returns by ref. Passing in
to out a const ref is *the* smoking gun. Working with D has
gotten me used to functions that take by val
On Monday, December 24, 2012 20:46:00 anonymous wrote:
> On Monday, 24 December 2012 at 18:50:12 UTC, Jonathan M Davis
>
> wrote:
> > const int& i = foo(bar(min(5, 7)));
> >
> > which would allow a reference to be kept around, which D
> > disallows.
>
> Does it?
>
> const(int)* i = &foo(bar(min
On Monday, 24 December 2012 at 18:50:12 UTC, Jonathan M Davis
wrote:
const int& i = foo(bar(min(5, 7)));
which would allow a reference to be kept around, which D
disallows.
Does it?
const(int)* i = &foo(bar(min(5, 7)));
On Monday, December 24, 2012 20:03:24 monarch_dodra wrote:
> Hum... Indeed, it takes by ref *and* returns by ref. Passing in
> to out a const ref is *the* smoking gun. Working with D has
> gotten me used to functions that take by value and return by
> value...
>
> Snap. You got me.
It wouldn't ma
On Monday, 24 December 2012 at 18:42:31 UTC, Andrei Alexandrescu
wrote:
On 12/24/12 1:05 PM, monarch_dodra wrote:
On Monday, 24 December 2012 at 17:37:54 UTC, Andrei
Alexandrescu wrote:
On 12/24/12 12:11 PM, Jonathan M Davis wrote:
On Monday, December 24, 2012 17:55:23 Minas Mina wrote:
On Sun
On Monday, December 24, 2012 19:05:32 monarch_dodra wrote:
> On Monday, 24 December 2012 at 17:37:54 UTC, Andrei Alexandrescu
> wrote:
> > An important smoking gun is C++'s min(), which is allows
> > writing unsafe code without casts.
> >
> > const int& haveANiceDay = min(4, 5);
> >
> >
> > Andr
On Monday, December 24, 2012 13:45:10 Andrei Alexandrescu wrote:
> The very binding of rvalues to const ref would allow that breakage. We
> can't allow that to happen.
But it's only bound for the length of the statement. After that, the binding
can no longer exist (as the binding was a function p
On 12/24/12 1:20 PM, Jonathan M Davis wrote:
On Monday, December 24, 2012 22:11:58 Dmitry Olshansky wrote:
12/24/2012 9:57 PM, Jonathan M Davis пишет:
On Monday, December 24, 2012 12:37:54 Andrei Alexandrescu wrote:
An important smoking gun is C++'s min(), which is allows writing unsafe
code w
On 12/24/12 12:57 PM, Jonathan M Davis wrote:
On Monday, December 24, 2012 12:37:54 Andrei Alexandrescu wrote:
An important smoking gun is C++'s min(), which is allows writing unsafe
code without casts.
const int& haveANiceDay = min(4, 5);
But what does that have to do with const& for funct
On 12/24/12 1:05 PM, monarch_dodra wrote:
On Monday, 24 December 2012 at 17:37:54 UTC, Andrei Alexandrescu wrote:
On 12/24/12 12:11 PM, Jonathan M Davis wrote:
On Monday, December 24, 2012 17:55:23 Minas Mina wrote:
On Sunday, 23 December 2012 at 23:59:55 UTC, Jonathan M Davis
wrote:
On Mond
On Monday, December 24, 2012 22:11:58 Dmitry Olshansky wrote:
> 12/24/2012 9:57 PM, Jonathan M Davis пишет:
> > On Monday, December 24, 2012 12:37:54 Andrei Alexandrescu wrote:
> >> An important smoking gun is C++'s min(), which is allows writing unsafe
> >> code without casts.
> >>
> >> const int
ave nothing to do with function parameters, and it's
the function parameters that everyone cares about.
That being said, I don't think that having const ref take rvalues is a good
solution for D given how strict its const is - rather I think that we should
figure out how to make auto ref
On Monday, 24 December 2012 at 17:37:54 UTC, Andrei Alexandrescu
wrote:
On 12/24/12 12:11 PM, Jonathan M Davis wrote:
On Monday, December 24, 2012 17:55:23 Minas Mina wrote:
On Sunday, 23 December 2012 at 23:59:55 UTC, Jonathan M Davis
wrote:
On Monday, December 24, 2012 00:48:01 Namespace wr
That being said, I don't think that having const ref take rvalues is a good
solution for D given how strict its const is - rather I think that we should
figure out how to make auto ref work for non-templated functions - but I fail
to see how making const ref accept rvalues would really cause any problems.
- Jonathan M Davis
On 12/24/12 12:11 PM, Jonathan M Davis wrote:
On Monday, December 24, 2012 17:55:23 Minas Mina wrote:
On Sunday, 23 December 2012 at 23:59:55 UTC, Jonathan M Davis
wrote:
On Monday, December 24, 2012 00:48:01 Namespace wrote:
but Andrei is dead set against
- Jonathan M Davis
Why?
He's con
On Monday, December 24, 2012 17:55:23 Minas Mina wrote:
> On Sunday, 23 December 2012 at 23:59:55 UTC, Jonathan M Davis
>
> wrote:
> > On Monday, December 24, 2012 00:48:01 Namespace wrote:
> >but Andrei is dead set against
> >
> > - Jonathan M Davis
>
> Why?
He's convinced that it's caused prob
On Sunday, 23 December 2012 at 23:59:55 UTC, Jonathan M Davis
wrote:
On Monday, December 24, 2012 00:48:01 Namespace wrote:
but Andrei is dead set against
- Jonathan M Davis
Why?
On Monday, December 24, 2012 12:16:15 Namespace wrote:
> Put another way: how long will we probably still wait for a
> solution? Yet another release, or 2? Say, 6 months or even
> longer? When it comes in the near future (ie a maximum of 1-2
> months), then it would be sufficient simply to templati
On Monday, December 24, 2012 14:01:10 Namespace wrote:
> One more thing: Which pull request is for "auto ref" for
> none-template functions?
There isn't one.
- Jonathan M Davis
One more thing: Which pull request is for "auto ref" for
none-template functions?
Put another way: how long will we probably still wait for a
solution? Yet another release, or 2? Say, 6 months or even
longer? When it comes in the near future (ie a maximum of 1-2
months), then it would be sufficient simply to templatize my
methods. But if it goes for much longer (which I stro
On Monday, December 24, 2012 09:08:09 Namespace wrote:
> Yes that's what I thought. My question was, if it's bad if now a
> lot of my functions/methods are templatized.
That would depend on what you're doing. It's a problem with classes, because
templated functions can't be virtual. With everythi
501 - 600 of 741 matches
Mail list logo
