I process archive:
///
import std.stdio, std.zip, std.file;
int main()
{
auto zip = new ZipArchive(read(c:/test.zip));
foreach (item; zip.directory) {
writeln(processing , item.name, ...);
// processing item...
}
return 0;
}
/
it works well for normal
On Saturday, 19 July 2014 at 07:55:10 UTC, AntonSotov wrote:
I process archive:
///
import std.stdio, std.zip, std.file;
int main()
{
auto zip = new ZipArchive(read(c:/test.zip));
foreach (item; zip.directory) {
writeln(processing , item.name, ...);
// processing
On Friday, 18 July 2014 at 16:19:20 UTC, John Colvin wrote:
On Friday, 18 July 2014 at 16:12:18 UTC, Rene Zwanenburg wrote:
On Friday, 18 July 2014 at 15:57:40 UTC, John Colvin wrote:
On Friday, 18 July 2014 at 14:15:46 UTC, Rene Zwanenburg
wrote:
For all intents and purposes, the following
is there any way for an object to make it self no longer usable?
eg
class someclass {
string somevalue;
bool someflag;
int somelength;
this (value,length,flag) {
somevalue = value;
someflag = flag;
somelength =
Marc Schütz:
import std.stdio, std.zip, std.file, std.mmfile;
int main()
{
auto mmfile = new MmFile(File(c:/test.zip, rb));
auto zip = new ZipArchive(mmfile[]);
foreach (item; zip.directory) {
writeln(processing , item.name, ...);
// processing item...
}
return 0;
}
This
It seems that ti only works for zip files with less than 65000
entries, zip64 that allow read more than that do seem to be
implemented.
It's ok to deduce opDispatch as pure, but then its purity should
be enforced and error reported.
On 07/19/2014 03:53 PM, Kagamin wrote:
It's ok to deduce opDispatch as pure, but then its purity should be
enforced and error reported.
Why would it be ok to deduce opDispatch as pure only to report an error
that it is not actually pure? This would be a bug as well (albeit none
that causes
On Saturday, 19 July 2014 at 13:46:08 UTC, Kagamin wrote:
You can encapsulate it in a wrapper, which will control access
to the object and reject if necessary.
how ?
surely not by writing another class with wrapper methods for the
existing one.
On Saturday, 19 July 2014 at 17:05:27 UTC, Sean Campbell wrote:
surely not by writing another class with wrapper methods for
the existing one.
If you don't want to write the class, you can write a generator
for it. See BlackHole wrapper for an example.
On Saturday, 19 July 2014 at 17:28:13 UTC, Frustrated wrote:
If you do this you are potentially asking for a lot of access
violation errors or undefined behavior.
Of course, the object should not be used after destruction. The
trick is to reliably diagnose it. If such uses are not
You can also try class invariant.
On Wednesday, 16 July 2014 at 19:43:26 UTC, Martijn Pot wrote:
On Tuesday, 15 July 2014 at 22:09:43 UTC, ponce wrote:
On Tuesday, 15 July 2014 at 20:46:32 UTC, Martijn Pot wrote:
To make a long story short:
Is there any math library with e.g. mean, std, polynomial
fitting, ...?
On Thursday, 17 July 2014 at 23:44:56 UTC, H. S. Teoh via
Digitalmars-d-learn wrote:
So you see, this has forced us to be more precise about exactly
what an
input range is, instead of the current imprecise definition
which leads
to subtle, corner case bugs like std.algorithm not handling
On Thursday, 17 July 2014 at 22:52:37 UTC, Justin Whear wrote:
static assert(isInputRange!SomeRange);
I'll use that for now.
Thx
On Thursday, 17 July 2014 at 18:03:45 UTC, H. S. Teoh via
Digitalmars-d-learn wrote:
T
Thx
I have a Resource struct that is supposed to free some memory
when it gets destroyed. Unfortunately, I can't define a
destructor. If I do, the compiler complains that it can't destroy
the shared versions. If I define a shared destructor, the
compiler complains that it can't disambiguate
17 matches
Mail list logo
