On Friday, 18 January 2013 at 07:21:48 UTC, simendsjo wrote:
On Friday, 18 January 2013 at 06:45:37 UTC, Mehrdad wrote:
On Friday, 18 January 2013 at 05:41:00 UTC, Artur Skawina
wrote:
This is one of the reasons why automatic code formatting is
such a bad idea.
artur
In what language? In
On Friday, 18 January 2013 at 07:19:16 UTC, Jonathan M Davis
wrote:
On Friday, January 18, 2013 07:45:34 Mehrdad wrote:
On Friday, 18 January 2013 at 05:41:00 UTC, Artur Skawina
wrote:
This is one of the reasons why automatic code formatting is
such a bad idea.
artur
In what language?
On Friday, 18 January 2013 at 07:58:57 UTC, Artur Skawina wrote:
On 01/18/13 07:45, Mehrdad wrote:
On Friday, 18 January 2013 at 05:41:00 UTC, Artur Skawina
wrote:
This is one of the reasons why automatic code formatting is
such a bad idea.
In what language? In C# it's actually a fantastic
On Friday, 18 January 2013 at 07:58:57 UTC, Artur Skawina wrote:
On 01/18/13 07:45, Mehrdad wrote:
On Friday, 18 January 2013 at 05:41:00 UTC, Artur Skawina
wrote:
This is one of the reasons why automatic code formatting is
such a bad idea.
In what language? In C# it's actually a fantastic
On Friday, January 18, 2013 09:12:26 Mehrdad wrote:
Have you /actually/ tried this in Visual C#?
Visual C# doesn't use heuristics to do format your code... it's
not like C++ where everything is ambiguous.
I suggest you give it a try and let the auto-formatter format
your code to see what
Maybe I should invent a programming language in which color has semantic
value. And fonts. :-P
Sort of :-)
http://www.colorforth.com/primer.htm
-=mike=-
On 1/17/2013 5:59 PM, Walter Bright wrote:
But in practice, I find over and over again that carefully formatted code tends
to go hand in hand with well designed code.
I might add that trying to find the right way to format code is a non-trivial
exercise I go through all the time. It matters
On 1/17/2013 11:58 PM, Artur Skawina wrote:
Sane, but badly formatted code is much preferable to bad, but pretty code.
Offhand, I can't remember ever running across bad but pretty code.
On 2013-01-18 08:18, Jonathan M Davis wrote:
In _any_ language. Inevitably, the formatter ends up totally mangling at least
some of the lines. In my experience, any attempt to be super strict with the
formatting rules (as an automatic code formatter must be) results in ugly
code. A basic set of
On Friday, 18 January 2013 at 08:13:48 UTC, deadalnix wrote:
Believing that one code formatting will inherently be better
than what a formatted can do is very similar to the assertion
often heard that code generated by the compiler is worse than
hand written assembly or many other recurring
On 01/18/2013 09:48 AM, Walter Bright wrote:
On 1/17/2013 11:58 PM, Artur Skawina wrote:
Sane, but badly formatted code is much preferable to bad, but pretty
code.
Offhand, I can't remember ever running across bad but pretty code.
Some of the worst code I have seen has been consistently
On Friday, January 18, 2013 09:47:31 Jacob Carlborg wrote:
On 2013-01-18 08:18, Jonathan M Davis wrote:
In _any_ language. Inevitably, the formatter ends up totally mangling at
least some of the lines. In my experience, any attempt to be super strict
with the formatting rules (as an
On 01/18/13 09:48, Walter Bright wrote:
On 1/17/2013 11:58 PM, Artur Skawina wrote:
Sane, but badly formatted code is much preferable to bad, but pretty code.
Offhand, I can't remember ever running across bad but pretty code.
Which is my point. An autoformatter makes the bad code look good,
On 01/18/13 09:58, Timon Gehr wrote:
On 01/18/2013 09:48 AM, Walter Bright wrote:
On 1/17/2013 11:58 PM, Artur Skawina wrote:
Sane, but badly formatted code is much preferable to bad, but pretty
code.
Offhand, I can't remember ever running across bad but pretty code.
Some of the worst
Am 18.01.2013 10:10, schrieb Artur Skawina:
Which is my point. An autoformatter makes the bad code look good, but does
not change its quality. Hence use of such a tool as part of the std dev
process should be strongly discouraged, not encouraged.
bad code can't look good by pretty-printing -
Am 18.01.2013 10:20, schrieb dennis luehring:
so you can concentrate your analysis completely on the semantic if an a
fulltime 100% working autoformatter would be always active
another nice effect of an autoformatter would be the newcomer-style -
only the semantic is normaly total shit in the
On Friday, January 18, 2013 10:20:58 dennis luehring wrote:
Am 18.01.2013 10:10, schrieb Artur Skawina:
Which is my point. An autoformatter makes the bad code look good, but does
not change its quality. Hence use of such a tool as part of the std dev
process should be strongly discouraged,
Am 18.01.2013 10:29, schrieb Jonathan M Davis:
Formatting can have a huge effect on code legibility. There are plenty of cases
where slight formatting changes don't make that big a difference, but some
really can (e.g. where the braces go), and many small differences can add up.
For instance,
On Friday, January 18, 2013 10:45:46 dennis luehring wrote:
Am 18.01.2013 10:29, schrieb Jonathan M Davis:
Formatting can have a huge effect on code legibility. There are plenty of
cases where slight formatting changes don't make that big a difference,
but some really can (e.g. where the
On Friday, 18 January 2013 at 09:10:38 UTC, Artur Skawina wrote:
On 01/18/13 09:48, Walter Bright wrote:
On 1/17/2013 11:58 PM, Artur Skawina wrote:
Sane, but badly formatted code is much preferable to bad, but
pretty code.
Offhand, I can't remember ever running across bad but pretty
code.
On Friday, 18 January 2013 at 09:30:51 UTC, Jonathan M Davis
wrote:
On Friday, January 18, 2013 10:20:58 dennis luehring wrote:
Am 18.01.2013 10:10, schrieb Artur Skawina:
Which is my point. An autoformatter makes the bad code look
good, but does
not change its quality. Hence use of such a
On Friday, 18 January 2013 at 10:40:50 UTC, Mehrdad wrote:
On Friday, 18 January 2013 at 10:30:33 UTC, deadalnix wrote:
If you believe you know operator precedence, you are probably
wrong. And even if you are right, most other programmer don't.
They're not /that/ bad...
+ - * / % are like
On Friday, 18 January 2013 at 10:30:33 UTC, deadalnix wrote:
If you believe you know operator precedence, you are probably
wrong. And even if you are right, most other programmer don't.
They're not /that/ bad...
+ - * / % are like in math
are harder, but all you need is to recall
On Friday, January 18, 2013 11:30:32 deadalnix wrote:
If you believe you know operator precedence, you are probably
wrong. And even if you are right, most other programmer don't.
You really should know the precedence of at least the common operators. For
instance, I don't think that there's
On Thu, 2013-01-17 at 11:18 -0800, H. S. Teoh wrote:
[…]
What would *really* be nice is if we extended the current format
specifiers to be able to deal with named parameters and custom
modifiers, for example:
[…]
Isn't there a way of handling this with closure capture. Python, Groovy,
etc.
On Thu, 2013-01-17 at 17:59 -0800, Walter Bright wrote:
[…]
But in practice, I find over and over again that carefully formatted code
tends
to go hand in hand with well designed code.
Having an obsessive–compulsive side to your nature is good in these
case.
--
Russel.
On 1/18/2013 12:58 AM, Timon Gehr wrote:
On 01/18/2013 09:48 AM, Walter Bright wrote:
On 1/17/2013 11:58 PM, Artur Skawina wrote:
Sane, but badly formatted code is much preferable to bad, but pretty
code.
Offhand, I can't remember ever running across bad but pretty code.
Some of the worst
Actually it is to emulate weak references. Allocating the memory with
malloc is an easy way to have references ignored by the GC. I have
already written an improved version of std.signals. It already works,
but the template mixin frontend for easy integration into a class (with
private signal
The magic comes from the fact, that a signal has weak reference
semantics, which means if you drop all references to the target object,
it won't be kept in memory because of the connected signal, instead the
slot gets de-registered automatically.
Surprisingly a lot of people seem to be unaware
No, this would not solve the issue, except you are going to drop weak
ref semantics, which would reduce a signal to a simple array of
delegates and greatly defeats its usefulness. (To prevent memory leaks,
you would have to deregister all your objects from any signals they
might be connected to,
On Friday, 18 January 2013 at 10:49:52 UTC, Jonathan M Davis
wrote:
On Friday, January 18, 2013 11:30:32 deadalnix wrote:
If you believe you know operator precedence, you are probably
wrong. And even if you are right, most other programmer don't.
You really should know the precedence of at
On Friday, 18 January 2013 at 10:49:52 UTC, Jonathan M Davis
wrote:
You really should know the precedence of at least the common
operators. For instance, I don't think that there's much excuse
for code like
if((a == b) (c != d))
Unfortunately I've come across a few cases (and in dmd too)
On Wednesday, 26 December 2012 at 22:52:29 UTC, Jonathan M Davis
wrote:
On Wednesday, December 26, 2012 23:02:25 deadalnix wrote:
Sound like the way to go for me. But is auto ref needed in such
case ? Why not simply allow ref to behave that way ?
Because there's a very large difference
On 01/18/2013 01:13 PM, monarch_dodra wrote:
...
*Personally*, I prefer
if ((a == b) (c != d))
over
if (a == b c != d)
I *know* the precedence here, but I still find it clearer with grouping.
HOWEVER, I 100% agree that in such code, the format chosen is very very
important. Place
monarch_dodra:
As a side note, I've taken to ALWAYS placing parenthesis with
ternary operators. That thing has some nasty precedence rules...
Then please vote :-)
http://d.puremagic.com/issues/show_bug.cgi?id=8757
Bye,
bearophile
if a function's argument is const ref, what would be the problem
of allowing it to to be passed const ref lvalues + rvalues?
Hi,
I just updated to dmd 2.061 and I am very happy to see that the
segfault thrown by one of my unittests that bugged me for the
last few hours is now gone. It seemed to be a nasty bug in the
runtime which is now fixed. I am really happy that there are
people continuously updating the tools
Am Fri, 18 Jan 2013 16:45:09 +0100
schrieb Stephan stepha...@mac.com:
One brief question:
Having just updated to dmd 2.061, I see that 2.062 is released,
but it is not on the website. Is that on purpose?
2.062 hasn't been released yet. I guess you got that impression from
the changelog on
On Tuesday, 15 January 2013 at 14:07:11 UTC, monarch_dodra wrote:
On Tuesday, 15 January 2013 at 13:55:53 UTC, Timon Gehr wrote:
On 01/15/2013 11:57 AM, mist wrote:
Well, probably I am playing good vision nazi here, as 12
font size
seems HUGE to me, far beyond the comfort zone.
It's just
On Fri, 2013-01-18 at 17:52 +0100, Graham Fawcett wrote:
[…]
FWIW, Emacs doesn't out of the box. But this makes it work:
(global-set-key [M-mouse-4] 'text-scale-increase)
(global-set-key [M-mouse-5] 'text-scale-decrease)
(M- for Alt, or C- for Control.)
Graham,
I am going to count the
On 01/18/2013 08:52 AM, Graham Fawcett wrote:
I do not know of any editor that does not support ctrl + scroll to
change the font sizes on the fly.
FWIW, Emacs doesn't out of the box. But this makes it work:
(global-set-key [M-mouse-4] 'text-scale-increase)
(global-set-key [M-mouse-5]
On Tue, 15 Jan 2013 13:52:10 +0100
bearophile bearophileh...@lycos.com wrote:
In D the Range static protocol of iteration is external and
opApply is internal. Some persons have suggested to use fibers in
D to introduce a very handy yield syntax for internal iteration.
D has problems in
On Friday, 18 January 2013 at 15:50:02 UTC, Johannes Pfau wrote:
Am Fri, 18 Jan 2013 16:45:09 +0100
schrieb Stephan stepha...@mac.com:
One brief question:
Having just updated to dmd 2.061, I see that 2.062 is
released, but it is not on the website. Is that on purpose?
2.062 hasn't been
On Fri, Jan 18, 2013 at 07:21:41PM +0100, Rob T wrote:
On Friday, 18 January 2013 at 15:50:02 UTC, Johannes Pfau wrote:
Am Fri, 18 Jan 2013 16:45:09 +0100
schrieb Stephan stepha...@mac.com:
One brief question:
Having just updated to dmd 2.061, I see that 2.062 is released,
but it is not on
On 1/18/2013 3:09 AM, Russel Winder wrote:
On Thu, 2013-01-17 at 17:59 -0800, Walter Bright wrote:
[…]
But in practice, I find over and over again that carefully formatted code tends
to go hand in hand with well designed code.
Having an obsessive–compulsive side to your nature is good in
On Friday, 18 January 2013 at 18:39:43 UTC, H. S. Teoh wrote:
What OS are you using? Installing from source is actually very
easy on
Linux (and other Posix OS's).
http://wiki.dlang.org/Building_DMD
(Very easy, compared to installation of other toolchains, like
GCC,
which is a royal
On 17/01/2013 22:01, Era Scarecrow wrote:
snip
As I recall for the compilers very early on, all comments and unneeded
whitespace were simply removed before compiling, leaving you with one
very long command string. The /**/ comment syntax makes perfect sense in
this case; Later tools more
http://d.puremagic.com/issues/show_bug.cgi?id=9352
Seems like dtors are a minefield of hidden and dangerous bugs, due to
them not being used (and therefore tested) very often. :-/
T
--
Lawyer: (n.) An innocence-vending machine, the effectiveness of which
depends on how much money is inserted.
Do you know why Walter is currently working on this stuff? Is
this an optimization? If it's an optimization, do you know why it
is more important than implementing scope or an unpacking
syntax for tuples?
On Fri, Jan 18, 2013 at 11:03:12AM -0800, Walter Bright wrote:
On 1/18/2013 3:09 AM, Russel Winder wrote:
On Thu, 2013-01-17 at 17:59 -0800, Walter Bright wrote:
[…]
But in practice, I find over and over again that carefully formatted
code tends to go hand in hand with well designed code.
Note that upon further investigation, the problem seems to be
more about delegates than dtors. The delegate can point to the
wrong struct, or to locals instead of the struct... but you can
access both; it compiles, but does the wrong thing.
We're talking in the bugzilla as well as here:
On Fri, Jan 18, 2013 at 09:49:34PM +0100, Adam D. Ruppe wrote:
Note that upon further investigation, the problem seems to be more
about delegates than dtors. The delegate can point to the wrong
struct, or to locals instead of the struct... but you can access
both; it compiles, but does the
On Friday, 18 January 2013 at 20:21:47 UTC, bearophile wrote:
Also, I don't agree a lot about the fog of war theory by
Walter.
I must have missed that one, what's it about?
I think a development plan should be discussed, written down,
and then followed (and dynamically fixed, when
I'm trying to bring @cmdfile functionality to gdmd. I looked at ldc's ldmd,
and they simply use dmd's root/response.c. Could I just include it in gdc,
too?
response.c itself says:
* This source file is made available for personal use
* only. The license is in backendlicense.txt
* For any
On Friday, 18 January 2013 at 15:50:02 UTC, Johannes Pfau wrote:
Am Fri, 18 Jan 2013 16:45:09 +0100
schrieb Stephan stepha...@mac.com:
One brief question:
Having just updated to dmd 2.061, I see that 2.062 is
released, but it is not on the website. Is that on purpose?
2.062 hasn't been
On 01/17/2013 03:13 PM, Stewart Gordon wrote:
Mathematically, a curve is considered a one-dimensional object,
regardless of whether the space in which it is embedded has two, three
or more dimensions. (I'm ignoring fractals here for simplicity.) If you
consider the shape of the indented block
Me and many others consider D as consistent, free and clever
replacement for screwed(IMHO) C++. From that perspective the
current design of D already has necessary things. I would like
developers to focus on fixing issues and polishing everything
rather than trying to implement something new
On 1/18/2013 2:16 PM, Andrey wrote:
I'm now still on 2.060 release, and I was shocked when suddenly have discovered
that member visibility and access attributes just don't work! Well, 2060
release, and I can easily compile such thing:
struct MyStruct {
private int a;
}
MyStruct ms;
ms.a =
On 1/18/13 3:21 PM, bearophile wrote:
Do you know why Walter is currently working on this stuff? Is this an
optimization? If it's an optimization, do you know why it is more
important than implementing scope or an unpacking syntax for tuples?
On Friday, 18 January 2013 at 19:50:06 UTC, Stewart Gordon wrote:
On 17/01/2013 22:01, Era Scarecrow wrote:
// c example, originally isprime and main don't have
// return types, defaulting to int instead.
Does the return type of a function still default to int if
unspecified in current C,
On Fri, Jan 18, 2013 at 05:43:16PM -0500, Andrei Alexandrescu wrote:
On 1/18/13 3:21 PM, bearophile wrote:
[...]
I agree with the sentiment but let's not use oblique rhetorical
questions to drive a point.
Allow me to extend again the invitation to participate to the
development by
Am 17.01.2013 19:28, schrieb John Colvin:
On Thursday, 17 January 2013 at 10:13:12 UTC, Paulo Pinto wrote:
Although I tend to do quite some posts, I am yet to fully make use of
D, with most of my work in JVM/.NET languages and FP/C++ stuff in some
private projects.
So sadly not much I can
MyStruct ms;
ms.a = 42; //!!!
writeln(ms.a);
This is by design, not a bug. All code in a module has access
to all private members in that same module. This obviates the
need for the C++ friend declarations.
Wikipedia states:
«In general, encapsulation is one of the 4 fundamentals of OOP
On Saturday, 19 January 2013 at 00:04:24 UTC, Andrey wrote:
So how am I supposed to hide the variable inside the struct or
class?
Generally the D answer here is to put them in separate files. The
module (file) is the main D encapsulation unit rather than the
class/struct.
It isn't the same
I'm wondering whether it would make sense to do compiler
bootstrapping to speedup further development and bugfixing?
This is inspired by a recent comment from Andrei
(https://github.com/D-Programming-Language/dmd/pull/1489) (I
think we're getting closer to the point we could and should do
On Saturday, 19 January 2013 at 00:11:03 UTC, Adam D. Ruppe wrote:
On Saturday, 19 January 2013 at 00:04:24 UTC, Andrey wrote:
So how am I supposed to hide the variable inside the struct or
class?
Generally the D answer here is to put them in separate files.
The module (file) is the main D
«Actually I made up the term object-oriented, and I can tell
you I did not have C++ in mind.» Alan Key.
Kay, of course. Alan Curtis Kay. Sorry for my english. :-)
On 1/18/2013 4:55 PM, Andrey wrote:
Are nested classes quite more perfectly suited for this? In my containers I
implement iterator interface using nested class. Then I can easily construct
mycontainer.new Iterator and have (should have by theory) access to protected
(not private) members. Also I
On Saturday, 7 January 2012 at 14:05:57 UTC, Jacob Carlborg wrote:
On 2012-01-07 10:31, Trass3r wrote:
On Friday, 6 January 2012 at 23:48:31 UTC, Jacob Carlborg
wrote:
On 2012-01-06 21:51, Trass3r wrote:
The only proper solution is using something like clang to
write a C++-D
converter.
First
On 01/18/2013 06:59 PM, Nick Sabalausky wrote:
tl;dr: D's input ranges are much more awkward to create than they
actually NEED to be, but the existing workarounds all have big problems.
...
My shot at it: http://dpaste.dzfl.pl/baa538af
(Does not work with 2.061)
This all falls apart once you decide you need friend access.
I haven't seen such situations yet. According to OOP concept they
must be very rare, so I tend to consider them more of
architecture and logic mistake (and C++ is one big architecture
and logic frankenstein).
Once again, in D you
On 01/19/2013 01:04 AM, Andrey wrote:
MyStruct ms;
ms.a = 42; //!!!
writeln(ms.a);
This is by design, not a bug. All code in a module has access to all
private members in that same module. This obviates the need for the
C++ friend declarations.
Wikipedia states:
«In general, encapsulation
On 1/18/2013 6:50 PM, Andrey wrote:
And for that reason we have a simple helper friend in C++.
C++ friends are quite complex and are a giant pain. D's method of everything in
a module being implicitly a friend has been working very well for 10 years now.
On Saturday, 19 January 2013 at 03:40:35 UTC, Walter Bright wrote:
On 1/18/2013 6:50 PM, Andrey wrote:
And for that reason we have a simple helper friend in C++.
C++ friends are quite complex and are a giant pain. D's method
of everything in a module being implicitly a friend has been
That is also the way to go IMO.
snip
This isn't directed at you, or any other poster for that matter
(I am to technically inept to figure out how to post to the
thread other than using the 'reply' feature)...
Anyway, just wanted to say that this thread got off topic in an
awful hurry.
snip
Anyway, just wanted to say that this thread got off topic in an
awful hurry.
It sort of funny that the thread started off with a complaint
about Walters lack of focus and quickly got off topic. Maybe
lack of focus is a common attribute of people interested in D.
I suggested that D be
Here is a helpful discussion on stack overflow about whether friend in
C++ breaks encapsulation:
http://stackoverflow.com/questions/1093618/how-does-the-friend-keyword-class-function-break-encapsulation-in-c
Also an article on encapsulation by Scott Meyers:
On Saturday, 19 January 2013 at 00:11:03 UTC, Adam D. Ruppe wrote:
On Saturday, 19 January 2013 at 00:04:24 UTC, Andrey wrote:
So how am I supposed to hide the variable inside the struct or
class?
I'm sure friend explodes the basics of OOP encapsulation
mechanics.
On Friday, 18 January 2013 at 07:34:35 UTC, Jacob Carlborg wrote:
You cannot both have CTFE/inlining/templates and hide the
source code. It's the same as in C++.
Yes I am aware of that limitation, nothing can be done except
lose the flexibility of templates and so forth, or keep it and
On 18/01/2013 08:09, Rob T wrote:
On Friday, 18 January 2013 at 07:34:35 UTC, Jacob Carlborg wrote:
You cannot both have CTFE/inlining/templates and hide the source code.
It's the same as in C++.
Yes I am aware of that limitation, nothing can be done except lose the
flexibility of templates
On 2013-01-18 09:09, Rob T wrote:
I have not yet seen examples or documentation explaining how to separate
interface and implementation from a class or struct. Are you sure this
can be done?
Yes, it's supposed to work. Just create a class as you normally would
and compile it as a library.
Despite the danger that this annoy you probably:
What about pull 1019
(https://github.com/D-Programming-Language/dmd/pull/1019)? I'm
still quite new with Git so I do not know exactly what 1 Fail, 9
Pending means (and why it stands there so long) and how current
the merge determination is.
But
On 2013-01-18 14:07, Namespace wrote:
Despite the danger that this annoy you probably:
What about pull 1019
(https://github.com/D-Programming-Language/dmd/pull/1019)? I'm still
quite new with Git so I do not know exactly what 1 Fail, 9 Pending
means (and why it stands there so long)
It means
On Friday, 18 January 2013 at 13:13:03 UTC, Jacob Carlborg wrote:
On 2013-01-18 14:07, Namespace wrote:
Despite the danger that this annoy you probably:
What about pull 1019
(https://github.com/D-Programming-Language/dmd/pull/1019)? I'm
still
quite new with Git so I do not know exactly what 1
Am Fri, 18 Jan 2013 01:07:05 + (UTC)
schrieb Justin Whear jus...@economicmodeling.com:
You can use extern(D) or simply extern; this is described here:
http://dlang.org/attribute.html#linkage
Justin
BTW: I wonder how export should be used? It seems like it
currently does nothing
18-Jan-2013 01:49, Era Scarecrow пишет:
On Thursday, 17 January 2013 at 19:36:34 UTC, Dmitry Olshansky wrote:
I'm thinking that a opSlice of stack-allocated must be @system and a
heap allocated can be @safe.
That's just a small part of the problem. With the new design, 90% of
it can be
Is there a way to use a function from a static D library without importing
their D sources nor their DI interface?
--
Jordi Sayol
On Friday, 18 January 2013 at 17:02:51 UTC, Jordi Sayol wrote:
Is there a way to use a function from a static D library
without importing their D sources nor their DI interface?
lib.d:
extern(C) void printf(const char*, ...);
void foo() {
printf(%s.ptr, hi.ptr);
}
test.d:
On Friday, 18 January 2013 at 17:02:51 UTC, Jordi Sayol wrote:
Is there a way to use a function from a static D library
without importing their D sources nor their DI interface?
Yes you should be able to do it, but not everything can be
imported without the source code, for example function
On Friday, 18 January 2013 at 04:46:46 UTC, Andrej Mitrovic wrote:
On 1/18/13, Rob T al...@ucora.com wrote:
however I read somewhere that it pretty much does nothing but
strip out the comments because it needs the full source code
for
a inlining, CTFE, and templates.
There was a recent pull
On Friday, 18 January 2013 at 17:47:42 UTC, nazriel wrote:
On Friday, 18 January 2013 at 17:02:51 UTC, Jordi Sayol wrote:
Is there a way to use a function from a static D library
without importing their D sources nor their DI interface?
lib.d:
extern(C) void printf(const char*, ...);
void
On 1/18/13, nazriel s...@dzfl.pl wrote:
extern(C) void _D3lib3fooFZv();
void main() {
_D3lib3fooFZv();
}
That's a *terrible* idea, you are calling a D function using the C
convention, you're going to have all sorts of problems. extern(D) is
not just used for mangling, it's also used
On Friday, 18 January 2013 at 18:10:35 UTC, Maxim Fomin wrote:
On Friday, 18 January 2013 at 17:47:42 UTC, nazriel wrote:
On Friday, 18 January 2013 at 17:02:51 UTC, Jordi Sayol wrote:
Is there a way to use a function from a static D library
without importing their D sources nor their DI
Am Fri, 18 Jan 2013 18:47:41 +0100
schrieb nazriel s...@dzfl.pl:
lib.d:
void foo() {
printf(%s.ptr, hi.ptr);
}
test.d:
extern(C) void _D3lib3fooFZv();
I think this is dangerous, there's no guarantee that extern(D) equals
extern(C).
How to handle name
mangling?
Maybe
Am Fri, 18 Jan 2013 19:17:33 +0100
schrieb nazriel s...@dzfl.pl:
[...]
Nice!
This should be mentioned at Language Reference, so it won't get
lost.
Isn't this documented? I thought it was well known that you can mark D
functions as extern(C). It's needed when implementing callback
On Friday, 18 January 2013 at 18:18:07 UTC, Andrej Mitrovic wrote:
On 1/18/13, nazriel s...@dzfl.pl wrote:
extern(C) void _D3lib3fooFZv();
void main() {
_D3lib3fooFZv();
}
That's a *terrible* idea, you are calling a D function using
the C
convention, you're going to have all sorts
On Friday, 18 January 2013 at 18:23:03 UTC, Johannes Pfau wrote:
Am Fri, 18 Jan 2013 19:17:33 +0100
schrieb nazriel s...@dzfl.pl:
[...]
Nice!
This should be mentioned at Language Reference, so it won't
get lost.
Isn't this documented? I thought it was well known that you can
mark D
Al 18/01/13 18:47, En/na nazriel ha escrit:
On Friday, 18 January 2013 at 17:02:51 UTC, Jordi Sayol wrote:
Is there a way to use a function from a static D library without importing
their D sources nor their DI interface?
lib.d:
extern(C) void printf(const char*, ...);
void foo() {
On Friday, 18 January 2013 at 18:23:57 UTC, nazriel wrote:
On Friday, 18 January 2013 at 18:18:07 UTC, Andrej Mitrovic
wrote:
On 1/18/13, nazriel s...@dzfl.pl wrote:
extern(C) void _D3lib3fooFZv();
void main() {
_D3lib3fooFZv();
}
That's a *terrible* idea, you are calling a D
Ok, thanks.
But nobody can tell me when and if the pull is merged, right?
I think many users here would be pleased if someone could say
something to this pull.
1 - 100 of 148 matches
Mail list logo
