On 2/12/2015 3:40 AM, Freddy wrote:
import std.stdio;
auto test1(){
void testFunc(){
}
return &testFunc;
}
auto test2(){
uint a;
void testFunc(){
a=1;
}
return &testFunc;
}
void main(){
writeln(test1()==test1());//true
writeln(test2()=
On 2/12/2015 6:42 AM, ketmar wrote:
this problem has very easy solition: we should stop calling class dtors
"destructors", and rename them to "finalizers".
Absolutely. So many people coming from C++ see "destructor" and want to
use them as they did in C++. How often do we see people coming
Truth be told, D has no guideline for deterministic destruction
of managed resources.
On Thursday, February 12, 2015 08:33:34 Kagamin via Digitalmars-d-learn wrote:
> Truth be told, D has no guideline for deterministic destruction
> of managed resources.
Really what it comes down to is that if you want deterministic destruction,
you _don't_ use managed resources. You use malloc and
On Thursday, 12 February 2015 at 08:14:49 UTC, Mike Parker wrote:
On 2/12/2015 6:42 AM, ketmar wrote:
this problem has very easy solition: we should stop calling
class dtors
"destructors", and rename them to "finalizers".
Absolutely. So many people coming from C++ see "destructor" and
wa
On Thursday, 12 February 2015 at 08:33:35 UTC, Kagamin wrote:
Truth be told, D has no guideline for deterministic destruction
of managed resources.
+1
don't complain about people wondering why class destructors don't
work when there's no _real_ way to do it in D beyond 'drop down
to C level
On Thursday, 12 February 2015 at 08:55:43 UTC, Jonathan M Davis
wrote:
On Thursday, February 12, 2015 08:33:34 Kagamin via
Digitalmars-d-learn wrote:
Truth be told, D has no guideline for deterministic destruction
of managed resources.
Really what it comes down to is that if you want determini
On Thu, 12 Feb 2015 09:26:12 +, Kagamin wrote:
> That's a repetition of C++ atavism, that resource management == memory
> management. IStream is a traditional example of a GC-managed object,
> which needs deterministic destruction, and not because it consumes
> memory, but because it encapsula
On Thu, 12 Feb 2015 09:26:12 +, Kagamin wrote:
> That's a repetition of C++ atavism, that resource management == memory
> management. IStream is a traditional example of a GC-managed object,
> which needs deterministic destruction, and not because it consumes
> memory, but because it encapsula
On Thu, 12 Feb 2015 09:04:27 +, ponce wrote:
> http://p0nce.github.io/d-idioms/#The-trouble-with-class-destructors
>
> I've also made one for "D can't do real-time because it has a
> stop-the-world GC"
> http://p0nce.github.io/d-idioms/#The-impossible-real-time-thread
>
> And one for "D does
Is there any "reliable" way to determine whether there is a
certain type of object in memory at a given address?
I am going to send the memory address of an object to another
program over pipes. Then after a while, other program will send
that memory address, and main program will try to addre
On Thursday, 12 February 2015 at 10:03:18 UTC, tcak wrote:
Is there any "reliable" way to determine whether there is a
certain type of object in memory at a given address?
I am going to send the memory address of an object to another
program over pipes. Then after a while, other program will s
On Thursday, 12 February 2015 at 10:04:29 UTC, tcak wrote:
BTW, I have already got the address of object into a "size_t"
type variable and sent it. That is not the problem part.
How reliable do you want? You would have to either "pin the
object" by registering a root to it to prevent it from b
On 2/12/2015 6:09 PM, weaselcat wrote:
On Thursday, 12 February 2015 at 08:33:35 UTC, Kagamin wrote:
Truth be told, D has no guideline for deterministic destruction of
managed resources.
+1
don't complain about people wondering why class destructors don't work
when there's no _real_ way to do
Thanks, everyone.
Or send a hash of the object along with the memory address,
then query the GC wether the memory is still allocated.
This part sounds interesnting. How does that GC querying thing
works exactly?
On Thursday, 12 February 2015 at 09:50:39 UTC, ketmar wrote:
On Thu, 12 Feb 2015 09:04:27 +, ponce wrote:
http://p0nce.github.io/d-idioms/#The-trouble-with-class-destructors
I've also made one for "D can't do real-time because it has a
stop-the-world GC"
http://p0nce.github.io/d-idioms/#Th
On Thursday, 12 February 2015 at 10:24:38 UTC, Mike Parker wrote:
On 2/12/2015 6:09 PM, weaselcat wrote:
On Thursday, 12 February 2015 at 08:33:35 UTC, Kagamin wrote:
Truth be told, D has no guideline for deterministic
destruction of
managed resources.
+1
don't complain about people wonderi
On Thu, 12 Feb 2015 11:10:34 +, ponce wrote:
> On Thursday, 12 February 2015 at 09:50:39 UTC, ketmar wrote:
>> On Thu, 12 Feb 2015 09:04:27 +, ponce wrote:
>>
>>> http://p0nce.github.io/d-idioms/#The-trouble-with-class-destructors
>>>
>>> I've also made one for "D can't do real-time becau
OK. there is some example:
// we're using an OpenGL
class A
{
protected int m_tex;
this()
{
// texture has been created in video memory. there is no GC
resource.
glGenTexture(1, &m_tex);
glTexImage2D(); // texture in video memory
Hi
We have a network traffic logger module at office.
We need to a tool which creates simple traffic with different
protocols and test our product's output to see if we parse the
headers correctly or not.
And of course I proposed writing this tool with D!!!
When it comes to create a HTTP ses
On Thursday, 12 February 2015 at 11:11:53 UTC, ponce wrote:
On Thursday, 12 February 2015 at 10:24:38 UTC, Mike Parker
wrote:
On 2/12/2015 6:09 PM, weaselcat wrote:
On Thursday, 12 February 2015 at 08:33:35 UTC, Kagamin wrote:
Truth be told, D has no guideline for deterministic
destruction of
On Thursday, 12 February 2015 at 12:10:22 UTC, Andrey Derzhavin
wrote:
OK. there is some example:
// we're using an OpenGL
class A
{
protected int m_tex;
this()
{
// texture has been created in video memory. there is no GC
resource.
glGenTexture(1, &m_
On Thursday, 12 February 2015 at 12:11:27 UTC, Kadir Erdem Demir
wrote:
Hi
We have a network traffic logger module at office.
We need to a tool which creates simple traffic with different
protocols and test our product's output to see if we parse the
headers correctly or not.
And of course I
On Thu, 12 Feb 2015 12:10:21 +, Andrey Derzhavin wrote:
> if GC does not guarantee the calling of dtor we can't be sure that some
> textures will be destroyed.
> It will be followed by overflowing of the video memory.
> And it is obvious, becouse we have no way to detect when the objects are
>
get("https://dlang.org";, http);
It works as I wanted, thanks a lot .
Regards
Erdem
On Thursday, 12 February 2015 at 12:29:47 UTC, Marc Schütz wrote:
Exactly. That's why it's wrong to rely on the GC if you need
deterministic resource management. It's simply the wrong tool
for that.
Unfortunately, the "right" tools are a bit awkward to use, for
the time being. I still have h
On Thu, 12 Feb 2015 12:52:02 +, Andrey Derzhavin wrote:
> If we can't relay on GC wholly, there is no need for GC.
> All of the objects, that I can create, I can destroy manually by myself,
> without any doubtful GC destroying attempts.
sure. but when it comes, for example, for big data struc
On Thursday, 12 February 2015 at 09:41:50 UTC, ketmar wrote:
On Thu, 12 Feb 2015 09:26:12 +, Kagamin wrote:
That's a repetition of C++ atavism, that resource management
== memory
management. IStream is a traditional example of a GC-managed
object,
which needs deterministic destruction, and
On Sunday, 8 February 2015 at 05:57:31 UTC, Lave Zhang wrote:
Hi,
My first D program is like this:
---
import std.stdio;
void main(string[] args)
{
dstring s1 = "hello你好"d;
writeln(s1);
}
---
But the output is not corre
On Thursday, 12 February 2015 at 13:11:48 UTC, ketmar wrote:
sure. but when it comes, for example, for big data structures
with
complex cross-references, you'll inevitably found that you
either leaking
memory, or writing your own half-backed semi-working GC
realization.
ah, good luck doing ef
On Thu, 12 Feb 2015 13:21:07 +, Paulo Pinto wrote:
> On Thursday, 12 February 2015 at 09:41:50 UTC, ketmar wrote:
>> On Thu, 12 Feb 2015 09:26:12 +, Kagamin wrote:
>>
>>> That's a repetition of C++ atavism, that resource management == memory
>>> management. IStream is a traditional exampl
On Thu, 12 Feb 2015 13:55:20 +, Andrey Derzhavin wrote:
> On Thursday, 12 February 2015 at 13:11:48 UTC, ketmar wrote:
>> sure. but when it comes, for example, for big data structures with
>> complex cross-references, you'll inevitably found that you either
>> leaking memory, or writing your o
On Thursday, 12 February 2015 at 12:52:03 UTC, Andrey Derzhavin
wrote:
If we can't relay on GC wholly, there is no need for GC.
All of the objects, that I can create, I can destroy manually
by myself, without any doubtful GC destroying attempts.
Manual memory management should be possible in D
On Thursday, 12 February 2015 at 11:10:35 UTC, ponce wrote:
On Thursday, 12 February 2015 at 09:50:39 UTC, ketmar wrote:
On Thu, 12 Feb 2015 09:04:27 +, ponce wrote:
http://p0nce.github.io/d-idioms/#The-trouble-with-class-destructors
I've also made one for "D can't do real-time because it
On Wednesday, 11 February 2015 at 22:24:53 UTC, anonymous wrote:
On Wednesday, 11 February 2015 at 22:14:44 UTC, MrSmith wrote:
http://dpaste.dzfl.pl/5f1d5d5d9e19
Instead I need to use template constraint which is less
compact.
http://dpaste.dzfl.pl/571ae84d783e
Why such behavior happens?
On Thursday, 12 February 2015 at 10:16:49 UTC, Ola Fosheim
Grøstad wrote:
then query the GC wether the memory is still allocated.
This is racy, though. Someone (or the GC) could have freed the
object in the meantime, and a new object of potentially different
type could have taken its place. Y
On Thursday, 12 February 2015 at 11:14:05 UTC, tcak wrote:
Or send a hash of the object along with the memory address,
then query the GC wether the memory is still allocated.
This part sounds interesnting. How does that GC querying thing
works exactly?
std [doc][1] is your friend but if you
On Thursday, 12 February 2015 at 15:53:07 UTC, Marc Schütz wrote:
On Thursday, 12 February 2015 at 10:16:49 UTC, Ola Fosheim
Grøstad wrote:
then query the GC wether the memory is still allocated.
This is racy, though. Someone (or the GC) could have freed the
object in the meantime, and a new
On Thursday, 12 February 2015 at 16:27:21 UTC, Ola Fosheim
Grøstad wrote:
On Thursday, 12 February 2015 at 15:53:07 UTC, Marc Schütz
wrote:
On Thursday, 12 February 2015 at 10:16:49 UTC, Ola Fosheim
Grøstad wrote:
then query the GC wether the memory is still allocated.
This is racy, though. S
On Thursday, 12 February 2015 at 16:56:24 UTC, Marc Schütz wrote:
Whoaa, that's just horrible! *shudder*
I know, but it works.
On Thursday, 12 February 2015 at 14:44:07 UTC, Kagamin wrote:
On Thursday, 12 February 2015 at 12:52:03 UTC, Andrey Derzhavin
wrote:
If we can't relay on GC wholly, there is no need for GC.
All of the objects, that I can create, I can destroy manually
by myself, without any doubtful GC destroyi
I have a template function that gets values out of a tree of
variant types. My goal is to be able to write code like;
node.get!string("path", "to", "leaf");
Inside get(), I would like to use std.conv to dynamically convert
(where able) to the target type (T) or, if that is not possible,
to re
On Thu, 12 Feb 2015 19:09:45 +, Chris Williams wrote:
> Is there something like isConvertible() in the library somewhere?
there is at least `std.traits.isImplicitlyConvertible`:
http://dlang.org/phobos/std_traits.html#isImplicitlyConvertible
signature.asc
Description: PGP signature
On Thursday, February 12, 2015 19:09:45 Chris Williams via Digitalmars-d-learn
wrote:
> I have a template function that gets values out of a tree of
> variant types. My goal is to be able to write code like;
>
> node.get!string("path", "to", "leaf");
>
> Inside get(), I would like to use std.conv
Thank you!
I'm currently trying to write a personal Associate Array class
that can be used in @nogc sections. Obviously, this means I'll
want to use malloc/free, however I'm not sure what the "Correct"
way to do this is. In a few places online I've seen code for
custom "_new" and "_delete" functions simil
I realized the above "_new" has an issue with emplace depending
on whether it's a class (reference type) or not. Class c =
emplace() works, but something like string s = emplace() does
not. Is doing string s = *emplace() safe and okay? Or is there a
better way to handle the differences between
On Thursday, 12 February 2015 at 23:27:51 UTC, Kitt wrote:
I'm currently trying to write a personal Associate Array class
that can be used in @nogc sections. Obviously, this means I'll
want to use malloc/free, however I'm not sure what the
"Correct" way to do this is. In a few places online I'v
finally ,I write a orm tool to replace hibernated, it is simple,
and it is easy to use, and every thing in control.
It is free to copy ,improve.
module mysqlormutil;
import vibe.d;
import std.stdio;
import mysql.connection;
import mysql.db;
struct NotNull
{
}
struct Auto
{
}
struct Index
how to update table schema automatically:
this()
{
mdb = new MysqlDB(connStr);
auto conn = mdb.lockConnection();
scope(exit) conn.close();
MysqlOrmUtil.updateTableSchema!(Customer)(conn);
MysqlOrmUtil.updateT
here is how to use:
@UniqueIndex("id",["id"])
class Card
{
@NotNull()
@Auto()
long id;
string pwd;
long agentId;
bool valid;
long rmb;
long createDate;
long soldDate;
long chargeDate;
}
public Card[] getAllCa
I've begun writing some basic OpenGL code using DerelictGL3 but
I've hit a wall. I've managed to open a window (with
DerelictSDL2) and call basic OpenGL functions such as glClear().
Still I can not get a basic triangle up and running. glError()
does not return anything and when compiling, linki
On Thursday, 12 February 2015 at 23:27:51 UTC, Kitt wrote:
The Exception obviously uses the GC, and would need to be
replaced with a printf or something; however, emplace doesn't
have a @nogc replacement that I know of. What I'd like to know,
from people much more knowledgeable about the ins an
54 matches
Mail list logo
