On 25/07/14 08:44, Jonathan M Davis wrote:
So, in the case where opCmp was defined but not opEquals, instead of
using the normal, built-in opEquals (which should already be equivalent
to lhs.opCmp(rhs) == 0), we're going to make the compiler generate
opEquals as lhs.opCmp(rhs) == 0? That's a
On 25/07/14 08:31, Jonathan M Davis wrote:
Exactly. The only reason that switching from using lhs.opCmp(rhs) == 0
to opEquals would break code is if a type does not define them such that
they're equivalent, which would mean that opEquals and/or opCmp was
defined in a buggy manner. So, the only
On 25/07/14 08:50, Walter Bright wrote:
Yes, that's why it's hard to see that it would break existing code,
unless that existing code had a bug in it that was worked around in some
peculiar way.
If the type was only used as an AA key and never checked for equivalent
then it worked correctly
On 25/07/14 09:37, Brian Schott wrote:
On the other hand, not having to re-implement trivial functions that you
need all the time is a form of usefulness.
I'm arguing that NullLogger is not something that's needed all the time.
--
/Jacob Carlborg
On 25/07/14 10:55, Walter Bright wrote:
Then we'll just get another bug report from AAs behaving differently
from ==.
No, not as long as it's not used.
--
/Jacob Carlborg
On 25/07/14 10:48, Walter Bright wrote:
Putting it simply,
1. == uses opEquals. If you don't supply opEquals, the compiler will
make one for you.
2. AAs use ==. See rule 1.
Easy to understand, easy to explain, easy to document.
It's very hard to use D when it constantly changes and breaks
On 25/07/14 12:07, Jonathan M Davis wrote:
The compiler _never_ defines opCmp for you. You have to do that
yourself. So, what you're suggesting would force people to define
opEquals just because they defined opCmp unless they wanted to take a
performance hit. And once you define opEquals, you
On 25/07/14 11:46, Jonathan M Davis wrote:
Code that worked perfectly fine before is now slower, because it's using
opCmp for opEquals when it wasn't before.
Who says opCmp need to be slower than opEquals.
Even worse, if you define
opEquals, you're then forced to define toHash, which is
On 25/07/14 12:39, Jonathan M Davis wrote:
But regardless of whether the efficiency cost is large, you're talking
about incurring it just to fix the code of folks who couldn't be
bothered to make sure that opEquals and lhs.opCmp(rhs) == 0 were
equivalent. You'd be punishing correct code
On 25/07/14 12:09, Jonathan M Davis wrote:
The _only_ code that would break would be code that's _already_ broken -
code that defines opCmp in a way that's inconsistent with the default
opEquals and then doesn't define opEquals. I see no reason to worry
about making sure that we don't break
On 25/07/14 11:37, Walter Bright wrote:
We went through the likely code breakage from this in this thread, and
it's hard to see any non-broken code breaking. It will also fix
regression https://issues.dlang.org/show_bug.cgi?id=13179 and stop that
breakage.
So opEquals will not be required to
On 2014-07-25 15:01, francesco cattoglio wrote:
fmin is trivial as well, is not used all the time, yet is in the
standard library. Sometime trivial stuff is still good to have.
I'm not saying it bad to have trivial stuff in the standard library. I
just don't see how NullLogger is useful. But
On 2014-07-25 14:52, Dicebot wrote:
That is interesting clash of attitude to standard library :) In my
opinion it is quite the opposite - standard library is here to ensure
primarily that all trivial things are done in a same way in all
projects. Anything more complicated can be packaged as a
On 2014-07-25 15:51, H. S. Teoh via Digitalmars-d wrote:
AA's don't care about keys being orderable, all they care about is that
keys should have a hash value, and be comparable. It was a mistake to
use opCmp for AA keys in the first place. We're now fixing this mistake.
I'm responding to
On 2014-07-25 20:56, Jonathan M Davis wrote:
opEquals will now be used for AA keys, not opCmp.
Well, yes. But that was not the case when the code was written. In that
case it was to correct to defined opCmp.
That's why git master
generates errors when you have a struct which defines opCmp
On Friday, 25 July 2014 at 22:15:15 UTC, Andrei Alexandrescu
wrote:
We've just open-sourced another D project at Facebook (just a
developer beta), an ODBC driver for the Presto database engine:
https://github.com/prestodb/presto-odbc.
The Windows version works well now, and Mark Isaacson
On Sunday, 3 August 2014 at 15:28:43 UTC, Manu via Digitalmars-d
wrote:
I'm trying to make better use of scope guards, but I find
myself belting
out try/catch statements almost everywhere.
I'm rather disappointed, because scope guards are advertised to
offer the
promise of eliminating
On Monday, 4 August 2014 at 04:09:07 UTC, Manu via Digitalmars-d
wrote:
Almost all exceptions I throw are in relation to bad input
data, and they
are to be caught at a slightly higher level of input
processing. My code
has become try/catch-tastic, and I really don't like looking at
it.
Why
On Sunday, 3 August 2014 at 17:19:04 UTC, Sean Kelly wrote:
Is there support for output? I see the makeArray and
makeObject routines... Ideally, there should be a way to
serialize JSON against an OutputRange with optional formatting.
I think it should only provide very primitive functions
On Sunday, 3 August 2014 at 18:44:37 UTC, Dicebot wrote:
Before going this route one needs to have a good vision how it
may interact with imaginary std.serialization to avoid later
deprecation.
I suggest only provide functions for serializing primitive types.
A separate serialization
On Sunday, 3 August 2014 at 20:40:47 UTC, Sean Kelly wrote:
This is tricky with a range. With an event-based parser I'd
have events for object and array begin / end, but with a range
you end up having an element that's a token, which is pretty
weird.
Have a look at Token.Kind in the top of
On Sunday, 3 August 2014 at 07:16:05 UTC, Andrei Alexandrescu
wrote:
We need a better json library at Facebook. I'd discussed with
Sönke the possibility of taking vibe.d's json to std but he
said it needs some more work. So I took std.jgrandson to proof
of concept state and hence ready for
On Monday, 4 August 2014 at 10:01:42 UTC, Manu via Digitalmars-d
wrote:
catch can't appear on its own though... or are you suggesting
that it
should be possible?
Yes, that's what I'm suggesting.
Yeah, that. Except I think scope(failure, Exception e) also has
a place;
there are instances
On Monday, 4 August 2014 at 14:02:22 UTC, Dicebot wrote:
Do you consider structs primitive types? This is probably #1
use case for JSON conversion.
No, only types that cannot be broken down in to smaller pieces,
i.e. integral, floating points, bool and strings.
On Monday, 4 August 2014 at 09:10:46 UTC, Daniel Murphy wrote:
This is exactly what I need in most projects. Basic types,
arrays, AAs, and structs are usually enough.
I was more thinking only types that cannot be broken down in to
smaller pieces, i.e. integer, floating point, bool and
On 2014-08-04 16:55, Dicebot wrote:
That is exactly the problem - if `structToJson` won't be provided,
complaints are inevitable, it is too basic feature to wait for
std.serialization :(
Hmm, yeah, that's a problem.
Simplified serialization algorithm:
1) write (cast(void*)
On 2014-08-04 18:55, Andrei Alexandrescu wrote:
What would be the places?
That's why it's easier with Github ;) I can comment directly on a line.
I just had a quick look but _true, _false and _null in Token.Kind.
If I recall correctly we add an underscore as a suffix for symbols with
the
On 2014-07-26 14:11, Kagamin wrote:
Like this?
http://wiki.dlang.org/LDC-specific_language_changes#LDC_global_crt_ctor_and_LDC_global_crt_dtor
I would guess so.
--
/Jacob Carlborg
On 2014-08-05 14:40, Daniel Murphy wrote:
I guess I meant types that have an obvious mapping to json types.
int/long - json integer
bool - json bool
string - json string
float/real - json float (close enough)
T[] - json array
T[string] - json object
struct - json object
This is usually enough
On 2014-08-05 11:54, Sönke Ludwig wrote:
I think we could also simply keep the generic default recursive descent
behavior, but allow serializers to customize the process using some kind
of trait. This could even be added later in a backwards compatible
fashion if necessary.
I have a very
On 2014-08-04 11:07, Daniel Murphy wrote:
But really, doesn't everyone?
Sure, but not to the point where I would go back to C style error handling.
--
/Jacob Carlborg
On 2014-08-04 12:09, Manu via Digitalmars-d wrote:
I hate pointless brace and indentation spam, I feel it severely damages
the readability of my code. And try/catch has a natural tendency to
produce horrid nested structures.
I would rather C-style error reporting via sentinel values and 'if()'
On 2014-08-05 01:10, Sean Kelly wrote:
The easiest thing would be to provide a thread-local reference to
the currently in-flight exception. Then you could do whatever
checking you wanted to inside the scope block.
That's quite clever. Can we do that?
--
/Jacob Carlborg
On 2014-08-05 12:38, Manu via Digitalmars-d wrote:
'scope' class destruction is deterministic though right?
http://dlang.org/statement.html : there are examples of stuff like this:
scope Foo f =new Foo();
Yes, but you don't know in the destructor of Foo if it was used in a
scope
On 2014-08-05 18:42, Daniel Murphy wrote:
Chances are tying it to a future
generic serialization library is going to make it take longer.
Yeah, that's the problem. But where do you draw the line. Should arrays
of structs be supported?
--
/Jacob Carlborg
On 2014-07-30 14:51, w0rp wrote:
I think it's important to ship with a linker without requiring any
further installation.
Just for the record. Currently, Windows in the only platform where this
is true.
--
/Jacob Carlborg
On 2014-08-06 13:36, Daniel Murphy wrote:
Yes. Allow T, where T is any of
int, float, long, etc
bool
struct { T... }
T[string]
T[]
BTW, why not classes? It's basically the same implementation as for structs.
--
/Jacob Carlborg
On 2014-08-03 19:59, Artur Skawina via Digitalmars-d wrote:
No; the advantage of using these magic UDA is that they don't need
to be vendor-specific. IOW one can define inline as the GDC magic
attribute, or nothing. Maybe even some other compiler can support it.
And the source code remains
On 14/08/14 21:12, bearophile wrote:
Elsewhere I have suggested to add to D an optional struct (and tuple)
method now named onMatch, similar to the unapply method of Scala
language, that is also called by the switch case to perform a basic
version of pattern matching.
It can be implemented as
On 15/08/14 04:46, H. S. Teoh via Digitalmars-d wrote:
I agree that's a cool thing to have, but that still doesn't address the
core issue, that is, given a generic type T, of which you have no
further information about how its concrete values might behave, how do
you write a unittest that
On 2014-08-16 01:33, Mike wrote:
Sounds like a worthwhile impromement to me.
Sounds like a breaking change to me. Which will include the usual complains.
--
/Jacob Carlborg
On 2014-08-15 23:02, H. S. Teoh via Digitalmars-d wrote:
What would interfacing with C++ templates be like in practice? C++
templates have SFINAE, but D doesn't; so how would one translate a set
of C++ templates that rely on SFINAE to the equivalent D declarations
(inside extern(C++) blocks)?
On 17/08/14 20:19, Joakim wrote:
Thanks to Jacob Carlborg and the excellent work he's done on dstep, for
allowing me to automate translation of most of those headers and save a
bunch of time. :) I'll submit the repo to deimos or dub, whichever is
the better place to put it.
Cool :) I
On 18/08/14 20:48, Andrei Alexandrescu wrote:
I get 117 with that. What gives? Do we have people with multiple emails,
or identical names?
Hara Kenji seems to be using two usernames/email address k-hara and
9rnsr.
--
/Jacob Carlborg
On 2014-08-19 16:11, Andrei Alexandrescu wrote:
Neither is listed at
https://github.com/D-Programming-Language/phobos/graphs/contributors. --
Andrei
9rnsr is listed for DMD [1], with very few commits. A wild guess: that
page only tracks Github accounts. Hara Kenji is doing all his work with
On 2014-08-19 18:07, Dicebot wrote:
This matches my knowledge and observations. It only counts actual
commits authors which have GitHub accounts with same e-mails as defined
in commit metadata.
It's easy to register an additional email address and suddenly k-hara
will be recognized as the
On 2014-08-19 18:31, Alex wrote:
Hi Everyone,
Is there a list of functions and data structures, the D-Compiler would
expect from a custom runtime?
Here's a list [1]. It's probably not complete but it's a start. It's
best to look at the source code of the existing runtime.
[1]
On 20/08/14 00:25, deadalnix wrote:
Hi all, I'm posting here because I think we have a serious
problem. Long story short, Apple updated its linker, and many
binaries produced by DMD do not link anymore.
You can find a sample code here:
https://issues.dlang.org/show_bug.cgi?id=12754
All version
Looking at the documentation for std.algorithm and the std.logger
(currently under review) [1] I think the function signatures look
absolutely horrible. The functions std.algorithm in have complicated
template constraints and in std.logger there are many functions with
default arguments like
On 20/08/14 10:20, Paulo Pinto wrote:
I think this is important when discussion about language complexity, as
the discussions in the Scala community show.
Scala has simplified signatures for a few methods as well, see:
On 20/08/14 09:35, bearophile wrote:
Another possible improvement is to add popups that show the complete
type when the mouse is over the name of a type or value.
You can see that used in this F# code:
http://tomasp.net/blog/2014/puzzling-fsharp/
And in this near-Haskell code:
On 2014-08-20 16:59, H. S. Teoh via Digitalmars-d wrote:
No, I want to see all parameters in the docs.
If it was unclear, all parameters will be available in the full
signature that is available in the generated docs as well.
I disagree.
See above
If we had more control over the
On 20/08/14 18:34, H. S. Teoh via Digitalmars-d wrote:
Sorry, I didn't make myself clear. What I meant was that ddoc will
generate the above structure, so that user ddoc templates can customize
the appearance of each element in the declaration. You don't actually
write any of these macros
On 21/08/14 08:35, Joakim wrote:
C++ support keeps coming up these days, with Andrei continually
stressing it as something to work on. How hard would it to be to write
a C++-D translator, to allow people to translate C++ libraries to D?
I've been using tools like DStep and looking at
On 21/08/14 06:59, Hubert wrote:
https://www.dropbox.com/s/oicmwoboku136jq/dlang_test_redesign.png
I kind of like the structure of the page, but not the colors.
--
/Jacob Carlborg
On 21/08/14 20:07, Brad Anderson wrote:
On Thursday, 21 August 2014 at 17:55:19 UTC, Timothee Cour via
Digitalmars-d wrote:
http://dlang.org/cpptod.html#raii mentions scope class and scope
variables,
which seem deprecated (http://dlang.org/deprecate.html)
On 2014-08-22 10:37, Daniel Murphy wrote:
It's listed as 'future', so it's not actually deprecated.
Everyone is treating it as deprecated.
While DDMD
does currently use it extensively, it can be replaced if necessary. I'd
much rather see it reinstated along with proper escape checking.
On 2014-08-22 00:35, Sönke Ludwig wrote:
Following up on the recent std.jgrandson thread [1], I've picked up
the work (a lot earlier than anticipated) and finished a first version
of a loose blend of said std.jgrandson, vibe.data.json and some changes
that I had planned for vibe.data.json for a
On 2014-08-24 09:26, Messenger wrote:
Use the source, Luke!
Hehe :)
--
/Jacob Carlborg
On 25/08/14 08:18, Brost wrote:
Is D different in this regard ?
In addition to being ABI compatible with C, D is also compatible with
C++ [1]. D recently got support for C++ templates and namespaces.
Hopefully it will get support for Objective-C as well, in the not too
far away future.
On 25/08/14 22:34, Marc Schütz schue...@gmx.net wrote:
Take Ruby as an example: Ruby is a scripting language that cannot be
compiled to native code (though it can be JITted).
Both MacRuby [1] and RubyMotion [2] supports ahead of time compilation.
I'm pretty sure Apple doesn't allow anything
On 25/08/14 21:49, simendsjo wrote:
So ldc can remove quite a substantial amount of code in some cases.
It's because the latest release of LDC has the --gc-sections falg
enabled by default.
--
/Jacob Carlborg
On 26/08/14 13:40, Marc Schütz schue...@gmx.net wrote:
I've heard about them, but I don't know any details. Anyway, the way
Ruby works, they either need to restrict the language, include a full
interpreter/jitter, or at most they could only translate it to a very
abstract level. Like for an
On 27/08/14 07:40, eles wrote:
But we could imagine a declarative layer in/over D or a module directed
at it. You know, one language to rule them all (including declarative
languages, just as the functional ones...).
You could probably come quite far with UDA's or similar.
--
/Jacob Carlborg
On 24/08/14 15:14, Marc Schütz schue...@gmx.net wrote:
In the Opportunities for D thread, Walter again mentioned the topics
ref counting, GC, uniqueness, and borrowing, from which a lively
discussion developed [1]. I took this thread as an opportunity to write
down some ideas about these topics.
On 2014-08-28 13:49, Chris wrote:
Is there any chance this could be made available on the server?
DMD 2.065.0 is available here: ftp://ftp.digitalmars.com/dmd.2.065.0.zip
--
/Jacob Carlborg
On 2014-08-28 11:16, Marc Schütz schue...@gmx.net wrote:
I'd rather introduce a special method that is called only by the GC.
Cleaning up after an object that goes out of scope has always been the
task of the regular destructor, it's undeterministic destruction that
needs special treatment.
I
On 28/08/14 21:27, Marc Schütz schue...@gmx.net wrote:
The other way round would be safer: A destructor automatically calls as
its first step a finalizer (let's use that term for a destructor called
by the GC) if present, but a finalizer doesn't call the destructor.
Remember that the things
On 29/08/14 04:21, Andrei Alexandrescu wrote:
Dear community, are you ready for this?
https://issues.dlang.org/show_bug.cgi?id=2834
https://github.com/D-Programming-Language/druntime/pull/864
Does this has the same issues as destructors for classes, i.e. not
guaranteed to run?
--
/Jacob
On 29/08/14 12:53, Marc Schütz schue...@gmx.net wrote:
Jacob Carlborg just recently brought this up in another thread. Isn't it
kind of consensus that calling a destructor from the GC is not a good
idea because of the restrictions that apply in this context? Andrei even
wanted to deprecate
On 01/09/14 02:10, Abe wrote:
Thanks, Adam.
Is this roughly the same on all relevant platforms for DMD?
I was thinking [hoping?] that maybe this was a problem vis-a-vis the Mac
OS X linker, i.e. a situation such that the linker isn`t dropping
anything from the referenced libraries, even when
On 01/09/14 01:57, Abe wrote:
… that is, the problem whereby DMD produces _huge_ executables for tiny
programs.
Yes, dynamic libraries are currently only properly supported on Linux.
--
/Jacob Carlborg
On 01/09/14 03:20, Abe wrote:
Reading ./src/druntime/src/rt/dylib_fixes.c seems to indicate that DMD
has at least _some_ support for Mac OS X dynamic libraries, but IDK how
much and under which circumstances.
Dynamic libraries are not yet properly supported.
If anybody with a Windows
On 01/09/14 01:51, Abe wrote:
The question: why is Hello World so frickin` huge?!?
The runtime and standard library is statically linked, compared to C
where it's dynamically linked. Also unnecessary symbols are not
stripped. DMD on OS X doesn't currently support dynamic libraries. LDC
has
On 2014-09-01 19:28, Dicebot wrote:
This was supposed to be enabled by default in 0.14.0 (it is exactly what
ld --gc-sections does). Probably some issue with ld argument wrapper for
whatever lines OSX uses?
It only works for Linux.
--
/Jacob Carlborg
On 2014-09-01 19:23, Dan Olson wrote:
When I try -dead_strip with DMD, I get runtime SEGV with simple writeln
hello world :-(
It will probably clean out TLS, module info and similar data which is
not reachable from the main function.
--
/Jacob Carlborg
On 01/09/14 20:33, Dicebot wrote:
Any reason why it can't work for OSX in a same way? Assuming LDC does
emit ModuleInfo Co sections the same way it does on Linux, using OSX
specific alternative to --gc-sections should just work.
It does not emit these sections the same way, at least not on
On 30/08/14 16:37, Dicebot wrote:
No it is not. GitHub is an intrusive closed ecosystem and it is
legitimate concern for anyone caring about the open internet.
There are alternatives. Gitlab for example. It's open source but it has
commercial interests as well. It's the best alternative I've
On 04/09/14 23:46, Nick Sabalausky wrote:
It sounds great, but TBH I'm a little disappointed with it: Without
horizontal scrolling, it's still a huge step backwards from a dedicated
native diff program like Beyond Compare and such. At least they're
improving though.
Gitlab has had split view
On 05/09/14 09:51, Nick Sabalausky wrote:
Hmm, checking out the demo server, that side-by-side diff still doesn't
really compare to the non-HTML ones I've used. On the real ones, the
horizontal scrollbar is never hidden below the bottom of the window, all
the way down at the bottom of the
On 2014-09-05 20:20, Dicebot wrote:
Unfortunately I have had to pause it a bit
Is it due to the garbage collector running :)
--
/Jacob Carlborg
On 2014-09-06 17:51, Russel Winder via Digitalmars-d wrote:
Ariovistus originally reported Issue 2940 against SCons and the D
toolset (http://scons.tigris.org/issues/show_bug.cgi?id=2940). The gdc
tool uses -Wl,-rpath=. in the gdc command to set the rpath for gdc.
The dmd tool uses -L-rpath=. in
On 2014-09-06 17:51, Russel Winder via Digitalmars-d wrote:
Is there an OSX user out there having no problem with dmd and dynamic
libraries I can prevail upon to give me a hand with this?
Note that dynamic libraries don't work properly on OS X.
--
/Jacob Carlborg
On 07/09/14 22:23, Andrei Alexandrescu wrote:
What are the issues? -- Andrei
The usual: module info, exception handling tables, TLS and so on. Same
problem Linux used to have. It has only be solved for Linux.
--
/Jacob Carlborg
On 09/09/14 02:56, Dicebot wrote:
Yeah those definitely look more interesting - as far as I can see
subtree is bound to a branch and not to specific commit hash.
Since Git 1.8.2 you can bound a submodule to a branch.
--
/Jacob Carlborg
On 09/09/14 06:56, Brad Roberts via Digitalmars-d wrote:
I believe that some vm images were created by someone that Andrew used,
and that's likely the best course to continue right now, imho.
I think Martin Nowak created the VM images using Vagrant. This file [1]
contains some Vagrant
On 10/09/14 10:47, Robert burner Schadek wrote:
But
void fun(int l = __LINE__, A...)(A...); cannot be replaced by
void fun(A...)(A..., int l = __LINE__);
Could we modify the compiler to allow that? Just for the special
identifiers __LINE__, __FILE__ and similar. It wouldn't be possible to
I'm working on the D/Objective-C integration. There's a bunch of new
tests added that should only be run on OS X. Currently these are in a
separate test suite. How should these tests be handled? Should they stay
in a separate test suite, exclude the files from the current makefile
somehow or
On 10/09/14 15:19, Daniel Murphy wrote:
I'd say just disable them in the makefile for all other platforms, if
they don't need a custom script.
Some of the need to compile Objective-C code.
--
/Jacob Carlborg
On 2014-09-10 17:09, Daniel Murphy wrote:
Are you planning to do that with shell scripts or by adding a feature to
d_do_test?
Currently this is done using REQUIRED_ARGS and $(), something like this:
// REQUIRED_ARGS: objc.o $(gcc -m$MODEL objc.m -c -o objc.o)
You could fairly easily add
On 10/09/14 14:04, Andrej Mitrovic via Digitalmars-d wrote:
When I had to test windows-specific stuff I put the actual test files
in /extra-files/. Here's an example:
https://github.com/D-Programming-Language/dmd/blob/master/test/compilable/test9680.sh
So you could simply exit if ${OS} does
On 12/09/14 00:22, H. S. Teoh via Digitalmars-d wrote:
Any ideas how to work around this breakage? (Short of hacking
root/checkedint.c, which is not particularly appealing since it's
supposed to be a direct translation of the D version of checkedint.)
If you only need debugging symbols, then
On 11/09/14 21:02, eles wrote:
Could you provide one or two short but illustrative examples in Tango
and Phobos showing the howto and the why not in Phobos?
Tango:
import tango.text.Unicode;
void foo ()
{
char[3] result; // pre-allocate buffer on the stack
auto b =
On 12/09/14 02:44, David Nadlinger wrote:
Just a quick comment on this: 2) is very simple to implement for all the
compilers that actually use libunwind Dwarf 2 EH on Linux, i.e. GDC and
LDC (I think deadalnix already looked into this for SDC).
It would be nice if DMD could do the same for D
On 12/09/14 02:35, Andrei Alexandrescu wrote:
Hello,
We are racking our brains to figure out what to do about exceptions
thrown from C++ functions into D code that calls them.
A few levels of Nirvana would go like this:
0. Undefined behavior - the only advantage to this is we're there
On 12/09/14 05:25, deadalnix wrote:
Yes, that is pretty why I limited myself to the unwind properly but do
not catch option. This one would require to mess with the innards of
various C++ runtime.
On 64bit Objective-C can catch C++ exceptions. But I don't think you can
do anything with the
On 12/09/14 07:01, Iain Buclaw via Digitalmars-d wrote:
Libunwind + handling foreign exceptions you can do this. And is
beneficial in that it works with any other languages that use libunwind,
such as gccgo.
And Objective-C.
--
/Jacob Carlborg
On 12/09/14 08:59, Daniel Kozak via Digitalmars-d wrote:
toUpperInPlace could help little, but still not perfect
Converting text to uppercase doesn't work in-place in some cases. For
example the German double S will take two letters in uppercase form.
--
/Jacob Carlborg
On 12/09/14 09:58, eles wrote:
On Friday, 12 September 2014 at 06:47:56 UTC, Jacob Carlborg wrote:
On 11/09/14 21:02, eles wrote:
Thank you. Basically, it is about a different interface of the
functions, something like the difference between new and placement new.
This could be added to
On 2014-09-13 03:36, Manu via Digitalmars-d wrote:
Yeah, but that's true regardless of C++ interop. It's so easy to make
mistakes, and so hard to find them when you do. virtual-by-default is
responsible for most of the silent errors in my code by far.
Surely, at very least, an extern(C++) class
301 - 400 of 3698 matches
Mail list logo
