Re: Need help in templates
On 3/25/2011 3:34 AM, Regan Heath wrote: FYI.. that's uuencoded data: http://en.wikipedia.org/wiki/Uuencoding it's one of the older style encodings used by NNTP. Most readers should support it. Oddly enough, Thunderbird is one that doesn't.
Re: C++ to D: mutable
On 3/24/2011 12:23 AM, Caligo wrote: Greetings, I have a C++ class that I would like to rewrite it in D. The class has members that are declared as 'mutable'. How do I achieve the same effect in D? if not, what is recommended? You don't. Specific recommendations would depend on how the class is used.
Re: Bug w/tuple of custom types?
On 3/23/2011 12:45 PM, Magnus Lie Hetland wrote: Any way to do that without (to be deprecated) typedef? Nothing pretty, at least not yet. bearophile's suggestion is about as close as you can get right now.
Dependencies file format
After some searching, I found the documentation here: http://d.puremagic.com/issues/show_bug.cgi?id=3122 Shouldn't this be on the web site somewhere?
Re: .di header imports with DLL symbols fails to link
On 3/12/2011 7:02 PM, Andrej Mitrovic wrote: My commands to compile were: dmd -ofmydll.dll mydll.d dmd -o- -Hdinclude mydll.d dmd driver.d mydll.lib -I%cd%\include Thanks. I've tried several things, but can't get the _D5mydll12__ModuleInfoZ symbol to show up at all. The behavior is the same with and without a .def file (I tried a few versions). I even went back to http://www.digitalmars.com/d/2.0/dll.html and copied everything in the "D code calling D code in DLLs" section verbatim. After fixing a few compilation errors (the web page's version of concat needs its arguments qualified with "in"), I ended up with the exact same problem you're experiencing. I'd definitely call this a bug.
Re: .di header imports with DLL symbols fails to link
On 3/12/2011 5:24 PM, Andrej Mitrovic wrote: driver.obj(driver) Error 42: Symbol Undefined _D5mydll12__ModuleInfoZ --- errorlevel 1 Your dll is exporting a different symbol: _D5mydll3fooFiZi Do you have the .def file and the command line used to build the DLL?
Re: Ranges
Or, better yet, just read Jonathan's post.
Re: Ranges
On 3/12/2011 2:02 PM, Jonas Drewsen wrote: Error message: test2.d(13): Error: template std.algorithm.copy(Range1,Range2) if (isInputRange!(Range1) && isOutputRange!(Range2,ElementType!(Range1))) does not match any function template declaration test2.d(13): Error: template std.algorithm.copy(Range1,Range2) if (isInputRange!(Range1) && isOutputRange!(Range2,ElementType!(Range1))) cannot deduce template function from argument types !()(char[],char[]) I haven't checked (could be completely off here), but I don't think that char[] counts as an input range; you would normally want to use dchar instead.
Re: Points and Vectors in 3D
On 3/12/2011 2:20 PM, Simon wrote: I've done lots of 3d over the years and used quite a lot of different libraries and I've come to prefer code that makes a distinction between points and vectors. Agreed. This has some nice benefits with operator overloading, as well: vec v = ...; pt p = ...; auto p2 = p + v;// p2 is pt auto p3 = p + p2; // error auto v2 = v + v;// v2 is vec ...and with properties: p.x = 5;// p is pt, sets p._vals[0] v.dx = 3; // v is vec, sets v._vals[0]
Re: Some weird crashes
On 3/8/2011 12:57 PM, simendsjo wrote: One more thing.. Function pointers in structs.. Should they use extern(Windows) too? Yes.
Re: No case ranges in final switches?
On 3/6/2011 1:11 PM, bearophile wrote:
Do you know why final switches disallow case ranges? Case ranges are not
bug-prone:
void main() {
ubyte u;
final switch (u) {
case 0: .. case 100:
break;
case 101: .. case 255:
break;
}
}
Final switch is really just meant to be used with enums; since
enumeration values don't have to cover the whole range of possible base
type values, and enumeration values don't often have a natural ordering,
ranges make little sense there.
Re: htod and system files
On 3/4/2011 3:31 PM, simendsjo wrote: The htod page, http://www.digitalmars.com/d/2.0/htod.html, says that system files will be included using the -hs option. htod mysql.h -hs Fatal error: unable to open input file 'sys/types.h' Does it try to find these files through an environment variable? htod is compatible with the -I and -D compiler switches from dmc. Use -I to reference to the directory containing the system headers you want to use.
Re: C const
On 3/4/2011 11:19 AM, simendsjo wrote: It also says "char const* q". Is "const char*" the same thing in C? For reference: In C, const T* x is the same as T const* x; both declare a mutable pointer to const T. T* const x declares a const pointer to mutable T, for which D has no analogue. In D, const T* x declares a const pointer to const T, which differs from the C syntax. In C, that would be const T* const x (or T const * const x). Thank God for D.
Re: Parameterized Structs
On 3/2/2011 8:56 PM, Peter Lundgren wrote:
Where can I go to learn about parameterized structs? I can't seem to find any
literature on the subject. In particular, what are you allowed to use as a
parameter? I would like to define a struct like so:
struct MyStruct(T, T[] a) {
...
}
but I receive the following error:
Error: arithmetic/string type expected for value-parameter, not T[]
Are arrays not allowed?
This compiles:
struct MyStruct(T : T[], T a)
{
T A = a.dup;
}
...but I have yet to figure out how to properly invoke it.
Re: Some weird crashes
On 3/2/11 10:52 AM, simendsjo wrote: I couldn't find a free download for coff2omf, that's why I don't use the supplied .lib. You can use coffimplib: ftp://ftp.digitalmars.com/coffimplib.zip
Re: About const and C functions
On 3/2/11 4:06 AM, bearophile wrote: Can't D/DMD err on the side of safety and consider the C-style variadic argument as not const, and so produce an error if you give to them something that's D const/immutable (and require a cast there)? (Especially a function like sscanf where the third and successive arguments are known to be modified). With an annotation on the function signature, perhaps, and certainly it should do this at all times in code marked @safe.
Re: Constructor template -- bug?
On 3/1/2011 11:47 PM, Jonathan M Davis wrote:
I should also point out that there is absolutely no need to use template for
what you're trying to do. Just declare the constructor like so:
this(string message, string file = __FILE__, size_t line = __LINE__ Throwable
next = null) { ... }
You are absolutely right; silly me. I'd assumed that would pick up the
file and line at the point of declaration...
Constructor template -- bug?
Code:
class MyException : Exception
{
this(string message, string file, size_t line, Throwable next =
null)
{
super(message, file, line, next);
}
this(string file = __FILE__, size_t line = __LINE__)(string message,
Throwable next = null)
{
this(message, file, line, next);
}
}
void main()
{
throw new MyException("Bluh!");
}
Error message:
test.d(8): Error: template test.MyException.__ctor(string file =
__FILE__,size_t line = __LINE__) conflicts with constructor
test.MyException.this at test.d(3)
If I remove the normal constructor and call super instead of this from
the constructor template, then I get this slightly different error message:
test.d(1): Error: constructor test.MyException.this conflicts with
template test.MyException.__ctor(string file = __FILE__,uint line =
__LINE__) at test.d(3)
Is this a compiler bug, or am I Doing It Wrong?
Re: comparing pointers passed to and returned from funcs
On 3/1/2011 4:12 PM, bearophile wrote: Bekenn: I'd remove those parens; you don't want people modifying TRUE or FALSE. Please, show me working code that implements your idea :-) Bye, bearophile Here you go; I only changed the one line. Compiles and works just fine in dmd 2.051. const Foo* TRUE, FALSE; instead of const(Foo)* TRUE, FALSE;
Re: About const and C functions
On 3/1/2011 2:33 PM, bearophile wrote:
Do you know why DMD doesn't give a compilation error here?
import core.stdc.stdio: sscanf;
immutable int value = 5;
void main() {
sscanf("10".ptr, "%d".ptr,&value);
}
Bye,
bearophile
I'm not sure that's checkable. I think this falls squarely into the
realm of "undefined behavior".
Re: comparing pointers passed to and returned from funcs
On 3/1/11 5:31 PM, bearophile wrote: Bekenn: Touche. I'll have to test that out once I get back from work... Sorry for that answer of mine, we are here to learn and cooperate, not to fight :-) It's just I sometimes have problems with const things in D, and sometimes DMD has problems with const things. Hey, no problem; I thought it was funny...
Re: comparing pointers passed to and returned from funcs
On 3/1/11 4:12 PM, bearophile wrote: Bekenn: I'd remove those parens; you don't want people modifying TRUE or FALSE. Please, show me working code that implements your idea :-) Touche. I'll have to test that out once I get back from work...
Re: comparing pointers passed to and returned from funcs
On 3/1/11 3:00 PM, bearophile wrote: const(Foo)* TRUE, FALSE; I'd remove those parens; you don't want people modifying TRUE or FALSE.
Re: string vs. w/char*
On 3/1/2011 12:25 AM, Tyro[a.c.edwards] wrote: Nevertheless, execution haults at the very next line following/catch and Create() never returns. CreateWindow sends a few messages to your window proc; anything interesting happening there?
Re: Ini parsing library in D ?
On 2/27/2011 11:04 PM, Tarun Ramakrishna wrote: Hi, Do we have a ini parser in D somewhere ? If not, is there some documentation anywhere that tells one how to wrap a simple C++ library like simple ini ? (Of course it isn't difficult to build a quick parser, just that someone would done this already) Thanks, Tarun You can give htod a try: http://www.digitalmars.com/d/2.0/htod.html It's not perfect, but it may give you a decent starting point to work from.
Re: Defining type coercion
On 2/27/2011 12:10 PM, Peter Lundgren wrote:
I'd like to define a type Ordinal which behaves like an int (using a struct or
alias) that represents the 26 letters, A-Z, with the numbers 1-26. Then, I
would like to be able to coerce between chars and Ordinals appropriately.
chars and ints already have the ability to coerce between each other using the
appropriate ASCII values. So, really, I'd just like to define a type that
overrides this behavior.
As far as I can tell, the place to define such rules is with opCast!, but I'm
at a loss for how to add additional rules to built in types.
I haven't tried anything like this yet (I'm still pretty new to D), but
I think something like this is the best you'll be able to do:
struct Ordinal
{
this(int value) { m_Value = value; }
this(dchar ch) { m_Value = ch - 'a' + 1; } // add range checks as
appropriate
alias this m_Value;
T opCast(T)() if (T is dchar) { return m_Value + 'a' - 1; }
// add more operators as appropriate
private:
int m_Value;
}
Re: Initializing a class pointer
On 2/26/2011 5:33 PM, Tyro[a.c.edwards] wrote:
Ok, that's essentially what I have, except that I used Controller pCtrl
vice auto. WinGetLong however, is a template that calls
GetWindowLongPtrA() and casts it's result (in this case) to Controller.
GetWindowLongPtrA() returns LONG_PTR (aka int) and therefore fails
miserably on the cast attempt. On the reverse, there is a WinSetLong
that attempts to cast Controller to int for use with
SetWindowLongPtrA(). Neither of these functions complain when I use
Controller* but I end up with the problem of trying to initialize a
pointer with a reference to Controller.
By the way, in original C++ code WinGetLong and WinSetLong are both
using a reinterpret_cast to achieve this monkey magic. To the best of my
knowledge, there is no reinterpret_cast facility in D. So the question
would be, why would it have been necessary to use reinterpret_cast in
the first place and how can similar effect be obtained in D? What was
being reinterpreted? Was it the address of the class or the value some
private value contained therein?
What you need here is a double cast; class references can be cast to
void*, and from there to LONG_PTR. The reverse also works:
auto WinGetLong(T)(HWND hwnd)
{
return cast(T)cast(void*)GetWindowLongPtrA(hwnd, GWLP_USERDATA);
}
void WinSetLong(T)(HWND hwnd, T o)
{
SetWindowLongPtrA(hwnd, GWLP_USERDATA, cast(LONG_PTR)cast(void*)o;
}
Re: Interfacing with c and platform dependent sizes
On 2/25/2011 7:24 PM, Steven Schveighoffer wrote: BTW, I think long long is a gnu extension, it's not standard C (I don't think long long exists in Visual C for instance). I'm pretty sure it's standard as of C99 (though not yet for C++; that's coming with C++0x). MSVC does indeed support it.
Re: Additional path for libs
Apologies for the late reply, but this could help: As you've already seen in the other replies, the provided sc.ini file is confounding your attempts at setting the LIB environment variable. However, OPTLINK's search path for sc.ini includes the current directory, so if you're reluctant to alter the original file, you can just create an empty sc.ini in the current directory. You are then free to redefine LIB and DFLAGS to whatever you like. Here's an excerpt from one of my makefiles (I use Microsoft's NMAKE): $(EXECUTABLE) : sc.ini $(SOURCES) $(D) $(SOURCES) $(LIBS) $(DFLAGS) $(DEXEFLAGS) @move /y "$(APPNAME).map" $(@D) > NUL sc.ini : @copy NUL sc.ini
wstring format
Is there a wstring version of string.format? I can't seem to find it anywhere...
