Re: Centralizable configured compile-time class instantiation
shd Wrote:
2011/7/12 Kagamin s...@here.lot:
You want an IOC container like Unity?
exactly
And you want the interface-to-class mapping to be configurable externally
rather than version out these classes directly in source?
like
version(UseGL)
{
�static import wrappers.gl;
�alias wrappers.gl.WindowImpl Window;
}
else version(UseWhat)
{
�static import wrappers.what;
�alias wrappers.what.WindowImpl Window;
}
container.register!(IWindow,Window)();
client:
IWindow myWindow=container.resolve!(IWindow)();
that's right :)
Hmm... If you have
wrappers/gl/guiImpl/...
and
wrappers/what/guiImpl/...
and conditionally add them to includes
for example
with -I wrappers/gl you should be able to import guiImpl; and use
guiImpl.Window. If it's -I wrappers/what, guiImpl.Window is still
guiImpl.Window.
Re: This seems like what could be a common cause of bugs
Steven Schveighoffer Wrote: On Tue, 12 Jul 2011 11:07:57 -0400, Kagamin s...@here.lot wrote: Steven Schveighoffer Wrote: Yes, but this is getting into territory where the false positive rate might get high. I bet it will be difficult to find a real-world example of this false positive. It depends on how the warning is triggered. Does this fail? void foo(int x, int y) Well, I said real-world example. You're talking about frequency, right? If the frequency is zero, it's no problem.
Re: Centralizable configured compile-time class instantiation
2011/7/13 Kagamin s...@here.lot: Hmm... If you have wrappers/gl/guiImpl/... and wrappers/what/guiImpl/... and conditionally add them to includes for example with -I wrappers/gl you should be able to import guiImpl; and use guiImpl.Window. If it's -I wrappers/what, guiImpl.Window is still guiImpl.Window. Yeah, that might work. I tend to see everywhere very strange problems (for other people). Like I think of including interface file from user-app, and then give him only this interface compliant instance. And if he wants to use some implementation-depended functionalities he should clearly instantiate IObjectSpecialized or import specialized.path.to.package; By doing it in way you are talking about (which is kind of less perfectionist version of method mentioned by me in first post, although *it works*), user is able to import path.to.package; then instantiate object by standard instantiation, and accidentally use implementation-dependant method. Then, he commits and someone else wants to compile end-app with different set of implementation libraries. Program won't compile because someone used method which isn't specified in portable interface. In the same time, program is assumed to work so, because it's not clear that person who wrote this call is acting unportable (so we're relying on documentation rather than no-can-do method). So it's a fail of my 'framework', which claims to let use x, y and z libraries interchangeably by only changing cmake definition, while the build breaks. Author of framework didn't gave programmer, clear feedback that he is acting unportable. I hope i didn't bored you too much with my imagination because there is something more i don't like. Directory hierarchy :) It's not D-related though. Soo, the only solutions we came up is doing it out of language (by -I impl/library/path), or messing with import/aliases in interfaces which isn't nice. Although first solution isn't as good as i hoped for, it works... which is a good start, so i'll probably do it this way :)
Re: Centralizable configured compile-time class instantiation
2011/7/13 Jesse Phillips jessekphillip...@gmail.com: After reading Kagamin's response, I'm not sure I understand you still. You want to have code reuse, you want to have run-time and compile-time configuration, but you don't want to make use of the technologies/techniques/patterns which facilitate these. I'm not sure are you referring 'technologies/techniques/patterns' to code reusability or configuration. If the first one, read one. If second, i don't know which techniques/patterns you are talking about. version() doesn't match for me here i think. You say no to libraries That's not true! I'm not sure how did you came up to this conclusions, but i love libraries for applications same as command-line programs (like ffmpeg) for GUI apps. , you say no to frameworks, That's true i don't really like frameworks, but only because i felt like they're trying to be irreplaceable. If you're using one part, it's hard to make other parts they implemented in your own way (so they're too tightly integrated). Maybe i just tried wrong ones, i don't know. Libraries on the other hand, let you compose your program from solutions i like most, and that's why i'm trying to do this clear division between interface and implementation. So i can use different specialized libraries, and later make my own, so if someone likes my entity system he doesn't have to use my poor renderer. So hopefully i won't end-up with some big chunk of code as ogre3d. you say no to versioning and desire the benefits of these without what they entail. If you come up with an alternative, then please do bring it forward. I don't see how anyone will be able to get you what you want. I like version control, and that's why i'm using one (git), even if i don't really need to operate with someone because of current project phase. Versions we're talking about are rather like compilation profiles, so you can use different sets of libraries to try different implementations without code modification. So, in one moment there would be code for many alternative implementations, and versions would affect only resulting binary which isn't commited at all.
Re: Centralizable configured compile-time class instantiation
On 13.07.2011 15:39, shd wrote: I hope i didn't bored you too much with my imagination because there is something more i don't like. Directory hierarchy :) It's not D-related though. Understanding a risk of going completely OT: you are not alone on this one :) Time ago I thought of something more like tag based file system, where filetypes and e.g. date of modification are just that - one of myriad of tags, besides any additional that are user/system defined. Though I have never reached any more or less complete design, the idea still thrills me. -- Dmitry Olshansky
Re: template instance cannot use local 'f' as parameter to non-global template
Anybody an idea?
Re: template instance cannot use local 'f' as parameter to non-global template
On 12.07.2011 15:06, Trass3r wrote:
Is this a bug? If not, how do you make it work?
void h() {}
class Bla
{
mixin wrap!h;
}
mixin template wrap(alias f)
{
void blub(alias g = f)()
{
}
}
void main()
{
Bla b = new Bla();
b.blub();
}
test.d(18): Error: template instance cannot use local 'f' as parameter
to non-global template blub(alias g = f)
test.d(18): Error: template instance forward reference of f
test.d(18): Error: template instance test.Bla.wrap!(h).blub!(f) error
instantiating
I am not sure but i am not that used to those template aliases anyway.
Re: template instance cannot use local 'f' as parameter to non-global template
On Tue, 12 Jul 2011 09:06:56 -0400, Trass3r u...@known.com wrote:
Is this a bug? If not, how do you make it work?
void h() {}
class Bla
{
mixin wrap!h;
}
mixin template wrap(alias f)
{
void blub(alias g = f)()
{
}
}
void main()
{
Bla b = new Bla();
b.blub();
}
test.d(18): Error: template instance cannot use local 'f' as parameter
to non-global template blub(alias g = f)
test.d(18): Error: template instance forward reference of f
test.d(18): Error: template instance test.Bla.wrap!(h).blub!(f) error
instantiating
I've seen this error before...
*searches memory and old code*
Here you go: http://d.puremagic.com/issues/show_bug.cgi?id=3051
As a workaround, is there a reason you need blub to be parameterized? I
mean, f is already part of the template.
-Steve
Re: template instance cannot use local 'f' as parameter to non-global template
Am 13.07.2011, 16:02 Uhr, schrieb Steven Schveighoffer
schvei...@yahoo.com:
void h() {}
class Bla
{
mixin wrap!h;
}
mixin template wrap(alias f)
{
void blub(alias g = f)()
{
g();
}
}
As a workaround, is there a reason you need blub to be parameterized? I
mean, f is already part of the template.
Yep, a default function is passed to wrap and in most cases blub just
calls that one.
But sometimes I need blub to use a function other than the default one.
Re: template instance cannot use local 'f' as parameter to non-global template
On 7/13/2011 11:35 PM, Trass3r wrote:
Am 13.07.2011, 16:02 Uhr, schrieb Steven Schveighoffer
schvei...@yahoo.com:
void h() {}
class Bla
{
mixin wrap!h;
}
mixin template wrap(alias f)
{
void blub(alias g = f)()
{
g();
}
}
As a workaround, is there a reason you need blub to be parameterized?
I mean, f is already part of the template.
Yep, a default function is passed to wrap and in most cases blub just
calls that one.
But sometimes I need blub to use a function other than the default one.
Don't know it this is the right answer or a possible bug but it does the
trick:
void h() { import std.stdio; write(h()); }
class Bla
{
mixin wrap!h;
}
mixin template wrap(alias f)
{
void blub(typeof(f) g = f)
{
g();
}
}
void main()
{
Bla b = new Bla();
b.blub();
}
Re: Declaring a D pointer to a C function
Andrej Mitrovic andrej.mitrov...@gmail.com wrote in message news:mailman.1569.1310506439.14074.digitalmars-d-le...@puremagic.com... Is this going to be fixed any time soon? Allowing callbacks with D calling convention where a C callback is expected should be an error, and this is like the 10th time I've ran into this bug. What, the bug that annoyed me so much I fixed it myself? Yeah, this should be gone by the next release.
Re: Declaring a D pointer to a C function
On 7/13/11, Daniel Murphy yebbl...@nospamgmail.com wrote: Andrej Mitrovic andrej.mitrov...@gmail.com wrote in message news:mailman.1569.1310506439.14074.digitalmars-d-le...@puremagic.com... Is this going to be fixed any time soon? Allowing callbacks with D calling convention where a C callback is expected should be an error, and this is like the 10th time I've ran into this bug. What, the bug that annoyed me so much I fixed it myself? Yeah, this should be gone by the next release. Thanks! I've literally lost an entire day once when I was just starting using D and C together and had a calling convention mismatch. :x
Re: template instance cannot use local 'f' as parameter to non-global template
Am 13.07.2011, 16:58 Uhr, schrieb Tyro[a.c.edwards] nos...@home.com:
Don't know it this is the right answer or a possible bug but it does the
trick:
void h() { import std.stdio; write(h()); }
class Bla
{
mixin wrap!h;
}
mixin template wrap(alias f)
{
void blub(typeof(f) g = f)
{
g();
}
}
void main()
{
Bla b = new Bla();
b.blub();
}
Thanks!
Unfortunately it doesn't work with more complex functions:
Error: arithmetic/string type expected for value-parameter, not cl_errcode
C function(cl_program program, uint param_name, ulong param_value_size,
void* param_value, ulong* param_value_size_ret)
Re: template instance cannot use local 'f' as parameter to non-global template
I've seen this error before... *searches memory and old code* Here you go: http://d.puremagic.com/issues/show_bug.cgi?id=3051 I think this is yet another issue. The inner template argument is not something on the stack but it is a template argument.
Re: Declaring a D pointer to a C function
Andrej Mitrovic andrej.mitrov...@gmail.com wrote in message news:mailman.1607.1310570915.14074.digitalmars-d-le...@puremagic.com... Thanks! I've literally lost an entire day once when I was just starting using D and C together and had a calling convention mismatch. :x It's worse than just calling conventions - try changing the parameter types! (or basically anything except the return type)
Re: Centralizable configured compile-time class instantiation
shd Wrote: 2011/7/13 Jesse Phillips jessekphillip...@gmail.com: You say no to libraries That's not true! I'm not sure how did you came up to this conclusions, but i love libraries for applications same as command-line programs (like ffmpeg) for GUI apps. It comes from, and APIs are not what i'd love to work with[...] A good library provides a good API. You build reusable code by creating a library that defines interfaces and routines that can be used by many applications. You make a library replaceable by providing defined interfaces and routines that another library can mimic. You generally don't provide a project that allows swapping out an implementation detail from a compiler switch, such as which Associative Array library to use. If you are doing graphical display you might want to support rendering to Cairo or QT or Windows Forms, but this means you will have to write the code that works with them. Or you'll have to define the API for which your library expects of a graphics rendering library and the person wanting to use one will need to write a wrapper for one of these libraries to conform to your API. This means they will have to write some code and will be using their own build setup and not one you have provided. I hope I'm being a little helpful, or at least you can see where I'm getting confused. Anyway it seems you got something workable (I was hoping someone else would pick this up if I asked the initial questions and it worked).
Re: Declaring a D pointer to a C function
On Wed, 13 Jul 2011 11:32:50 -0400, Daniel Murphy yebbl...@nospamgmail.com wrote: Andrej Mitrovic andrej.mitrov...@gmail.com wrote in message news:mailman.1607.1310570915.14074.digitalmars-d-le...@puremagic.com... Thanks! I've literally lost an entire day once when I was just starting using D and C together and had a calling convention mismatch. :x It's worse than just calling conventions - try changing the parameter types! (or basically anything except the return type) Yeah, examining the assembly, a major difference is that D passes one parameter in a register, whereas C pushes it on the stack. This means you are going to have off-by-one corruption any time you access a parameter. -Steve
Re: Centralizable configured compile-time class instantiation
2011/7/13 Dmitry Olshansky dmitry.o...@gmail.com Time ago I thought of something more like tag based file system, where filetypes and e.g. date of modification are just that - one of myriad of tags, besides any additional that are user/system defined. Though I have never reached any more or less complete design, the idea still thrills me. Been thinking about it too, so i suppose it's quite common idea :) I didn't even started designing it for real (to code) because i don't think i had/have now necessary qualifications, time and... come on - it had to be part of my uber secure and (quite...) easy to use operating system with semi-formally tested microkernel... but doh :) Yeah, one of this extremely unlikely to achieve ideas. But this is good when other people have similar thoughts. Maybe someday, someone will make it.
Re: Centralizable configured compile-time class instantiation
2011/7/13 Jesse Phillips jessekphillip...@gmail.com: shd Wrote: 2011/7/13 Jesse Phillips jessekphillip...@gmail.com: You say no to libraries That's not true! I'm not sure how did you came up to this conclusions, but i love libraries for applications same as command-line programs (like ffmpeg) for GUI apps. It comes from, and APIs are not what i'd love to work with[...] Yeah, but it doesn't mean i don't like library concept. The other thing is, i'm not saying libraries i'm using got bad APIs. They're not D, so they have to be C which means APIs aren't OO and i'd like to use in my code OO things which are good integrating with D language features. Furthermore, API is the only one of aspects for choosing library for yourself. A good library provides a good API. You build reusable code by creating a library that defines interfaces and routines that can be used by many applications. You make a library replaceable by providing defined interfaces and routines that another library can mimic. You generally don't provide a project that allows swapping out an implementation detail from a compiler switch, such as which Associative Array library to use. If you are doing graphical display you might want to support rendering to Cairo or QT or Windows Forms, but this means you will have to write the code that works with them. Or you'll have to define the API for which your library expects of a graphics rendering library and the person wanting to use one will need to write a wrapper for one of these libraries to conform to your API. This means they will have to write some code and will be using their own build setup and not one you have provided. I see your point, but i'm young enough to try things on my way first. If it won't work, i'll refactor/drop whatever.The only things i don't want to implement, are if someone already tried it, described that it failed (and WHY), If you see something against swappable implementations besides of performance and 'you can abstract it out', then i'll gladly hear. It's a personal project where i'm making first steps in this area, so i'd like to take advantage of my freshness. I'm not doing it because i have to feed myself and my family, nor someone (besides of me) isn't attached to success of it. If only thing i get from it is knowledge (and fun), good for me. So, if the only thing against is, 'generally people are doing other way' - it's ok for me to try my way. Anyway, it's not true that people aren't swapping implementations during compilation. Most famous example i believe would be linux kernel and it's config. Can't you tweak scheduler algorithm, or 439284 other options? Yes, you can. I think it's cool. I hope I'm being a little helpful, or at least you can see where I'm getting confused. Anyway it seems you got something workable (I was hoping someone else would pick this up if I asked the initial questions and it worked). Yep, you helped a lot. Thank you.
Re: String Appender Fails (Memory Allocation Failure)
On 2011-07-14 01:11, Loopback wrote:
Hello!
I've been working on a project where I had to do all memory handling
explicitly because no destructors were called. When I got too tired
of the explicit memory handling I decided to trace what was causing
this error. After hours of code stripping I had gotten myself a
small concrete sample which could demonstrate the error.
Now to the point; I create a program using WinMain as entry point. The
program template i use, is identical to the win32 template on the
D-Website. If you have used this template you know that all user code
goes within the function myWinMain. In this function I declare a class
named Foo. When I create this class an empty constructor is called, and
then the function myWinMain returns.
Now the program calls Runtime.terminate, which is supposed to take
care of the memory garbage and etc. This does not work. The terminate
function call throws an Error, Memory Allocation Failure.
This failure originates in the 'Foo' destructor, which in turn creates
a appender object of type string. My question is; how come this throws
an error?
Not to forget the important part:
// Import WINAPI
import win32.windows;
// Core API
import core.runtime;
// For appender
import std.range;
extern (Windows) int WinMain(HINSTANCE hInstance, HINSTANCE
hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
{
int result;
void exceptionHandler(Throwable e) { throw e; }
try
{
Runtime.initialize(exceptionHandler);
result = myWinMain(hInstance, hPrevInstance, lpCmdLine,
nCmdShow);
Runtime.terminate(exceptionHandler);
}
// If you use Exception object instead here, the program fails
// silently without any MessageBox of any kind. The program, in this
case quits
// automatically after about 7-12 seconds, without any destructors
called.
// If you instead use Error object to catch the error, a message pops
// up saying, Memory Allocation Failure, why?
catch (/*Exception*/Error o) // catch any uncaught exceptions
{
MessageBoxA(null, cast(char *) o.toString(), Error, MB_OK |
MB_ICONEXCLAMATION);
result = 0;// failed
}
return result;
}
int myWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR
lpCmdLine, int nCmdShow)
{
Foo foo = new Foo;
return (foo !is null);
}
class Foo
{
public:
this()
{
}
~this()
{
// This line causes memory allocation failure
auto writer = appender!string();
}
}
String Appender Fails (Memory Allocation Failure)
Hello! I've been working on a project where I had to do all memory handling explicitly because no destructors were called. When I got too tired of the explicit memory handling I decided to trace what was causing this error. After hours of code stripping I had gotten myself a small concrete sample which could demonstrate the error. Now to the point; I create a program using WinMain as entry point. The program template i use, is identical to the win32 template on the D-Website. If you have used this template you know that all user code goes within the function myWinMain. In this function I declare a class named Foo. When I create this class an empty constructor is called, and then the function myWinMain returns. Now the program calls Runtime.terminate, which is supposed to take care of the memory garbage and etc. This does not work. The terminate function call throws an Error, Memory Allocation Failure. This failure originates in the 'Foo' destructor, which in turn creates a appender object of type string. My question is; how come this throws an error?
Re: String Appender Fails (Memory Allocation Failure)
On 7/14/11 1:11 AM, Loopback wrote: Now the program calls Runtime.terminate, which is supposed to take care of the memory garbage and etc. This does not work. The terminate function call throws an Error, Memory Allocation Failure. This failure originates in the 'Foo' destructor, which in turn creates a appender object of type string. My question is; how come this throws an error? Currently, no memory can be allocated at all during garbage collection runs, which is where destructors are usually called. David
Re: String Appender Fails (Memory Allocation Failure)
On 2011-07-14 01:17, David Nadlinger wrote:
Currently, no memory can be allocated at all during garbage collection
runs, which is where destructors are usually called.
David
That explains it. Do you know when this feature will be available, if
at all?
Here is another interesting case, where I am using external libraries
(FMOD) in this case.
I have two different cases here, but they have two notable things in
common. Both use WinMain as entry point and they both originate in the
class Foo.
In the first case, I use the class Foo, which has the Sound
class as a private member. If foo omits the call to allocate the sound
class no Memory Allocation Failure occurs. This error is also avoided
if the two lines in the static destructor of sound is omitted:
FMOD_System_Close(m_system);
FMOD_System_Release(m_system);
How come these external functions generates a Memory Allocation Failure
when they use malloc for their memory allocation? Also worth noticing
is that in the non-static destructor FMOD_Sound_Release is called
without any problems, if the two function calls are omitted.
One other thing; how come no Memory Allocation Failure occurs, when
I do not allocate the sound class, since the static de-/constructors
of the class are still called?
In the second case, the exact same functions are called except that
everything takes place in-lined in the Foo constructor.
Case 1: Memory Allocation Failure and Sound destructor is not called.
Case 2: Everything works as expected.
// Import WINAPI
import win32.windows;
// Core API
import core.runtime;
import std.range;
import std.string;
// FMOD
import fmod.fmod;
extern (Windows) int WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPSTR lpCmdLine, int nCmdShow)
{
int result;
void exceptionHandler(Throwable e) { throw e; }
try
{
Runtime.initialize(exceptionHandler);
result = myWinMain(hInstance, hPrevInstance, lpCmdLine,
nCmdShow);
Runtime.terminate(exceptionHandler);
}
catch (Error o)
{
MessageBoxA(null, cast(char *) o.toString(), Error, MB_OK |
MB_ICONEXCLAMATION);
result = 0;// failed
}
return result;
}
int myWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine,
int nCmdShow)
{
Foo foo = new Foo;
return (foo !is null);
}
class Foo
{
public:
this()
{
//m_sound = new Sound(rC:\acdc.ogg);
}
~this()
{
MessageBoxA(null, Never Called, Error, MB_OK |
MB_ICONEXCLAMATION);
}
private:
Sound m_sound;
}
class Sound
{
public:
static this()
{
if(FMOD_System_Create(m_system) != FMOD_RESULT.FMOD_OK)
throw new Error(Failed to create fmod system.);
if(FMOD_System_Init(m_system, 2, FMOD_INIT_NORMAL, null) !=
FMOD_RESULT.FMOD_OK)
throw new Error(Failed to initialize fmod.);
}
static ~this()
{
// Close and release system (omitting these prevents any errors
from occuring)
FMOD_System_Close(m_system);
FMOD_System_Release(m_system);
}
this(string file)
{
if(FMOD_System_CreateSound(m_system, cast(char *)
file.toStringz, FMOD_HARDWARE | FMOD_LOOP_OFF, null, m_sound) !=
FMOD_RESULT.FMOD_OK)
throw new Error(Failed to create sound.);
}
~this()
{
// Release Sound
FMOD_Sound_Release(m_sound);
}
private:
static FMOD_SYSTEM * m_system;
FMOD_SOUND * m_sound;
}// Import WINAPI
import win32.windows;
// Core API
import core.runtime;
import std.range;
import std.string;
// FMOD
import fmod.fmod;
extern (Windows) int WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPSTR lpCmdLine, int nCmdShow)
{
int result;
void exceptionHandler(Throwable e) { throw e; }
try
{
Runtime.initialize(exceptionHandler);
result = myWinMain(hInstance, hPrevInstance, lpCmdLine,
nCmdShow);
Runtime.terminate(exceptionHandler);
}
catch (Error o)
{
MessageBoxA(null, cast(char *) o.toString(), Error, MB_OK |
MB_ICONEXCLAMATION);
result = 0;// failed
}
return result;
}
int myWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine,
int nCmdShow)
{
Foo foo = new Foo;
return (foo !is null);
}
class Foo
{
public:
this()
{
FMOD_SYSTEM * m_system;
FMOD_SOUND * m_sound;
if(FMOD_System_Create(m_system) != FMOD_RESULT.FMOD_OK)
throw
Re: template instance cannot use local 'f' as parameter to non-global template
On 7/14/2011 12:24 AM, Trass3r wrote:
Am 13.07.2011, 16:58 Uhr, schrieb Tyro[a.c.edwards] nos...@home.com:
Don't know it this is the right answer or a possible bug but it does
the trick:
void h() { import std.stdio; write(h()); }
class Bla
{
mixin wrap!h;
}
mixin template wrap(alias f)
{
void blub(typeof(f) g = f)
{
g();
}
}
void main()
{
Bla b = new Bla();
b.blub();
}
Thanks!
Unfortunately it doesn't work with more complex functions:
Error: arithmetic/string type expected for value-parameter, not
cl_errcode C function(cl_program program, uint param_name, ulong
param_value_size, void* param_value, ulong* param_value_size_ret)
I gusss the simplest example of the problem you're experiencing would be
this:
void h() { import std.stdio; write(h()); }
void function() fp = h;
class Bla
{
mixin wrap!(fp);
}
mixin template wrap(alias f)
{
void blub()
{
typeof(f) g = f;
g(); // --- source of error [1]
}
}
void main()
{
Bla b = new Bla();
b.blub();
}
edit1.d(19): Error: function expected before (), not g of type uint* C
function()*
[1] Here you are calling a function pointer which simply returns the
address of the function... hence your error!
Try calling the function (differencing the pointer as such: (*g)()) and
your problem is solved.
Re: template instance cannot use local 'f' as parameter to non-global template
On 7/14/2011 12:24 AM, Trass3r wrote:
Am 13.07.2011, 16:58 Uhr, schrieb Tyro[a.c.edwards] nos...@home.com:
Don't know it this is the right answer or a possible bug but it does
the trick:
void h() { import std.stdio; write(h()); }
class Bla
{
mixin wrap!h;
}
mixin template wrap(alias f)
{
void blub(typeof(f) g = f)
{
g();
}
}
void main()
{
Bla b = new Bla();
b.blub();
}
Thanks!
Unfortunately it doesn't work with more complex functions:
Error: arithmetic/string type expected for value-parameter, not
cl_errcode C function(cl_program program, uint param_name, ulong
param_value_size, void* param_value, ulong* param_value_size_ret)
I guess the simplest example of the problem you're experiencing would be
this:
void h() { import std.stdio; write(h()); }
void function() fp = h;
class Bla
{
mixin wrap!(fp);
}
mixin template wrap(alias f)
{
void blub()
{
typeof(f) g = f;
g(); // --- source of error [1]
}
}
void main()
{
Bla b = new Bla();
b.blub();
}
edit1.d(19): Error: function expected before (), not g of type void
function()*
[1] Here you are calling a function pointer which simply returns the
address of the function... hence your error!
Try calling the function pointed to by differencing the pointer as such:
(*g)() and your problem is solved.
tiny web server in D
While the following D program runs without compiler error, it seems unable to
serve a web page. Is there a better way?
import std.socket, std.string;
void main() {
Socket listener = new TcpSocket;
assert(listener.isAlive);
listener.bind(new InternetAddress(8080));
listener.listen(10);
string webpage = index.html;
Socket currSock;
uint bytesRead;
ubyte buff[1];
while(1) {
currSock = listener.accept();
while ((bytesRead = currSock.receive(buff)) 0) {
currSock.sendTo(webpage);
}
currSock.close();
buff.clear();
}
}
Re: tiny web server in D
On 14-7-2011 5:48, Dr.Smith wrote:
import std.socket, std.string;
void main() {
Socket listener = new TcpSocket;
assert(listener.isAlive);
listener.bind(new InternetAddress(8080));
listener.listen(10);
string webpage = index.html;
Socket currSock;
uint bytesRead;
ubyte buff[1];
while(1) {
currSock = listener.accept();
while ((bytesRead = currSock.receive(buff)) 0) {
currSock.sendTo(webpage);
}
currSock.close();
buff.clear();
}
}
I recieve
index.htmlindex.htmlindex.html etc etc
if I use this, it works
import std.socket, std.string;
void main() {
Socket listener = new TcpSocket;
assert(listener.isAlive);
listener.bind(new InternetAddress(8080));
listener.listen(10);
string webpage = htmlbodyhi/body/html;
Socket currSock;
uint bytesRead;
ubyte buff[1];
while(1) {
currSock = listener.accept();
if ((bytesRead = currSock.receive(buff)) 0) {
currSock.sendTo(webpage);
}
currSock.close();
buff.clear();
}
}
