Am 22.08.2014 00:48, schrieb Brian Schott:
On Thursday, 21 August 2014 at 22:35:18 UTC, Sönke Ludwig wrote:
Destroy away! ;)
source/stdx/data/json/lexer.d(263:8)[warn]: 'JSONToken' has method
'opEquals', but not 'toHash'.
source/stdx/data/json/lexer.d(499:65)[warn]: Use parenthesis to clarify
"Joakim" wrote in message news:ynfwlptfuzfutksbn...@forum.dlang.org...
Yes, I'm aware of ddmd. You've mentioned many times that it only works
because dmd is written using a very unC++-like style, to the point where
github's source analyzer claims that dmd is written in 66.7% C, 28.4% D
(pres
On 21/08/14 20:07, Brad Anderson wrote:
On Thursday, 21 August 2014 at 17:55:19 UTC, Timothee Cour via
Digitalmars-d wrote:
http://dlang.org/cpptod.html#raii mentions scope class and scope
variables,
which seem deprecated (http://dlang.org/deprecate.html)
https://github.com/D-Programming-Langu
Jacob Carlborg:
How about we undeprecate it instead. If I recall correctly then
DDMD depends on it.
I think the idea is to discourage their usage as much as possible
in user code, until (someday, perhaps) some memory area tracking
system is implemented.
Bye,
bearophile
On Friday, 22 August 2014 at 07:48:30 UTC, Daniel Murphy wrote:
So no, you can't magically upgrade a project from C++ to D.
Hence the name "magicport"?
Sorry, could not resist.
David
"Jacob Carlborg" wrote in message news:lt6u0n$18mj$1...@digitalmars.com...
How about we undeprecate it instead. If I recall correctly then DDMD
depends on it.
It's listed as 'future', so it's not actually deprecated. While DDMD does
currently use it extensively, it can be replaced if necess
"David Nadlinger" wrote in message
news:jumhdppapovcvfnwn...@forum.dlang.org...
On Friday, 22 August 2014 at 07:48:30 UTC, Daniel Murphy wrote:
> So no, you can't magically upgrade a project from C++ to D.
Hence the name "magicport"?
Sorry, could not resist.
David
It's only the illusion of
On Fri, 22 Aug 2014 08:29:52 +
David Nadlinger via Digitalmars-d wrote:
> Hence the name "magicport"?
magic is not easy, contrary to widespread beliefs. ;-)
signature.asc
Description: PGP signature
In my project I have sort of complicated logic to implement data
structure that is somehow similar to std.typecons.Tuple. I can't
reproduce it, because I can't locate the source of bug. My code
is like this but have more nested template "calls".
import std.stdio, std.typetuple;
struct MyLib(A
On Thursday, 21 August 2014 at 15:36:41 UTC, ketmar via
Digitalmars-d wrote:
On Thu, 21 Aug 2014 15:27:46 +
MacAsm via Digitalmars-d wrote:
Any thoughts? I don't know if I'm missing something but two
functions (and not methods) with same name is very bad.
they doing much the same, but for
https://github.com/duovia/WindowsServiceInD/blob/master/src/onedge/mysvc.d#L20
these are not necessarily static: it makes sense to have instance
fields of shared types too.
Am 22.08.2014 00:35, schrieb Sönke Ludwig:
The DOM style JSONValue type is based on std.variant.Algebraic. This
currently has a few usability issues that can be solved by
upgrading/fixing Algebraic:
- Operator overloading only works sporadically
- (...)
- Operations and conversions between
Very nice ! I had started (and dropped) a json module based on
Algebraic too. So without opDispatch you plan to use a syntax
like jPerson["age"] = 10 ? You didn't use stdx.d.lexer. Any
reason why ? (I am asking even if I never used this module.(never
coded much in D in fact))
Am 22.08.2014 14:17, schrieb matovitch:
Very nice ! I had started (and dropped) a json module based on Algebraic
too. So without opDispatch you plan to use a syntax like jPerson["age"]
= 10 ? You didn't use stdx.d.lexer. Any reason why ? (I am asking even
if I never used this module.(never coded
On Friday, 22 August 2014 at 12:39:08 UTC, Sönke Ludwig wrote:
Am 22.08.2014 14:17, schrieb matovitch:
Very nice ! I had started (and dropped) a json module based on
Algebraic
too. So without opDispatch you plan to use a syntax like
jPerson["age"]
= 10 ? You didn't use stdx.d.lexer. Any reason
Am 22.08.2014 14:47, schrieb matovitch:
Ok. I think I remember there was a stdx.d.lexer's Json parser provided
as sample.
I see, so you just have to write your own number/string parsing routines:
https://github.com/Hackerpilot/lexer-demo/blob/master/jsonlexer.d
I just want to write something like this:
#ololo script
foreach(child; findAllChildrens())
{
child.insert(
static void doABarrelRoll() { }
);
}
#end
Templates/mixins is not enough for me... maybe because of
hands.dll error :)
On Friday, 22 August 2014 at 13:00:19 UTC, Sönke Ludwig wrote:
Am 22.08.2014 14:47, schrieb matovitch:
Ok. I think I remember there was a stdx.d.lexer's Json parser
provided
as sample.
I see, so you just have to write your own number/string parsing
routines:
https://github.com/Hackerpilot/
You can try D parsing libraries:
http://forum.dlang.org/thread/jqwvudiwgiuprqcua...@forum.dlang.org
they're believed to enable writing refactoring scripts.
Example:
import std.lexer;
import std.d.lexer;
import std.array;
import std.stdio;
void main(string[] args)
{
File input = File(args[1]);
File output = args.length > 2 ? File(args[2]) : stdout;
ubyte[] inputBytes = uninitializedArray!(ubyte[])(input.size);
input.r
To call decode() from std.encoding I need to make sure it is an
UTF (may ne ASCII too) otherwise is will skyp over ASCII values.
Is there any D native for it or I need to check byte order mark
and write one myself?
I believe it should work (it is no different from foreach(elem;
myLib.Symbols) which works), but there are better experts on such
topics hanging around.
On Friday, 22 August 2014 at 13:53:04 UTC, MacAsm wrote:
To call decode() from std.encoding I need to make sure it is an
UTF (may ne ASCII too) otherwise is will skyp over ASCII
values. Is there any D native for it or I need to check byte
order mark and write one myself?
You may want to take
On 8/22/14 1:29 AM, David Nadlinger wrote:
On Friday, 22 August 2014 at 07:48:30 UTC, Daniel Murphy wrote:
So no, you can't magically upgrade a project from C++ to D.
Hence the name "magicport"?
Sorry, could not resist.
David
It's pronounced "sufficiently advanced technology port" :)
On 8/22/14, 3:33 AM, Sönke Ludwig wrote:
Am 22.08.2014 02:42, schrieb Ary Borenszweig:
Say I have a class Person with name (string) and age (int) with a
constructor that receives both. How would I create an instance of a
Person from a json with the json stream?
Suppose the json is this:
{"age"
On Friday, 22 August 2014 at 13:53:04 UTC, MacAsm wrote:
To call decode() from std.encoding I need to make sure it is an
UTF (may ne ASCII too) otherwise is will skyp over ASCII
values. Is there any D native for it or I need to check byte
order mark and write one myself?
This may be simpler f
On Friday, 22 August 2014 at 13:33:12 UTC, Kagamin wrote:
You can try D parsing libraries:
http://forum.dlang.org/thread/jqwvudiwgiuprqcua...@forum.dlang.org
they're believed to enable writing refactoring scripts.
Thanks a lot! It will be useful.
On 2014-08-22 10:37, Daniel Murphy wrote:
It's listed as 'future', so it's not actually deprecated.
Everyone is treating it as deprecated.
While DDMD
does currently use it extensively, it can be replaced if necessary. I'd
much rather see it reinstated along with proper escape checking.
Fa
On 2014-08-22 00:35, Sönke Ludwig wrote:
Following up on the recent "std.jgrandson" thread [1], I've picked up
the work (a lot earlier than anticipated) and finished a first version
of a loose blend of said std.jgrandson, vibe.data.json and some changes
that I had planned for vibe.data.json for a
On Thursday, 21 August 2014 at 18:07:31 UTC, Brad Anderson wrote:
On Thursday, 21 August 2014 at 17:55:19 UTC, Timothee Cour via
Digitalmars-d wrote:
http://dlang.org/cpptod.html#raii mentions scope class and
scope variables,
which seem deprecated (http://dlang.org/deprecate.html)
https://git
On Friday, 22 August 2014 at 15:47:51 UTC, Jacob Carlborg wrote:
* I think we have talked about this before, when reviewing D
lexers. I'm thinking of how to handle invalid data. Is it the
best solution to throw an exception? Would it be possible to
return an error token and have the client deci
Am 22.08.2014 17:47, schrieb Jacob Carlborg:
On 2014-08-22 00:35, Sönke Ludwig wrote:
Following up on the recent "std.jgrandson" thread [1], I've picked up
the work (a lot earlier than anticipated) and finished a first version
of a loose blend of said std.jgrandson, vibe.data.json and some chang
Am 22.08.2014 16:53, schrieb Ary Borenszweig:
On 8/22/14, 3:33 AM, Sönke Ludwig wrote:
Without a serialization framework it would in theory work like this:
JSONValue v = parseJSON(`{"age": 10, "name": "John"}`);
auto p = new Person(v["name"].get!string, v["age"].get!int);
unfortunate
Some thoughts about the API:
1) Instead of `parseJSONValue` and `lexJSON`, how about static
methods `JSON.parse` and `JSON.lex`, or even a module level
functions `std.data.json.parse` etc.? The "JSON" part of the name
is redundant.
2) Also, `parseJSONValue` and `parseJSONStream` probably don
On Monday, 11 August 2014 at 14:45:09 UTC, Andrei Alexandrescu
wrote:
On 8/11/14, 2:11 AM, "Nordlöw" wrote:
On Monday, 11 August 2014 at 06:56:52 UTC, Dragos Carp wrote:
bool sliceOf(T)(in T[] whole, in T[] slice)
{
return whole.ptr <= slice.ptr &&
whole.ptr + slice.length <= whole.pt
It would be nice to have integers treated separately to doubles.
I know it makes the number parsing simpler to just treat
everything as double, but still, it could be annoying when you
expect an integer type.
I'd also like to see some benchmarks, particularly against some
of the high performa
Am 22.08.2014 18:15, schrieb "Marc Schütz" ":
Some thoughts about the API:
1) Instead of `parseJSONValue` and `lexJSON`, how about static methods
`JSON.parse` and `JSON.lex`, or even a module level functions
`std.data.json.parse` etc.? The "JSON" part of the name is redundant.
For those functi
Am 22.08.2014 18:31, schrieb Christian Manning:
It would be nice to have integers treated separately to doubles. I know
it makes the number parsing simpler to just treat everything as double,
but still, it could be annoying when you expect an integer type.
That's how I've done it for vibe.data.
On Friday, 22 August 2014 at 08:47:23 UTC, Uranuz wrote:
In my project I have sort of complicated logic to implement
data structure that is somehow similar to std.typecons.Tuple. I
can't reproduce it, because I can't locate the source of bug.
You could try using DustMite:
https://github.com/C
On 8/22/14, 1:24 PM, Sönke Ludwig wrote:
Am 22.08.2014 16:53, schrieb Ary Borenszweig:
On 8/22/14, 3:33 AM, Sönke Ludwig wrote:
Without a serialization framework it would in theory work like this:
JSONValue v = parseJSON(`{"age": 10, "name": "John"}`);
auto p = new Person(v["name"].g
On Friday, 22 August 2014 at 16:48:44 UTC, Sönke Ludwig wrote:
Am 22.08.2014 18:15, schrieb "Marc Schütz" ":
Some thoughts about the API:
1) Instead of `parseJSONValue` and `lexJSON`, how about static
methods
`JSON.parse` and `JSON.lex`, or even a module level functions
`std.data.json.parse`
On Friday, 22 August 2014 at 16:56:26 UTC, Sönke Ludwig wrote:
Am 22.08.2014 18:31, schrieb Christian Manning:
It would be nice to have integers treated separately to
doubles. I know
it makes the number parsing simpler to just treat everything
as double,
but still, it could be annoying when you
Am 22.08.2014 19:24, schrieb "Marc Schütz" ":
On Friday, 22 August 2014 at 16:48:44 UTC, Sönke Ludwig wrote:
Actually they take exactly the same parameters and just differ in
their return value. It would be more descriptive to name them
parseAsJSONValue and parseAsJSONStream - or maybe parseJSO
Am 22.08.2014 19:27, schrieb "Marc Schütz" ":
On Friday, 22 August 2014 at 16:56:26 UTC, Sönke Ludwig wrote:
Am 22.08.2014 18:31, schrieb Christian Manning:
It would be nice to have integers treated separately to doubles. I know
it makes the number parsing simpler to just treat everything as do
A friend of mine stumbled across this today:
http://tomerfiliba.com/blog/dlang/
Rejoice! :-)
T
--
Why waste time reinventing the wheel, when you could be reinventing the engine?
-- Damian Conway
On Friday, 22 August 2014 at 17:54:36 UTC, H. S. Teoh via
Digitalmars-d wrote:
A friend of mine stumbled across this today:
http://tomerfiliba.com/blog/dlang/
Rejoice! :-)
T
There's a fairly active conversation going on about this article
on Hacker News currently.
https://news.yc
On Friday, 22 August 2014 at 17:35:20 UTC, Sönke Ludwig wrote:
... why not use exactly the same convention then? =>
`parse!JSONValue`
Would be nice to have a "pluggable" API where you just need to
specify
the type in a factory method to choose the input format. Then
there
could be `parse!BSO
On Friday, 22 August 2014 at 17:54:36 UTC, H. S. Teoh via
Digitalmars-d wrote:
A friend of mine stumbled across this today:
http://tomerfiliba.com/blog/dlang/
Rejoice! :-)
T
http://forum.dlang.org/post/qycdbardacyhvabyq...@forum.dlang.org
On Friday, 22 August 2014 at 17:45:03 UTC, Sönke Ludwig wrote:
Am 22.08.2014 19:27, schrieb "Marc Schütz" ":
On Friday, 22 August 2014 at 16:56:26 UTC, Sönke Ludwig wrote:
Am 22.08.2014 18:31, schrieb Christian Manning:
It would be nice to have integers treated separately to
doubles. I know
it
I got this FB chatted to me from an old programmer friend too
yesterday who has never used D himself but knows I do. It seems
to be getting somewhat broad exposure.
On 8/21/2014 3:35 PM, Sönke Ludwig wrote:
Destroy away! ;)
Thanks for taking this on! This is valuable work. On to destruction!
I'm looking at:
http://s-ludwig.github.io/std_data_json/stdx/data/json/lexer/lexJSON.html
I anticipate this will be used a LOT and in very high speed demanding
app
Am 22.08.2014 19:57, schrieb "Marc Schütz" ":
On Friday, 22 August 2014 at 17:35:20 UTC, Sönke Ludwig wrote:
... why not use exactly the same convention then? => `parse!JSONValue`
Would be nice to have a "pluggable" API where you just need to specify
the type in a factory method to choose the i
On Fri, Aug 22, 2014 at 05:55:03PM +, Dicebot via Digitalmars-d wrote:
[...]
> http://forum.dlang.org/post/qycdbardacyhvabyq...@forum.dlang.org
On Fri, Aug 22, 2014 at 05:56:12PM +, Brad Anderson via Digitalmars-d wrote:
[...]
> There's a fairly active conversation going on about this arti
On Fri, Aug 22, 2014 at 06:05:03PM +, Adam D. Ruppe via Digitalmars-d wrote:
> I got this FB chatted to me from an old programmer friend too
> yesterday who has never used D himself but knows I do. It seems to be
> getting somewhat broad exposure.
Ah, that would explain why this particular fri
Am 22.08.2014 20:01, schrieb "Marc Schütz" ":
On Friday, 22 August 2014 at 17:45:03 UTC, Sönke Ludwig wrote:
Am 22.08.2014 19:27, schrieb "Marc Schütz" ":
On Friday, 22 August 2014 at 16:56:26 UTC, Sönke Ludwig wrote:
Am 22.08.2014 18:31, schrieb Christian Manning:
It would be nice to have in
First of all thanks for your replies, they are useful.
@Philippe:
A pure function is ok for initializing "default_nodes" but not
for "nodes" because a pure function can't read a file.
The "static this" has the problem it needs know the initializer
at compile time but I wanted to choose the init
On Friday, 22 August 2014 at 18:08:34 UTC, Sönke Ludwig wrote:
Am 22.08.2014 19:57, schrieb "Marc Schütz" ":
The easiest and cleanest way would be to add a function in
std.data.json:
auto parse(Target, Source)(Source input)
if(is(Target == JSONValue))
{
return ...;
Apparently there is evidence that unused variables in C-like
languages correlate with bugs:
https://kev.inburke.com/slides/errors/#error-correlations
One problem with ruling out some classes of unused variables
(like unused function arguments, unused private module-level
variables, unused fun
On 8/22/14, Sönke Ludwig wrote:
> Docs: http://s-ludwig.github.io/std_data_json/
This confused me for a solid minute:
// Lex a JSON string into a lazy range of tokens
auto tokens = lexJSON(`{"name": "Peter", "age": 42}`);
with (JSONToken.Kind) {
assert(tokens.map!(t => t.kind).equal(
Ten years is a long time but perhaps this can help anyone running
into this forum thread.
https://github.com/duovia/WindowsServiceInD
I'm using the Windows API library (source actually) on
dsource.org. See link on the github page. I found it difficult to
find a complete solution to the proble
Am 22.08.2014 21:15, schrieb Andrej Mitrovic via Digitalmars-d:
On 8/22/14, Sönke Ludwig wrote:
Docs: http://s-ludwig.github.io/std_data_json/
This confused me for a solid minute:
// Lex a JSON string into a lazy range of tokens
auto tokens = lexJSON(`{"name": "Peter", "age": 42}`);
with (J
On Friday, 22 August 2014 at 09:09:22 UTC, Kagamin wrote:
https://github.com/duovia/WindowsServiceInD/blob/master/src/onedge/mysvc.d#L20
these are not necessarily static: it makes sense to have
instance fields of shared types too.
Yes, Kagamin, you're right. I'll pull those out of shared as th
On Friday, 22 August 2014 at 17:45:03 UTC, Sönke Ludwig wrote:
Am 22.08.2014 19:27, schrieb "Marc Schütz" ":
On Friday, 22 August 2014 at 16:56:26 UTC, Sönke Ludwig wrote:
Am 22.08.2014 18:31, schrieb Christian Manning:
It would be nice to have integers treated separately to
doubles. I know
it
Am 22.08.2014 21:48, schrieb Christian Manning:
On Friday, 22 August 2014 at 17:45:03 UTC, Sönke Ludwig wrote:
Am 22.08.2014 19:27, schrieb "Marc Schütz" ":
On Friday, 22 August 2014 at 16:56:26 UTC, Sönke Ludwig wrote:
Am 22.08.2014 18:31, schrieb Christian Manning:
It would be nice to have
Indeed the ref can be applied to the return type:
http://dlang.org/function.html#ref-functions
So, does the following code copy any data from "nodes"?
If that is the case this solution avoids the "class" storage,
avoids pointers and "nodes" is encapsulated as read-only, that's
great.
The progra
On Friday, 22 August 2014 at 18:21:06 UTC, Vicente wrote:
@Wyatt:
Certainly ref parameters help a lot, but I'm trying to get a
"Node" by returning (a reference to) it. Does the ref keyword
apply to the return type?
I poked it a bit and came out with this. I _think_ it's working
as expected
On Friday, 22 August 2014 at 20:02:41 UTC, Sönke Ludwig wrote:
Am 22.08.2014 21:48, schrieb Christian Manning:
On Friday, 22 August 2014 at 17:45:03 UTC, Sönke Ludwig wrote:
Am 22.08.2014 19:27, schrieb "Marc Schütz"
":
On Friday, 22 August 2014 at 16:56:26 UTC, Sönke Ludwig
wrote:
Am 22.08.2
On Friday, 22 August 2014 at 19:07:24 UTC, bearophile wrote:
Another solution is to leave such tests out of the core
compiler, and put them in a lint tool that you run when you
think your code is in good shape.
https://github.com/Hackerpilot/Dscanner
The unused variable and unused parameter c
Yes, no decimal point + no exponent would work without overhead
to detect integers, but that wouldn't solve the proposed
automatic long->double overflow, which is what I meant. My
current idea is to default to double and optionally support any
of long, BigInt and "Decimal" (BigInt+exponent), wh
On Friday, 22 August 2014 at 20:12:39 UTC, Wyatt wrote:
I poked it a bit and came out with this. I _think_ it's
working as expected:
...
auto ref opSlice(){return nodes[];};
...
-Wyatt
Assuming it's working as expected, that is exactly what I was
looking for!
But the following cod
Brian Schott:
The unused variable and unused parameter checks have existed
since May. As far as I know it only gives false positives if
mixin statements are present.
Another interesting feature is similar to -Wsuggest-final-types
and -Wsuggest-final-methods. They give warnings when there is
Am 22.08.2014 20:08, schrieb Walter Bright:
On 8/21/2014 3:35 PM, Sönke Ludwig wrote:
Destroy away! ;)
Thanks for taking this on! This is valuable work. On to destruction!
I'm looking at:
http://s-ludwig.github.io/std_data_json/stdx/data/json/lexer/lexJSON.html
I anticipate this will be use
Am 22.08.2014 18:13, schrieb Sönke Ludwig:
Am 22.08.2014 17:47, schrieb Jacob Carlborg:
* Opening braces should be put on their own line to follow Phobos style
guides
Will do.
* I'm wondering about the assert in lexer.d, line 160. What happens if
two invalid tokens after each other occur?
On 08/22/2014 09:07 PM, bearophile wrote:
Apparently there is evidence that unused variables in C-like languages
correlate with bugs:
https://kev.inburke.com/slides/errors/#error-correlations
...
http://xkcd.com/552/
If the foreach loop is replaced by:
foreach(ref node_ref; np)
Then it works like a charm!
Timon Gehr:
http://xkcd.com/552/
What better alternative do you suggest in practice? The only
better solution I remember that was used for a language design is
the ":" added to Python after some controlled experiments done on
users.
Relying on experimental correlations (if the analysis is
On 8/22/14, 6:46 PM, bearophile wrote:
Currently a group of people are trying to design a language pushing to
the extreme the idea of design by committee, it's future a peer reviewed
language meant to be used for scientific programming. I've taken a look
at its syntax and I was not happy with the
Ary Borenszweig:
What language is that?
I don't remember its name, of course.
I have just scanned the last few months of the LambdaTheUltimate
blog without success.
Bye,
bearophile
On 08/23/2014 01:32 AM, Timon Gehr wrote:
you seemed to suggest in the OT.
OP
On 08/22/2014 11:46 PM, bearophile wrote:
Timon Gehr:
http://xkcd.com/552/
...
My point is just that this correlation is not a strong data point
supporting putting effort into elimination of unused variables. It is
possible that all this will accomplish is that unused variables will no
lo
On Friday, 22 August 2014 at 23:32:54 UTC, Timon Gehr wrote:
The correlation only indicates that poor code tends to have
more unused variables. If one eliminates unused variables just
for the sake of eliminating unused variables, code quality will
most likely not magically increase.
I would a
On 08/23/2014 02:03 AM, Brian Schott wrote:
On Friday, 22 August 2014 at 23:32:54 UTC, Timon Gehr wrote:
The correlation only indicates that poor code tends to have more
unused variables. If one eliminates unused variables just for the sake
of eliminating unused variables, code quality will most
On 8/22/2014 2:27 PM, Sönke Ludwig wrote:
Am 22.08.2014 20:08, schrieb Walter Bright:
1. There's no mention of what will happen if it is passed malformed JSON
strings. I presume an exception is thrown. Exceptions are both slow and
consume GC memory. I suggest an alternative would be to emit an "
First thank you for your work. std.json is horrible to use right
now, so a replacement is more than welcome.
I haven't played with your code yet, so I may be asking for
somethign that already exists, but did you had a look to jsvar by
Adam ?
You can find it here:
https://github.com/adamdrup
On 8/22/2014 6:05 PM, Walter Bright wrote:
The problem is that it really depends on the use case and on the type of input
stream which approach is more efficient (storing the escaped version of a string
might require *two* allocations if the input range cannot be sliced and if the
decoded string
On Sat, 23 Aug 2014 02:23:25 +
deadalnix via Digitalmars-d wrote:
> I haven't played with your code yet, so I may be asking for
> somethign that already exists, but did you had a look to jsvar by
> Adam ?
jsvar using opDispatch, and Sönke wrote:
> - No opDispatch() for JSONValue - this ha
On Fri, 22 Aug 2014 21:46:44 +
bearophile via Digitalmars-d wrote:
> What better alternative do you suggest in practice?
don't declare unused variables. really, this is extremely easy. my 15+
years of expirience in writing projects of different scale shows that
good decomposition, code archit
On Saturday, 23 August 2014 at 02:48:15 UTC, ketmar via
Digitalmars-d wrote:
don't declare unused variables. really, this is extremely easy.
my 15+
years of expirience in writing projects of different scale
What about:
- versioning
- debugging (commenting out debugging code)
- virtual functio
On Saturday, 23 August 2014 at 02:30:23 UTC, Walter Bright wrote:
Another possibility is to have the user pass in a resizeable
buffer which then will be used to store the strings in as
necessary.
One example is std.internal.scopebuffer. The nice thing about
that is the user can use the stack
On Sat, 23 Aug 2014 03:50:13 +
via Digitalmars-d wrote:
> - versioning
refactor it, so that shared code goes to separate functions. nested
functions especially helpful here. i'm used to this GCC extension.
> - debugging (commenting out debugging code)
why comment it out? if (debug_enabled) i
On Saturday, 23 August 2014 at 04:07:58 UTC, ketmar via
Digitalmars-d wrote:
On Sat, 23 Aug 2014 03:50:13 +
via Digitalmars-d wrote:
- versioning
refactor it, so that shared code goes to separate functions.
nested
functions especially helpful here. i'm used to this GCC
extension.
Won't
On 8/22/2014 9:01 PM, Ola Fosheim Gr wrote:
On Saturday, 23 August 2014 at 02:30:23 UTC, Walter Bright wrote:
One example is std.internal.scopebuffer. The nice thing about that is the user
can use the stack for the storage, which works out to be very, very fast.
Does this mean that D is gettin
On Saturday, 23 August 2014 at 04:36:34 UTC, Walter Bright wrote:
On 8/22/2014 9:01 PM, Ola Fosheim Gr wrote:
Does this mean that D is getting resizable stack allocations
in lower stack
frames? That has a lot of implications for code gen.
scopebuffer does not require resizeable stack allocati
On 8/22/2014 9:48 PM, Ola Fosheim Gr wrote:
On Saturday, 23 August 2014 at 04:36:34 UTC, Walter Bright wrote:
On 8/22/2014 9:01 PM, Ola Fosheim Gr wrote:
Does this mean that D is getting resizable stack allocations in lower stack
frames? That has a lot of implications for code gen.
scopebuffe
On Saturday, 23 August 2014 at 05:28:55 UTC, Walter Bright wrote:
On 8/22/2014 9:48 PM, Ola Fosheim Gr wrote:
On Saturday, 23 August 2014 at 04:36:34 UTC, Walter Bright
wrote:
On 8/22/2014 9:01 PM, Ola Fosheim Gr wrote:
Does this mean that D is getting resizable stack allocations
in lower stac
On 8/22/2014 11:25 PM, Ola Fosheim Gr wrote:
On Saturday, 23 August 2014 at 05:28:55 UTC, Walter Bright wrote:
On 8/22/2014 9:48 PM, Ola Fosheim Gr wrote:
On Saturday, 23 August 2014 at 04:36:34 UTC, Walter Bright wrote:
On 8/22/2014 9:01 PM, Ola Fosheim Gr wrote:
Does this mean that D is get
On Saturday, 23 August 2014 at 06:41:11 UTC, Walter Bright wrote:
Scopebuffer is extensively used in Warp, and works very well.
The "hole" in the stack is not a significant problem.
Well, on a webserver you don't want to push out the caches for no
good reason.
You can always implement your o
97 matches
Mail list logo
