On Friday, 28 June 2013 at 00:48:23 UTC, Steven Schveighoffer
wrote:
On Thu, 27 Jun 2013 20:34:53 -0400, JS
wrote:
Would it be possible for a language(specifically d) to have
the ability to automatically type a variable by looking at its
use cases without adding too much complexity? It seems
On 6/27/13 9:42 PM, Maxime Chevalier-Boisvert wrote:
I'd like to stack-allocate an array that will be dynamically sized. Is
alloca somewhere in the standard D library? If so, what should I import
to have access to it?
Yah, import core.stdc.stdlib.
Andrei
On Thursday, 27 June 2013 at 20:24:46 UTC, Nick Sabalausky wrote:
but auto can be used in paramenters too.
It can? Cool!
Actually I meant "dmd does not support the feature now, but I see
no reason for not supporting it".
I'd like to stack-allocate an array that will be dynamically
sized. Is alloca somewhere in the standard D library? If so, what
should I import to have access to it?
On Friday, 28 June 2013 at 02:34:01 UTC, Juan Manuel Cabo wrote:
On 06/27/2013 10:12 PM, Milvakili wrote:
I have successfully link c++ with D.
Have ever when I create a dependency:
cpp2->cpp1->d
when compile with dmd
dmd cpp1.a cpp2.a file.d -L-lstdc++
I tried it and it works _perfectly_ fo
On 28/06/13 11:47, Jonathan M Davis wrote:
On Friday, June 28, 2013 10:44:36 Peter Williams wrote:
On 28/06/13 05:52, Jonathan M Davis wrote:
On Thursday, June 27, 2013 13:47:53 Adam D. Ruppe wrote:
On Thursday, 27 June 2013 at 06:59:49 UTC, Jonathan M Davis wrote:
But if we make a design dec
On 06/27/2013 10:12 PM, Milvakili wrote:
> I have successfully link c++ with D.
>
> Have ever when I create a dependency:
> cpp2->cpp1->d
>
> when compile with dmd
>
> dmd cpp1.a cpp2.a file.d -L-lstdc++
I tried it and it works _perfectly_ for me, but instead of .a I
compiled the C++ files to .
On Friday, 28 June 2013 at 01:42:35 UTC, Milvakili wrote:
On Friday, 28 June 2013 at 01:39:49 UTC, Adam D. Ruppe wrote:
On Friday, 28 June 2013 at 01:12:11 UTC, Milvakili wrote:
relocation error: "some path": symbol _ZNSsC1EPKcRKSaIcE,
version GLIBCXX_3.4 not defined in file libstdc++.so.6 with
On Friday, June 28, 2013 10:44:36 Peter Williams wrote:
> On 28/06/13 05:52, Jonathan M Davis wrote:
> > On Thursday, June 27, 2013 13:47:53 Adam D. Ruppe wrote:
> >> On Thursday, 27 June 2013 at 06:59:49 UTC, Jonathan M Davis wrote:
> >>> But if we make a design decision that favors 1% of our user
On Friday, 28 June 2013 at 01:39:49 UTC, Adam D. Ruppe wrote:
On Friday, 28 June 2013 at 01:12:11 UTC, Milvakili wrote:
relocation error: "some path": symbol _ZNSsC1EPKcRKSaIcE,
version GLIBCXX_3.4 not defined in file libstdc++.so.6 with
link time reference
did you compile the C++ and run the
On Friday, 28 June 2013 at 01:12:11 UTC, Milvakili wrote:
relocation error: "some path": symbol _ZNSsC1EPKcRKSaIcE,
version GLIBCXX_3.4 not defined in file libstdc++.so.6 with
link time reference
did you compile the C++ and run the program on the same computer?
This is complaining that it cou
I have successfully link c++ with D.
Have ever when I create a dependency:
cpp2->cpp1->d
when compile with dmd
dmd cpp1.a cpp2.a file.d -L-lstdc++
It compiles but when I run it I get
relocation error: "some path": symbol _ZNSsC1EPKcRKSaIcE, version
GLIBCXX_3.4 not defined in file libstdc++.s
JS:
in this case x and y's type is inferred from future use. The
compiler essentially just lazily infers the variable type.
Obviously ambiguity will generate an error.
Do you mean the flow-sensitive typing of the Whiley language?
http://whiley.org/guide/typing/flow-typing/
It's surely neat.
On Thu, 27 Jun 2013 20:34:53 -0400, JS wrote:
Would it be possible for a language(specifically d) to have the ability
to automatically type a variable by looking at its use cases without
adding too much complexity? It seems to me that most compilers already
can infer type mismatchs which w
I believe it would be possible. D does something similar for auto
return values on functions already. Might be a bit of work in
the compiler though.
On 28/06/13 05:52, Jonathan M Davis wrote:
On Thursday, June 27, 2013 13:47:53 Adam D. Ruppe wrote:
On Thursday, 27 June 2013 at 06:59:49 UTC, Jonathan M Davis wrote:
But if we make a design decision that favors 1% of our userbase
I really think we all need to be more careful about these kind
Would it be possible for a language(specifically d) to have the
ability to automatically type a variable by looking at its use
cases without adding too much complexity? It seems to me that
most compilers already can infer type mismatchs which would allow
them to handle stuff like:
main()
{
On 27/06/13 23:33, bearophile wrote:
Andrej Mitrovic:
Yeah but it's not always possible to know what the formatting string
is. For example, maybe you have an enum array of format strings but a
runtime index into this array which you pass to format at runtime.
I've ported C samples before that u
On Thursday, 27 June 2013 at 22:12:49 UTC, Nick B wrote:
On Sunday, 23 June 2013 at 15:22:22 UTC, Jacob Carlborg wrote:
On 2013-06-23 15:12, qznc wrote:
That would be SystemTap on Linux. However, I wonder if it is
the right
tool for the job.
[snip]
here is a comparion of Systemtap and D
On Thursday, 27 June 2013 at 21:56:00 UTC, H. S. Teoh wrote:
On Thu, Jun 27, 2013 at 11:48:15PM +0200, Idan Arye wrote:
On Thursday, 27 June 2013 at 20:43:47 UTC, H. S. Teoh wrote:
>That's something I never really understood about the Windows
>/ GUI
>world. The backend functionality is already
On Tuesday, 25 June 2013 at 22:22:09 UTC, cybervadim wrote:
I know Andrey mentioned he was going to work on Allocators a
year ago. In DConf 2013 he described the problems he needs to
solve with Allocators. But I wonder if I am missing the
discussion around that - I tried searching this forum, f
On Thu, Jun 27, 2013 at 11:48:15PM +0200, Idan Arye wrote:
> On Thursday, 27 June 2013 at 20:43:47 UTC, H. S. Teoh wrote:
> >That's something I never really understood about the Windows / GUI
> >world. The backend functionality is already all there, yet for some
> >strange reason the application re
On Thursday, 27 June 2013 at 20:43:47 UTC, H. S. Teoh wrote:
That's something I never really understood about the Windows /
GUI
world. The backend functionality is already all there, yet for
some
strange reason the application refuses to have the means to
access that
functionality, requiring in
On Thursday, 27 June 2013 at 20:43:47 UTC, H. S. Teoh wrote:
clip
That's something I never really understood about the Windows /
GUI
world. The backend functionality is already all there, yet for
some
strange reason the application refuses to have the means to
access that
functionality, requ
On Thursday, 27 June 2013 at 03:47:39 UTC, Jonathan M Davis wrote:
That's _very_ dependent on what the function does. A prime
counter-example
would be overloaded operators like opBinary which uses their
string template
arguments in mixins within the function, thereby generating
completely
diffe
On Sat, 22 Jun 2013 06:27:34 +0200
"QAston" wrote:
> On Thursday, 20 June 2013 at 12:16:54 UTC, deadalnix wrote:
> >
> > Which lead to TITMOD, test in the middle of dev.
>
> You should write a book on that, it'd be a total paradigm shift
> for the non-yet-believers of TITMOD.
The coolest acron
On Thu, 20 Jun 2013 00:15:50 +0200
"Szymon Gatner" wrote:
> On Wednesday, 19 June 2013 at 21:59:21 UTC, Jonathan M Davis
> wrote:
> >
> > I _do_ agree with writing the tests fora function as soon as
> > the function is
> > done, in which case, you're likely going to have to do more
> > work on
On Thu, Jun 27, 2013 at 10:20:59PM +0200, Idan Arye wrote:
> On Thursday, 27 June 2013 at 04:15:27 UTC, H. S. Teoh wrote:
> >Anything else is just the formula for endless frustration,
> >untraceable bugs, and project failure. If your IDE's build function
> >doesn't support full end-to-end reproduci
On Thu, 27 Jun 2013 19:58:58 +0200
"Maxim Fomin" wrote:
> On Thursday, 27 June 2013 at 17:42:14 UTC, bearophile wrote:
> > (This is an extended repost of a message that I have put in
> > D.learn.)
> >
> > Sometimes I have code like this:
> >
> > struct VeryLongNamedStruct {}
> > void foo(in Very
On Thursday, 27 June 2013 at 04:15:27 UTC, H. S. Teoh wrote:
Anything else is just the formula for endless frustration,
untraceable
bugs, and project failure. If your IDE's build function doesn't
support
full end-to-end reproducible builds, it's worthless and should
be
thrown out.
The IDE's
On Thursday, June 27, 2013 13:47:53 Adam D. Ruppe wrote:
> On Thursday, 27 June 2013 at 06:59:49 UTC, Jonathan M Davis wrote:
> > But if we make a design decision that favors 1% of our userbase
>
> I really think we all need to be more careful about these kinds
> of statements. I often see posts o
On Thursday, 27 June 2013 at 19:22:08 UTC, bearophile wrote:
(also why is it 1-based?):
It is specified that way in the Single Unix Specification for
format strings.
I'm not sure why they did it that way, but if we changed it, that
would be surprising since the format string is otherwise si
Andrei Alexandrescu:
But the bottom line is I don't think we need to force anything
on anybody. If anything, we could split up the internal format
implementation and provide format and safeFormat functions.
format("%s %s", 1); // no exceptions
NO! This is exactly the kind of code that is bu
On Thursday, 27 June 2013 at 17:42:14 UTC, bearophile wrote:
(This is an extended repost of a message that I have put in
D.learn.)
Sometimes I have code like this:
struct VeryLongNamedStruct {}
void foo(in VeryLongNamedStruct x = VeryLongNamedStruct(1)) {}
void main() {}
Or even:
void bar(in
(This is an extended repost of a message that I have put in
D.learn.)
Sometimes I have code like this:
struct VeryLongNamedStruct {}
void foo(in VeryLongNamedStruct x = VeryLongNamedStruct(1)) {}
void main() {}
Or even:
void bar(in TupleFoo x = TupleFoo(TupleBar(2), TupleSpam(3))) {}
In thos
On Wednesday, 26 June 2013 at 23:59:01 UTC, Adam D. Ruppe wrote:
On Wednesday, 26 June 2013 at 23:02:47 UTC, H. S. Teoh wrote:
Maybe a type distinction akin to C++'s auto_ptr might help?
It might not be so bad if we modified D to add a lent storage
class, or something, similar to some discuss
On 06/27/13 13:16, Nicolas Sicard wrote:
> On Wednesday, 26 June 2013 at 20:50:03 UTC, bearophile wrote:
>> If you want a special behavour you should use a special function as
>> partialWritefln that ignores arguments not present in the format string.
>
> Or maybe just define a new format specifi
On 2013-06-27 05:35:11 +, Timothee Cour said:
See [1][2] for related thread introducing extern(objective C)
A)
The syntax proposed in [2] transforms:
-(void) insertItemWithObjectValue: (NSString *) path atGreen:(NSInteger)
anInt;
[obj insertItemWithObjectValue:val atGreen:idx ];
into:
voi
Andrej Mitrovic:
Yeah but it's not always possible to know what the formatting
string
is. For example, maybe you have an enum array of format strings
but a
runtime index into this array which you pass to format at
runtime.
I've ported C samples before that used this style of formatting.
In
On 6/27/13, Adam D. Ruppe wrote:
> I think if there's going to be a new function anyway, it might as
> well be more like the ctFormat bearophile mentioned, and check it
> at compile time.
Yeah but it's not always possible to know what the formatting string
is. For example, maybe you have an enum
On 6/27/13, Andrej Mitrovic wrote:
> On 6/27/13, Andrei Alexandrescu wrote:
>> NO! This is exactly the kind of code that is buggy and useless. The
>> right use cases involve more arguments than format specifiers.
>
> I mistyped that, I meant:
>
> format("%s", 1, 2); // no exceptions in future re
On Thursday, 27 June 2013 at 13:11:55 UTC, Andrej Mitrovic wrote:
I mistyped that, I meant:
format("%s", 1, 2); // no exceptions in future release
safeFormat("%s", 1, 2); // exception thrown
I think if there's going to be a new function anyway, it might as
well be more like the ctFormat bea
On 6/27/13, Andrei Alexandrescu wrote:
> NO! This is exactly the kind of code that is buggy and useless. The
> right use cases involve more arguments than format specifiers.
I mistyped that, I meant:
format("%s", 1, 2); // no exceptions in future release
safeFormat("%s", 1, 2); // exception th
On Thursday, 27 June 2013 at 05:35:28 UTC, Timothee Cour wrote:
See [1][2] for related thread introducing extern(objective C)
A)
The syntax proposed in [2] transforms:
-(void) insertItemWithObjectValue: (NSString *) path
atGreen:(NSInteger)
anInt;
[obj insertItemWithObjectValue:val atGreen:idx
On 2013-06-27 07:35, Timothee Cour wrote:
See [1][2] for related thread introducing extern(objective C)
A)
The syntax proposed in [2] transforms:
-(void) insertItemWithObjectValue: (NSString *) path atGreen:(NSInteger)
anInt;
[obj insertItemWithObjectValue:val atGreen:idx ];
into:
void insertIt
On Thursday, 27 June 2013 at 06:59:49 UTC, Jonathan M Davis wrote:
But if we make a design decision that favors 1% of our userbase
I really think we all need to be more careful about these kinds
of statements. I often see posts on the newsgroup where someone
says "feature/function X is totall
Jonathan M Davis:
Andrei Alexandrescu:
The only point I'd negotiate would be to not throw with
positional arguments, and throw with sequential arguments.
All code that cares uses positional specifiers anyway.
That sounds like a good compromise.
OK :-)
Bye,
bearophile
On Wednesday, 26 June 2013 at 20:50:03 UTC, bearophile wrote:
If you want a special behavour you should use a special
function as partialWritefln that ignores arguments not present
in the format string.
Or maybe just define a new format specifier (%z, for 'zap'?) to
ignore one or more argumen
On Wednesday, 26 June 2013 at 18:08:10 UTC, bearophile wrote:
[cut]
The most common problem they find are errors in the format
string of printf-like functions (despite the code is C++):
The top type of bug that /analyze finds is format string errors
– mismatches between printf-style format str
On Tuesday, 28 May 2013 at 00:11:18 UTC, Walter Bright wrote:
Every time I've been to a programming shop in a foreign
country, the developers speak english at work and code in
english. Of course, that doesn't mean that everyone does, but
as far as I can tell the overwhelming bulk is done in eng
On Thursday, 30 May 2013 at 11:29:47 UTC, Manu wrote:
Have you ever worked on code written by people who barely speak
English?
I did. It's better than having a mixture of languages like here:
http://code.google.com/p/trileri/source/browse/trunk/tr/yazi.d
assert(length == dizgi.length); - in o
On Thursday, 27 June 2013 at 02:17:09 UTC, Andrei Alexandrescu
wrote:
On 6/26/13 1:31 PM, Andrej Mitrovic wrote:
On 6/26/13, Andrei Alexandrescu
wrote:
Actually this is good because it allows to customize the
format string
to print only a subset of available information (I've
actually used th
On 6/21/2013 4:10 AM, Paulo Pinto wrote:
Except not everyone has the authorization to place their work code in such
public places nor the availability or desire to code after work, just to please
job interviewers.
True, but your odds of being 'discovered' go up enormously if you make such an
e
On Thursday, 27 June 2013 at 07:33:16 UTC, Paulo Pinto wrote:
On Wednesday, 26 June 2013 at 22:56:41 UTC, Walter Bright wrote:
On 6/26/2013 2:47 PM, Paulo Pinto wrote:
I have been an adept of iostreams since day one and never
understood why people
complain so much about them or the operator<<
On Wednesday, 26 June 2013 at 22:04:39 UTC, H. S. Teoh wrote:
On Wed, Jun 26, 2013 at 11:47:32PM +0200, Paulo Pinto wrote:
Am 26.06.2013 20:52, schrieb H. S. Teoh:
[...]
>None of my C++ code uses iostream. I still find stdio.h more
>comfortable to use, in spite of its many problems. One of the
On Thursday, 27 June 2013 at 06:59:49 UTC, Jonathan M Davis wrote:
ad populum obviously isn't enough. But if we make a design
decision that
favors 1% of our user base and causes problems for the other
99%, then I think
that we've made a big mistake. And while having most everyone
disagree with
On Wednesday, 26 June 2013 at 22:56:41 UTC, Walter Bright wrote:
On 6/26/2013 2:47 PM, Paulo Pinto wrote:
I have been an adept of iostreams since day one and never
understood why people
complain so much about them or the operator<< and operator>>
for that matter.
Even if you can get past the
On Thursday, 27 June 2013 at 02:25:54 UTC, Andrei Alexandrescu
wrote:
On 6/26/13 2:47 PM, Paulo Pinto wrote:
Am 26.06.2013 20:52, schrieb H. S. Teoh:
On Wed, Jun 26, 2013 at 08:08:08PM +0200, bearophile wrote:
An interesting blog post found through Reddit:
http://randomascii.wordpress.com/201
On 6/26/13 11:59 PM, Jonathan M Davis wrote:
I'm just pointing out that ignoring what the majority
thinks is not necessarily a good idea.
Of course. In this case it is.
Andrei
On 6/26/13 11:59 PM, Jonathan M Davis wrote:
On Wednesday, June 26, 2013 23:47:15 Andrei Alexandrescu wrote:
That
behavour is surprising, and it risks hiding some information silently.
Doesn't surprise me one bit.
Well, it shocks most of us.
I'm also not moved by argumentum ad populum.
a
On Wednesday, June 26, 2013 23:47:15 Andrei Alexandrescu wrote:
> >>> That
> >>> behavour is surprising, and it risks hiding some information silently.
> >>
> >> Doesn't surprise me one bit.
> >
> > Well, it shocks most of us.
>
> I'm also not moved by argumentum ad populum.
ad populum obviousl
61 matches
Mail list logo
