On 2012-36-22 01:10, bearophile wrote:
This benchmark shows that if you allocate the class instances on the
heap one at a time the total amount of memory used is the same for the
various Bar (maybe because of the GC), so that optimization is useful
for emplace() only and similar in-place a
On 2012-10-22 01:36, bearophile wrote:
D classes are free to reorder their fields, so maybe Bar1 should reorder
its fields as Bar3, to save 4 bytes for each instance on 32 bit systems:
Are D allowed to reorder the class fields? What happens then to binary
compatibility?
--
/Jacob Carlborg
Simen Kjaeraas:
The current GC always allocates a power of two, with a minimum
of 16
bytes. You should see an effect if you make a class that will
be above such a threshold without reordering, and below with.
Right.
Nothing bad can come of it.
OK :-)
--
Jacob Carlbo
Hi,
My first post here as a new D user. I am trying to interface with
FFmpeg with D and need some guidance on how to replicate the
version semantics in a C header. I'd like to open source the D
modules files so I want to get this right.
FFMpeg defines a bunch of constants that are then used
On 2012-10-22 10:48, bearophile wrote:
This page says:
http://dlang.org/class.html
The D compiler is free to rearrange the order of fields in a class to
optimally pack them in an implementation-defined manner. Consider the
fields much like the local variables in a function - the compiler
assig
Sumit Raja:
Am I using version correctly? How is this done usually?
I think "version" is usually meant to be given as compiler
switch. Maybe a simple enum + static if is enough in your case.
And keep in mind that C int and D int are different on 64 bit
systems, the D int is always 32 bit.
Thanks for explanation!
On Mon, 22 Oct 2012 12:39:48 +0100, bearophile
wrote:
Sumit Raja:
Am I using version correctly? How is this done usually?
I think "version" is usually meant to be given as compiler switch. Maybe
a simple enum + static if is enough in your case.
Good suggestion. I was curious so I had
SWIG requires some kind of interface files, which I assume one
must have to manually write. Then what's the difference?
These can be as small as:
sfml.i:
%{
#include
%}
%include SFML/Config.hpp
%include SFML/Audio/Export.hpp
In practice, some additional tweaks may be needed to support
certa
correction regarding macros:
myheader.h:
#define MEX_INFORMATION_VERSION 1
interface file myheader.i:
%{
%include "myheader.h"
%}
%include myheader.h
generated d file will contain:
int MEX_INFORMATION_VERSION() @property {
auto ret = swig.mex_im.swig_mex_MEX_INFORMATION_VERSION_get();
retu
On Monday, 22 October 2012 at 06:28:12 UTC, Jacob Carlborg wrote:
On 2012-10-21 21:45, timotheecour wrote:
Manually porting of C/C++ libraries shouldn't be the way to go
(a
major problem being when said library gets updated, human
errors,
porting to different architectures etc).
SWIG require
On 2012-10-22 19:27, timotheecour wrote:
SWIG requires some kind of interface files, which I assume one must
have to manually write. Then what's the difference?
These can be as small as:
sfml.i:
%{
#include
%}
%include SFML/Config.hpp
%include SFML/Audio/Export.hpp
In practice, some additio
On 2012-10-22 20:38, Brad Lanam wrote:
Huge difference. It's not necessary to figure out corresponding type
sizes on every system. I only need to figure out what needs to be in
there. And once all the work of creating the interface file is done,
the work of porting to another architecture or
On 2012-10-22 19:27, timotheecour wrote:
http://www.swig.org/Doc1.1/HTML/SWIG.html#n7
One of SWIG's most recent additions is support for Objective-C parsing.
This is currently an experimental feature that may be improved in future
releases.
Will this generate C code or can it be made to genera
On Monday, 22 October 2012 at 19:12:46 UTC, Jacob Carlborg wrote:
On 2012-10-22 20:38, Brad Lanam wrote:
I prefer the approach I took when I created DStep, it uses
libclang. The tool can parse all C(++) and Objective-C(++) code
that clang can. Although it currently won't generate code for
ever
On Monday, 22 October 2012 at 19:12:46 UTC, Jacob Carlborg wrote:
On 2012-10-22 20:38, Brad Lanam wrote:
I prefer the approach I took when I created DStep, it uses
libclang. The tool can parse all C(++) and Objective-C(++) code
that clang can. Although it currently won't generate code for
ever
On Sunday, 21 October 2012 at 22:47:00 UTC, Jonathan M Davis
wrote:
http://dlang.org/function.html#function-overloading
The big thing to remember here is that constness matters more
than refness when overloads are chosen, so if you want refness
to matter when choosing an overload, then the c
On Monday, October 22, 2012 22:54:44 Era Scarecrow wrote:
> On Sunday, 21 October 2012 at 22:47:00 UTC, Jonathan M Davis
>
> wrote:
> > http://dlang.org/function.html#function-overloading
> >
> > The big thing to remember here is that constness matters more
> > than refness when overloads are cho
On Monday, 22 October 2012 at 21:58:04 UTC, Jonathan M Davis
wrote:
AFAIK, there are no plans to change it. I don't think that it's
even been suggested.
I thought I suggested it back for a different order of
preferences. Basically boils down to accepting the const ones
over the non-const whe
On 2012-10-22 21:48, Brad Lanam wrote:
Nothing wrong with that.
I had different goals -- portability and legacy systems. My tool is all
bourne shell and awk. There aren't many systems it does not work on
(e.g. ULTRIX shell runs out of memory).
How can you mention bourne shell and portability
On 2012-10-23 07:09, timotheecour wrote:
If you try to automate processing of the pre-processed headers,
all of the included system headers will be processed and too much that
isn't needed will be output.
Swig has lots of customization to control what gets translated. For
example, we recursivel
21 matches
Mail list logo
