A chat in IRC revealed a couple of possible improvements to the
development scenario in which the interface file (.di) is managed
manually and separately from the implementation file (.d).
After discussing a few ideas with Walter, the following language
improvement came about. Consider a very
On Friday, 22 July 2011 at 22:06:20 UTC, Andrei Alexandrescu
wrote:
1. The compiler shall accept method definitions outside a class.
Sorry to bump this old thread, but after having spent some time
with D I like the idea of having the ability to implement class
methods outside of the class, bu
I really like this and never never understood reason behind
automatically generated .di files, as much as difficulties with
separation of interface and implementation. If there is one thing
that prevents me to say that D module system is 100% better than
C++ - here it is. If there is something
On Sunday, 3 March 2013 at 10:47:34 UTC, Dicebot wrote:
Regarding CTFE - it is a reason to not use this layout for
generic algorithm libraries and similar stuff, but there is no
point in allowing application module code for CTFE by an
accident.
It is the virtual vs final by default argument.
On Sunday, 3 March 2013 at 11:03:55 UTC, deadalnix wrote:
On Sunday, 3 March 2013 at 10:47:34 UTC, Dicebot wrote:
Regarding CTFE - it is a reason to not use this layout for
generic algorithm libraries and similar stuff, but there is no
point in allowing application module code for CTFE by an
a
On Sunday, 3 March 2013 at 11:08:33 UTC, Dicebot wrote:
On Sunday, 3 March 2013 at 11:03:55 UTC, deadalnix wrote:
On Sunday, 3 March 2013 at 10:47:34 UTC, Dicebot wrote:
Regarding CTFE - it is a reason to not use this layout for
generic algorithm libraries and similar stuff, but there is
no po
On Sunday, 3 March 2013 at 13:19:35 UTC, deadalnix wrote:
...
Ah, beg my pardon, misunderstood you a bit. Still, difference I
am trying to point is that virtual vs final does not rely on
actual method implementation at all, while proper CTFE function
needs to be written with CTFE in mind as
On Sunday, 3 March 2013 at 13:24:39 UTC, Dicebot wrote:
On Sunday, 3 March 2013 at 13:19:35 UTC, deadalnix wrote:
...
Ah, beg my pardon, misunderstood you a bit. Still, difference I
am trying to point is that virtual vs final does not rely on
actual method implementation at all, while proper
On Friday, 22 July 2011 at 22:06:20 UTC, Andrei Alexandrescu
wrote:
A chat in IRC revealed a couple of possible improvements to the
development scenario in which the interface file (.di) is
managed manually and separately from the implementation file
(.d).
After discussing a few ideas with Wa
+1_000_000_000
Yes please!
It's near impossible to get a brief overview of a class at a glance in D!
On 3 March 2013 15:35, Andrej Mitrovic wrote:
> On Friday, 22 July 2011 at 22:06:20 UTC, Andrei Alexandrescu wrote:
>
>> 1. The compiler shall accept method definitions outside a class.
>>
>
>
On Monday, 4 March 2013 at 06:06:14 UTC, Rob T wrote:
One of the main selling points of the module system is to
prevent exactly what you are proposing, so I think there must
be a better solution.
Please explain. Main points of module system is to avoid header
compilation time hell and control
On Monday, 4 March 2013 at 06:06:14 UTC, Rob T wrote:
Manually maintaining a .di file is a bad idea for what should
be obvious reasons
No, they are not obvious at all, please explain.
On Friday, 22 July 2011 at 22:06:20 UTC, Andrei Alexandrescu
wrote:
[SNIP]
Walter is reluctantly on board with a change in this direction,
with the note that he'd just recommend interfaces for this kind
of separation. My stance in this matter is that we shouldn't
constrain without necessit
One of the main selling points of the module system is to
prevent exactly what you are proposing, so I think there must
be a better solution.
Please explain. Main points of module system is to avoid header
compilation time hell and control access. I don't how this is
relevant to the topic.
On Monday, 4 March 2013 at 06:18:35 UTC, Manu wrote:
+1_000_000_000
Yes please!
It's near impossible to get a brief overview of a class at a
glance in D!
I agree it's very handy to get an overview of a class or struct
or module interface, however I think that the IDE should deal
with thi
On 3/5/13, Rob T wrote:
> The relatively primitive IDE that I use allows me to at least
> perform function folding, which in some ways helps solve the
> problem, albeit in a poor way, but it hints that better tools can
> solve the problem rather nicely without a duplication of code.
Code folding
On Tuesday, 5 March 2013 at 00:17:03 UTC, Andrej Mitrovic wrote:
On 3/5/13, Rob T wrote:
The relatively primitive IDE that I use allows me to at least
perform function folding, which in some ways helps solve the
problem, albeit in a poor way, but it hints that better tools
can
solve the probl
3/5/13, Rob T wrote:
> In that case it would be nice to avoid most of the class name
> duplication, that's one of the things I really disliked about C++.
I guess you meant:
class A
{
class B;
}
class A.B
{
// implementation
}
Ideally both styles would be supported.
Manu:
+1_000_000_000
Yes please!
It's near impossible to get a brief overview of a class at a
glance in D!
-1 from me. It's one more step toward turning D code into a
syntax soup.
Bye,
bearophile
On Monday, 4 March 2013 at 23:24:02 UTC, Rob T wrote:
One of the main selling points of the module system is to
prevent exactly what you are proposing, so I think there must
be a better solution.
Please explain. Main points of module system is to avoid
header compilation time hell and control
On Monday, 4 March 2013 at 23:36:18 UTC, Rob T wrote:
On Monday, 4 March 2013 at 06:18:35 UTC, Manu wrote:
+1_000_000_000
Yes please!
It's near impossible to get a brief overview of a class at a
glance in D!
I agree it's very handy to get an overview of a class or struct
or module interf
On 2013-03-05 09:48, Dicebot wrote:
I can find nothing on the topic of "separation" issue down that link. In
fact I have never met a C/C++ programmer saying fact of having a
separate headers is a problem, it was a loved feature if anything.
Problem was the way it was designed, via pre-processor.
On Monday, 4 March 2013 at 06:18:35 UTC, Manu wrote:
+1_000_000_000
Yes please!
It's near impossible to get a brief overview of a class at a
glance in D!
Exactly for this reason, what about make this way at least the
recommended way, if not the single one?
What is to lose? As about what to
On 2013-03-05 13:01, eles wrote:
Exactly for this reason, what about make this way at least the
recommended way, if not the single one?
You want to break every single piece of D code that uses classes?
What is to lose? As about what to win, basically each .d file will carry
its .di file (cla
On Tuesday, 5 March 2013 at 10:41:36 UTC, Jacob Carlborg wrote:
On 2013-03-05 09:48, Dicebot wrote:
I can find nothing on the topic of "separation" issue down
that link. In
fact I have never met a C/C++ programmer saying fact of having
a
separate headers is a problem, it was a loved feature if
On Tuesday, 5 March 2013 at 12:19:17 UTC, Jacob Carlborg wrote:
The compiler will need to know the size of the class, for that
it needs to know the instance variables.
Quite an interesting problem to address, by the way. I am on the
side that it can be better addressed by providing some genera
On Tuesday, 5 March 2013 at 12:19:17 UTC, Jacob Carlborg wrote:
On 2013-03-05 13:01, eles wrote:
The compiler will need to know the size of the class, for that
it needs to know the instance variables.
Maybe, but private variables should have nothing to do w.r.t. the
behaviour of the class, in
On 2013-03-05 13:48, eles wrote:
Maybe, but private variables should have nothing to do w.r.t. the
behaviour of the class, including its behaviour w.r.t. the sizeof()
operator and so on.
What compiler does know and what the user care about are different things.
True. But how does the compiler
On Tuesday, 5 March 2013 at 14:40:57 UTC, Jacob Carlborg wrote:
On 2013-03-05 13:48, eles wrote:
True. But how does the compiler get this information if you're
using a pre compiled library and a .di file?
I imagine that a similar question was asked about the virtual
methods...
Hide that into
On Tuesday, 5 March 2013 at 12:20:15 UTC, Dicebot wrote:
On Tuesday, 5 March 2013 at 10:41:36 UTC, Jacob Carlborg wrote:
On 2013-03-05 09:48, Dicebot wrote:
I can find nothing on the topic of "separation" issue down
that link. In
fact I have never met a C/C++ programmer saying fact of
having
On Tuesday, 5 March 2013 at 12:01:54 UTC, eles wrote:
On Monday, 4 March 2013 at 06:18:35 UTC, Manu wrote:
+1_000_000_000
Yes please!
It's near impossible to get a brief overview of a class at a
glance in D!
Exactly for this reason, what about make this way at least the
recommended way, if
On Tue, Mar 05, 2013 at 06:39:07PM +0100, Rob T wrote:
> On Tuesday, 5 March 2013 at 12:01:54 UTC, eles wrote:
> >On Monday, 4 March 2013 at 06:18:35 UTC, Manu wrote:
> >>+1_000_000_000
> >>
> >>Yes please!
> >>It's near impossible to get a brief overview of a class at a
> >>glance in D!
> >
> >Exa
05-Mar-2013 21:39, Rob T пишет:
On Tuesday, 5 March 2013 at 12:01:54 UTC, eles wrote:
On Monday, 4 March 2013 at 06:18:35 UTC, Manu wrote:
+1_000_000_000
Yes please!
It's near impossible to get a brief overview of a class at a glance
in D!
Exactly for this reason, what about make this way at
On Tuesday, 5 March 2013 at 17:22:52 UTC, Rob T wrote:
Clearly there's a misunderstanding going on somewhere. For
example when I say "code duplication" you say "There is close
to zero code duplication." but from my POV there clearly is
code duplication and it is indeed significant and completel
On Tuesday, 5 March 2013 at 19:14:08 UTC, Dicebot wrote:
Do you consider necessity to duplicate method signature when
overriding in descendant to be a significant code duplication
too? Because I fail to see the difference in this two cases.
I think there is a difference. For example the comp
I curse the lack of an edit feature!
Correction of my main point:
... whatever goes in the .di should not be considered as your
"source code" because it should be auto generated from the source
(eg your .o files are not source code in the same way). If
there's ever a real reason
On Tuesday, 5 March 2013 at 18:16:41 UTC, Dmitry Olshansky wrote:
Leverage UDAs ?
Yes that's one possible method, tagging the interface with
recognized attributes that guide the generation of the .di files.
If the generation is smart enough that we can do without, even
better.
The other
On Tuesday, 5 March 2013 at 18:00:59 UTC, H. S. Teoh wrote:
[...]
I've actually seen (and fixed) a case of two C functions that
were
declared with the same name in two different libraries, and in
one
module, the wrong library was linked in, thus linking the call
to the
wrong function, causing
On Tuesday, 5 March 2013 at 19:59:13 UTC, Rob T wrote:
Perhaps then, what I think is the most significant point of all
is being missed. I can see a very clear reason why in terms of
source code, the interface and implementation must not be be
separated. Automated .di generation is a means to so
On Tuesday, 5 March 2013 at 20:40:41 UTC, Vladimir Panteleev
wrote:
Also, I don't think that we should consider that a class
declaration is the same thing as the class interface - for the
simple reason that a class declaration must also contain
private fields and methods. Having to recompile
On Tuesday, 5 March 2013 at 19:59:13 UTC, Rob T wrote:
On Tuesday, 5 March 2013 at 19:14:08 UTC, Dicebot wrote:
Do you consider necessity to duplicate method signature when
overriding in descendant to be a significant code duplication
too? Because I fail to see the difference in this two case
On Tuesday, 5 March 2013 at 20:47:11 UTC, Rob T wrote:
On Tuesday, 5 March 2013 at 20:40:41 UTC, Vladimir Panteleev
wrote:
Also, I don't think that we should consider that a class
declaration is the same thing as the class interface - for the
simple reason that a class declaration must also c
On Tuesday, 5 March 2013 at 20:40:41 UTC, Vladimir Panteleev
wrote:
On Tuesday, 5 March 2013 at 19:59:13 UTC, Rob T wrote:
Perhaps then, what I think is the most significant point of
all is being missed. I can see a very clear reason why in
terms of source code, the interface and implementation
On Tuesday, 5 March 2013 at 20:51:02 UTC, Dicebot wrote:
As far as I get spirit of this proposal, compiler should do the
very same checks and complain on mismatch between interface and
implementation. Because it knows it is his interface, contrary
to C. And there is no sane way to avoid it in t
On Tuesday, 5 March 2013 at 00:41:23 UTC, Andrej Mitrovic wrote:
3/5/13, Rob T wrote:
In that case it would be nice to avoid most of the class name
duplication, that's one of the things I really disliked about
C++.
I guess you meant:
class A
{
class B;
}
class A.B
{
// implementat
On 3/6/13, Rob T wrote:
> Actually I had meant this instead, which reduces duplication
>
> class A
> {
>
> }
>
> class A.B
> {
> // implementation
> }
I don't like this idea at all. It again makes the class unreadable
because you can't tell at a glance what it contains.
On Wednesday, 6 March 2013 at 13:44:39 UTC, Andrej Mitrovic wrote:
On 3/6/13, Rob T wrote:
Actually I had meant this instead, which reduces duplication
class A
{
}
class A.B
{
// implementation
}
I don't like this idea at all. It again makes the class
unreadable
because you can't te
On 7/22/11 5:06 PM, Andrei Alexandrescu wrote:
[snip]
I almost forgot - we should also have a means to allow a class to import
its own incomplete declaration, as follows:
// a.di
class A { private int x; int foo(); }
// a.d
import a;
class A { private int x; int foo() { return x + 1; }
The c
On Fri, 22 Jul 2011, Andrei Alexandrescu wrote:
> On 7/22/11 5:06 PM, Andrei Alexandrescu wrote:
> [snip]
>
> I almost forgot - we should also have a means to allow a class to import its
> own incomplete declaration, as follows:
>
> // a.di
> class A { private int x; int foo(); }
>
> // a.d
> i
Andrei:
> Currently, in order for a program with separately-implemented methods to
> work properly, there must be TWO different files for the same class, and
> the .di file and the .d file MUST specify the same exact field layout.
> Ironically, the .d file is forbidden from including the .di fi
On Sat, 23 Jul 2011 01:06:19 +0300, Andrei Alexandrescu
wrote:
A chat in IRC revealed a couple of possible improvements to the
development scenario in which the interface file (.di) is managed
manually and separately from the implementation file (.d).
I might be forgetting bits of our di
On 7/22/11 9:29 PM, Vladimir Panteleev wrote:
On Sat, 23 Jul 2011 01:06:19 +0300, Andrei Alexandrescu
wrote:
A chat in IRC revealed a couple of possible improvements to the
development scenario in which the interface file (.di) is managed
manually and separately from the implementation file (.
On Sat, 23 Jul 2011 05:52:12 +0300, Andrei Alexandrescu
wrote:
I don't think it's an either-or situation. For a variety of reasons,
some organizations want separate control of the "declaration" and
"definition" files. Inability to do so is a common criticism leveled
against Java and one
On 7/23/11, Andrei Alexandrescu wrote:
> Currently, in order for a program with separately-implemented methods to
> work properly, there must be TWO different files for the same class
Can we get a chat log of this discussion to figure out what is trying
to be solved here?
interface IFoo
{
in
On Saturday 23 July 2011 07:34:43 Andrej Mitrovic wrote:
> On 7/23/11, Andrei Alexandrescu wrote:
> > Currently, in order for a program with separately-implemented methods to
> > work properly, there must be TWO different files for the same class
>
> Can we get a chat log of this discussion to fi
Andrei:
> I don't think it's an either-or situation.
OK, but first it's better to work as much as possible on the automatic/compiler
side of things, and see how much far it goes. Turning .di files into
hand-written things has to be left as very last chance.
> For a variety of reasons,
> some
On 7/23/11 12:19 AM, Vladimir Panteleev wrote:
On Sat, 23 Jul 2011 05:52:12 +0300, Andrei Alexandrescu
wrote:
I don't think it's an either-or situation. For a variety of reasons,
some organizations want separate control of the "declaration" and
"definition" files. Inability to do so is a commo
On 7/23/11 12:34 AM, Andrej Mitrovic wrote:
On 7/23/11, Andrei Alexandrescu wrote:
Currently, in order for a program with separately-implemented methods to
work properly, there must be TWO different files for the same class
Can we get a chat log of this discussion to figure out what is trying
On Sat, 23 Jul 2011 17:21:26 +0300, Andrei Alexandrescu
wrote:
There are not many D large projects at the time being, and everybody who
worked on one has had problems. Large projects will come, and the
language must be prepared. This _is_ important. Of course, it can happen
only of a con
On Sat, 23 Jul 2011 17:16:28 +0300, Andrei Alexandrescu
wrote:
On 7/23/11 12:19 AM, Vladimir Panteleev wrote:
On Sat, 23 Jul 2011 05:52:12 +0300, Andrei Alexandrescu
wrote:
I don't think it's an either-or situation. For a variety of reasons,
some organizations want separate control of the
On 7/23/11 11:26 AM, Vladimir Panteleev wrote:
On Sat, 23 Jul 2011 17:21:26 +0300, Andrei Alexandrescu
wrote:
There are not many D large projects at the time being, and everybody
who worked on one has had problems. Large projects will come, and the
language must be prepared. This _is_ importan
On Sat, 23 Jul 2011 20:43:13 +0300, Andrei Alexandrescu
wrote:
One of the reasons I
ran from C++ is due to not having to maintain header files any longer.
Whatever your reasons are for manually-maintained .di files, let's not
consider them a cure-all for all large project problems.
Probably
Isn't the biggest issue of large D projects the problems with
incremental compilation (e.g.
https://bitbucket.org/h3r3tic/xfbuild/issue/7/make-incremental-building-reliable),
optlink, and the toolchain?
I'm not sure how adding another responsibility to the programmer will
help big projects.
Which
On Sat, 23 Jul 2011 21:53:30 +0300, Andrej Mitrovic
wrote:
Isn't the biggest issue of large D projects the problems with
incremental compilation (e.g.
https://bitbucket.org/h3r3tic/xfbuild/issue/7/make-incremental-building-reliable),
optlink, and the toolchain?
Yes. This is a difficult prob
On 7/23/11 1:53 PM, Andrej Mitrovic wrote:
Isn't the biggest issue of large D projects the problems with
incremental compilation (e.g.
https://bitbucket.org/h3r3tic/xfbuild/issue/7/make-incremental-building-reliable),
optlink, and the toolchain?
The proposed improvement would mark a step forwar
On Sat, 23 Jul 2011 23:16:20 +0300, Andrei Alexandrescu
wrote:
On 7/23/11 1:53 PM, Andrej Mitrovic wrote:
Isn't the biggest issue of large D projects the problems with
incremental compilation (e.g.
https://bitbucket.org/h3r3tic/xfbuild/issue/7/make-incremental-building-reliable),
optlink, an
Andrei Alexandrescu wrote:
On 7/23/11 1:53 PM, Andrej Mitrovic wrote:
Isn't the biggest issue of large D projects the problems with
incremental compilation (e.g.
https://bitbucket.org/h3r3tic/xfbuild/issue/7/make-incremental-building-reliable),
optlink, and the toolchain?
The proposed impro
On 7/23/11 4:01 PM, Vladimir Panteleev wrote:
On Sat, 23 Jul 2011 23:16:20 +0300, Andrei Alexandrescu
wrote:
On 7/23/11 1:53 PM, Andrej Mitrovic wrote:
Isn't the biggest issue of large D projects the problems with
incremental compilation (e.g.
https://bitbucket.org/h3r3tic/xfbuild/issue/7/mak
On Sun, 24 Jul 2011 00:54:57 +0300, Andrei Alexandrescu
wrote:
On 7/23/11 4:01 PM, Vladimir Panteleev wrote:
On Sat, 23 Jul 2011 23:16:20 +0300, Andrei Alexandrescu
wrote:
On 7/23/11 1:53 PM, Andrej Mitrovic wrote:
Isn't the biggest issue of large D projects the problems with
incremental
Andrei:
I am not expert on this, but it doesn't look like esoteric stuff.
> Consider:
Thank you for explaining better, with more examples. This usually helps the
discussion.
> Say the team working on A wants to "freeze" a.di without precluding work
> on A.fun().
Currently in D there is no e
On Sun, 24 Jul 2011 00:54:57 +0300, Andrei Alexandrescu
wrote:
The program prints "424344" as expected.
The problem with this setup is that it's extremely fragile, in ways that
are undetectable during compilation or runtime. For example, just
swapping a and b in the implementation file m
On 7/23/11 5:34 PM, Vladimir Panteleev wrote:
I was going to suggest something like this, but without creating the
dependency on a 3rd-party build tool. I mentioned in another thread how
DMD shouldn't touch the .di file's mtime. A better idea is to not
attempt to overwrite the file at all if the
On 7/23/11 5:39 PM, bearophile wrote:
Andrei:
I am not expert on this, but it doesn't look like esoteric stuff.
Consider:
Thank you for explaining better, with more examples. This usually
helps the discussion.
Say the team working on A wants to "freeze" a.di without precluding
work on A.f
On Sun, 24 Jul 2011 01:47:32 +0300, Andrei Alexandrescu
wrote:
and then either remove the .tmp if identical or rename it forcefully to
filename.di if different. That's a classic in code generation tools.
Not sure i got it right but how renaming it forcefully would solve this?
This must be
On Sun, 24 Jul 2011 01:39:01 +0300, bearophile
wrote:
Andrei:
I am not expert on this, but it doesn't look like esoteric stuff.
Consider:
Thank you for explaining better, with more examples. This usually helps
the discussion.
I retract my comment about this :)
The problem with this
On 7/23/11 6:02 PM, so wrote:
On Sun, 24 Jul 2011 01:47:32 +0300, Andrei Alexandrescu
wrote:
and then either remove the .tmp if identical or rename it forcefully
to filename.di if different. That's a classic in code generation tools.
Not sure i got it right but how renaming it forcefully wou
Am 24.07.2011 01:02, schrieb so:
On Sun, 24 Jul 2011 01:47:32 +0300, Andrei Alexandrescu
wrote:
and then either remove the .tmp if identical or rename it forcefully
to filename.di if different. That's a classic in code generation tools.
Not sure i got it right but how renaming it forcefully
On 7/23/11 6:10 PM, Daniel Gibson wrote:
Am 24.07.2011 01:02, schrieb so:
On Sun, 24 Jul 2011 01:47:32 +0300, Andrei Alexandrescu
wrote:
and then either remove the .tmp if identical or rename it forcefully
to filename.di if different. That's a classic in code generation tools.
Not sure i go
On Sun, 24 Jul 2011 02:10:47 +0300, Daniel Gibson
wrote:
Am 24.07.2011 01:02, schrieb so:
On Sun, 24 Jul 2011 01:47:32 +0300, Andrei Alexandrescu
wrote:
and then either remove the .tmp if identical or rename it forcefully
to filename.di if different. That's a classic in code generation to
On Sun, 24 Jul 2011 01:47:32 +0300, Andrei Alexandrescu
wrote:
Yes, neither of the above are "proper" solutions. But, unless I've lost
track of something, you're trying to justify a solid amount of work on
the compiler to implement the "proper" solution, when the above
alternatives are much s
On 7/23/2011 3:50 PM, Andrei Alexandrescu wrote:
On 7/23/11 5:39 PM, bearophile wrote:
I have suggested some fine-grained hashing. Compute a hash from a
class definition, and later quickly compare this value with a value
stored elsewhere (like automatically written in the .di file).
I discusse
On 07/23/2011 11:54 PM, Andrei Alexandrescu wrote:
The problem with this setup is that it's extremely fragile, in ways that
are undetectable during compilation or runtime. For example, just
swapping a and b in the implementation file makes the program print
"08.96566e-31344". Similar issues occur
On 7/24/11 4:31 AM, Mike Wey wrote:
On 07/23/2011 11:54 PM, Andrei Alexandrescu wrote:
The problem with this setup is that it's extremely fragile, in ways that
are undetectable during compilation or runtime. For example, just
swapping a and b in the implementation file makes the program print
"0
On 22/07/2011 23:06, Andrei Alexandrescu wrote:
I see this as a source of problems going forward, and I propose the
following changes to the language:
1. The compiler shall accept method definitions outside a class.
2. A method cannot be implemented unless it was declared with the same
signatur
On Sat, 23 Jul 2011 21:14:27 -0300, Walter Bright
wrote:
On 7/23/2011 3:50 PM, Andrei Alexandrescu wrote:
On 7/23/11 5:39 PM, bearophile wrote:
I have suggested some fine-grained hashing. Compute a hash from a
class definition, and later quickly compare this value with a value
stored elsewh
Don:
> As far as performance goes, it would seem much simpler to just
Have Walter and Andrei seen this post by Don?
Bye,
bearophile
Walter Bright Wrote:
> The only way the linker can detect mismatches is by embedding the hash into
> the
> name, i.e. more name mangling.
It's not the only way. You can keep current mangling scheme and store hashes in
another place. If the linker doesn't support hashes, everything will just wo
Andrei Alexandrescu Wrote:
> I don't think it's an either-or situation. For a variety of reasons,
> some organizations want separate control of the "declaration" and
> "definition" files. Inability to do so is a common criticism leveled
> against Java and one of the reasons for the proliferatio
Kagamin Wrote:
> Walter Bright Wrote:
>
> > The only way the linker can detect mismatches is by embedding the hash into
> > the
> > name, i.e. more name mangling.
>
> It's not the only way. You can keep current mangling scheme and store hashes
> in another place. If the linker doesn't support
On Fri, 22 Jul 2011 18:06:19 -0400, Andrei Alexandrescu
wrote:
A chat in IRC revealed a couple of possible improvements to the
development scenario in which the interface file (.di) is managed
manually and separately from the implementation file (.d).
I have mixed feelings on this propos
On 7/25/11 11:19 AM, Steven Schveighoffer wrote:
On Fri, 22 Jul 2011 18:06:19 -0400, Andrei Alexandrescu
wrote:
A chat in IRC revealed a couple of possible improvements to the
development scenario in which the interface file (.di) is managed
manually and separately from the implementation file
91 matches
Mail list logo
