On Friday, 16 March 2012 at 18:21:54 UTC, H. S. Teoh wrote:
void checkConsistency(T...)(T args, string file=__FILE__,
size_t line=__LINE__) { ... }
but this causes compile errors because when C==string, then the
call is
ambiguous.
Does it make sense to consider to a
On Sat, Mar 17, 2012 at 01:21:56AM +0100, Adam D. Ruppe wrote:
> On Saturday, 17 March 2012 at 00:13:33 UTC, H. S. Teoh wrote:
> >Playing around with it a little, I notice that it doesn't output
> >template bodies, even though calls to template functions are left
> >intact. It also doesn't expand [
On Saturday, 17 March 2012 at 00:13:33 UTC, H. S. Teoh wrote:
Playing around with it a little, I notice that it doesn't output
template bodies, even though calls to template functions are
left intact. It also doesn't expand [] into
opIndex/opIndexAssign,
I didn't play with this yet.. but it m
On Thu, Mar 15, 2012 at 02:51:33PM +0100, Adam D. Ruppe wrote:
> On Thursday, 15 March 2012 at 08:35:48 UTC, Jay Norwood wrote:
> >Is there some option, similar to -E gcc option, that would
> >generate the analogous listing for D?
>
> You could add one to the compiler in just
> a few lines; there'
On Fri, 16 Mar 2012 14:41:40 -0400, H. S. Teoh
wrote:
On Fri, Mar 16, 2012 at 02:30:25PM -0400, Steven Schveighoffer wrote:
[...]
I know this is already answered, but do you get a stack trace?
Shouldn't the second stack frame point to the offending line?
[...]
I didn't compile with debuggi
16.03.2012 20:35, H. S. Teoh пишет:
[...]
Actually, I found the solution: the compiler understands __FILE__ and
__LINE__ in compile-time arguments too, so this works: void
checkConsistency(string file=__FILE__, size_t line=__LINE__, T...)(T
args) { ... } It's a bit painful with the assert st
On Fri, Mar 16, 2012 at 02:30:25PM -0400, Steven Schveighoffer wrote:
[...]
> I know this is already answered, but do you get a stack trace?
> Shouldn't the second stack frame point to the offending line?
[...]
I didn't compile with debugging turned on, so it only showed a hex
address. Using compi
On Friday, 16 March 2012 at 18:31:58 UTC, Kevin Cox wrote:
But then you have to write it each time.
Nah, it just works, at least for the implicit calls:
checkConsistency(1, "2", 3); // calls checkConsistenct!(__FILE__,
__LINE__, int, string, int)(1, "2", 3);
On Fri, Mar 16, 2012 at 02:31:47PM -0400, Kevin Cox wrote:
> On Mar 16, 2012 2:29 PM, "Adam D. Ruppe" wrote:
> >
> > Put the string file = blaha in the template argument list,
> > before the variadic.
> >
> > voic checkConsistency(string file = __FILE__, int line = __LINE__,
> T...)(T t) {
> >
> >
On Fri, 16 Mar 2012 14:23:37 -0400, H. S. Teoh
wrote:
I'm writing some unittests with very repetitive tests for a myriad of
different types, so I wrote a helper function:
version(unittest) {
void checkConsistency(T...)(T args) {
foreach (a; arg
On Fri, Mar 16, 2012 at 08:26:30PM +0200, Mantis wrote:
> 16.03.2012 20:23, H. S. Teoh пишет:
> >I'm writing some unittests with very repetitive tests for a myriad of
> >different types, so I wrote a helper function:
> >
> > version(unittest) {
> > void checkConsistency(T...)(T args
On Mar 16, 2012 2:29 PM, "Adam D. Ruppe" wrote:
>
> Put the string file = blaha in the template argument list,
> before the variadic.
>
> voic checkConsistency(string file = __FILE__, int line = __LINE__,
T...)(T t) {
>
>
But then you have to write it each time.
On Friday, 16 March 2012 at 18:21:54 UTC, H. S. Teoh wrote:
void checkConsistency(T...)(T args, string file=__FILE__,
size_t line=__LINE__) { ... }
but this causes compile errors because when C==string, then the
call is
ambiguous.
Is there an easy of working around thi
16.03.2012 20:23, H. S. Teoh пишет:
I'm writing some unittests with very repetitive tests for a myriad of
different types, so I wrote a helper function:
version(unittest) {
void checkConsistency(T...)(T args) {
foreach (a; args) {
I'm writing some unittests with very repetitive tests for a myriad of
different types, so I wrote a helper function:
version(unittest) {
void checkConsistency(T...)(T args) {
foreach (a; args) {
assert(isConsistent(a))
On Friday, 16 March 2012 at 08:23:39 UTC, dv wrote:
I do not wish to spend time learning something with a shoddy
base. If I am to port or create projects with the language, I
need solid architecture and compiler support. Can some D users
enlighten me about the current state? Platforms I wish t
On Friday, 16 March 2012 at 08:34:18 UTC, Dmitry Olshansky wrote:
Ehm, because they have different engines that _should_ give
identical results. And the default one apparently has a bug,
that I'm looking into.
Fill the bug report plz.
Ok, submitted: id 7718
Thanks,
Josh
On 2012-03-16 09:08, Jonathan M Davis wrote:
On Friday, March 16, 2012 08:52:47 Jacob Carlborg wrote:
On 2012-03-16 04:52, James Miller wrote:
Also, git-svn isn't actually that bad...
It is. You can't properly use git because you have to make sure it's
compatible with svn, like linear history
On 16.03.2012 7:36, Joshua Niehus wrote:
Hello,
Does anyone know why I would get different results between
ctRegex and regex in the following snippet?
Ehm, because they have different engines that _should_ give identical
results. And the default one apparently has a bug, that I'm looking into
Hello, I am currently evaluating D2, and have questions.
Language-wise, D2 looks very interesting to me. I do have
concerns about the toolchain and architecture support, however.
First of all, there is DMD, LDC, GDC. Of these three, LDC seems
to be preferred. x86-64 support is apparently soli
On Friday, March 16, 2012 08:52:47 Jacob Carlborg wrote:
> On 2012-03-16 04:52, James Miller wrote:
> > Also, git-svn isn't actually that bad...
>
> It is. You can't properly use git because you have to make sure it's
> compatible with svn, like linear history. If you don't have a linear
> history
On 2012-03-16 04:52, James Miller wrote:
Also, git-svn isn't actually that bad...
It is. You can't properly use git because you have to make sure it's
compatible with svn, like linear history. If you don't have a linear
history you're in big trouble.
--
/Jacob Carlborg
22 matches
Mail list logo
