Re: A few general thoughts
== Quote from KennyTM~ (kenn...@gmail.com)'s article > It's very *unportable* to write a string in your way. Yes, that's probably true. > If D allowed non-UTF encoding without error, it's possible that a string > in those settings got misinterpreted, but it's not easy to determine when. Could be generate just warning, not error...
Re: A few general thoughts
== Quote from KennyTM~ (kenn...@gmail.com)'s article > You could use x"" string, or just escape those characters > auto x = x"f1f2f3 f4"; > auto y = "\xf1\xf2\xf3\xf4"; > (And if your "string" is not a UTF-8 string at all, you should use a > ubyte[], not char[]. > const(ubyte)[] z = [0xf1, 0xf2, 0xf3, 0xf4]; > auto t = cast(const(ubyte)[]) x"f1f2f3f4"; > ) It would be very unclean write strings this way, but it is not so important. The point is that I don't like features which cannot be disabled. For example variables in D are initialized, which is good, but you can write int i = void; and disable it. The final decision is on the programmer. You are not forced to do it only one "good" way. This is philosophy which I like. Of course, I understand that it is not possible make everything optional, it has negatives, like everything has, but if there are serious doubts about some feature and it is not big deal to make it optional, it SHOULD be optional. At least I think so.
Re: A few general thoughts
== Quote from Daniel Gibson (metalcae...@gmail.com)'s article
> Once a feature is deprecated, the compiler will treat using it as an
> error - *if* you don't use the "-d" switch ("Allow deprecated features").
> I think this should be acceptable for you?
> Cheers,
> - Daniel
Seems good. Sorry, I didn't know that it is already working this way.
Re: A few general thoughts
> This has been acknowledged. Yes, removing delete in D2 will break > compatibility with existing code. However, I'm sure that at an early > stage, the compiler will probably issue error messages once it > encounters delete statements, for which the fix is quite easy: just > remove them, and recompile. As an unfortunate side effect, a few other > problems might occur, especially for shared objects. But refactoring to > a simpler system, in which the garbage collector is trusted to manage > the heap, should be easy. Yes, I was speaking generally here about "breaking compatibility" philosophy. I agree that delete probably will not be such problem - but I would prefer mark features deprecated before it will be really removed and write only warning when compiled - in case it is possible. (For example some datatype was removed in d2 (bit? - I am not sure) which is one of error messages which I get when I try compile my project with incompatible library) People don't have to know what is planned for removing. Moreover there is not complete list of changes in d2. Or is?
Re: A few general thoughts
== Quote from Denis Koroskin (2kor...@gmail.com)'s article
> You can use import("file.txt"); to import files (text or binary) at
> compile time.
Interesting - I didn't know this. It's true that most of strings will be
probably
loaded from some file in final application...
A few general thoughts
This post is in fact mainly about removing delete, but I didn't wont make everyone angry just with title.:) I am sure not expert to language design, so I should probably be quiet, but I have question. My question is: Didn't break it (i.e. removing delete) compatibility? In my opinion every decision have both bad and good sides, which should be carefully weighted. (I hope that you can understand me, because english is not my native language) For me, backward compatibility is important issue. I am sure that this topic was discussed here many times, but I want just say that I vote for more careful way to make changes in language. It is even more important for young language, I believe, because many libraries and tools can stay incompatible for long time. For example I am not using D2.0, because I have incompatible libraries in my project and it seems it cannot be fixed easy way. What about mark features to remove as "deprecated" and write warning by compiler, if they are used? So feature would be really removed after some time in next version, and people would be informed this way and have time to prepare your code or discuss change. I am not against breaking compatibility entirely, but it should be compensated with really significant improvement. Another thing with bad and good sides is "dangerous" feature, as was mentioned for delete. In my opinion more safety means often more restrictive language (and now I am speaking in general, not about "delete"). For example C gives you big freedom, but it is very dangerous. Modern languages are much more restrictive. But sometimes I prefer dangerous feature (if it is not "too dangerous"), which give me more freedom. Because even smartest language designer cannot see all real situations possible and restriction which cannot be disabled can be very annoying. Example: I was not happy with error message "invalid utf8 character". I am using international character in my strings and compiler gives me this message. Of course, I can switch my source codes into utf8, but here are few tricks which can be done with plain ascii. I draw characters in graphic, using OpenGl by calling glCallLists(somestring.length, somestring.ptr); It will take somestring as array of indexes of displaylists where each displaylist will draw one character and his id=ascii code. But because this restriction it is not possible. And it is error, not warning and cannot be disabled ANY WAY (as far as I know). You can say: Blah, utf8 is generally good thing, and this is minor unimportant issue, but I want just illustrate that restriction can create unexpected problems and that's because I like if I have choice. (And again this was not about delete or utf8, but general thougth) Sorry for long post.
Re: lame question
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article > On 4/19/11 1:04 PM, Timon Gehr wrote: > > Steven Schveighoffer wrote: > >> And one other note -- delete will eventually be deprecated. In order to > >> free memory, you must use clear and GC.free. > > > >> -Steve > > > > Well, why? It seems like a bad decision to me. > The feature is not going away, just the keyword. > "delete" is a gratuitous carryover from C++, which had to invent it > because the need for manual object disposal predated the introduction of > templates. > D stays a systems programming language but also has a safe subset and > generally offers better safety guarantees than C++. It is excessive to > allocate a keyword to a feature that's fundamentally unsafe, > particularly since the underlying feature offers considerably fewer > guarantees than its C++ counterpart. (Some GCs are unable to implement > "delete" meaningfully.) > Manual memory disposal for the GC heap will be implemented as a template > function with semantics defined by the GC implementation. > Andrei Well, I don't understand internal architecture at all, but from user's point of view it would be good keep some simple and nice way to remove object. I like if I can have things under control - if I want.
Re: lame question
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
> On Mon, 18 Apr 2011 04:31:26 -0400, %u wrote:
> > Is it necessary free memory allocated for member of structure, like in
> > C? I
> > suppose not (we have gc). Example:
> >
> > struct BITMAP {
> > (...)
> > ubyte[] pixels;
> > }
> >
> > BITMAP* bitmap = new BITMAP;
> > bitmap.pixels = new ubyte[100*100];
> > (...)
> >
> > // delete bitmap.pixels; //not necessary?
> >
> > delete bitmap;
> It is not necessary, because pixels will be collected by the GC sometime
> in the future. It will *not* free pixel's data by calling delete on the
> BITMAP pointer.
> Just a note, you may be tempted to use a destructor do effect the above
> (as is done in C++ commonly), but this is a very big mistake.
So what is "correct" way to manage structures like BITMAP? Don't bother with
freeing memory at all?
> And one other note -- delete will eventually be deprecated. In order to
> free memory, you must use clear and GC.free.
> -Steve
It's pity. I like delete.:)
Re: lame question
I see...thanks for answer. And if I call "delete bitmap", it will be removed immediatelly, or it doesn't matter and gc will remove it when it will start its cycle? So even ubyte[] pixels will be allocated on the stack ?? What is prefered method to allocate large byte array, then? Should I use malloc?
internal representation of struct
Hello, I have array of type vertex_t vertices[] where vertex_t is:
struct vertex_t {
float[3] xyz;
ubyte[4] color;
...
}
Now, I would like use instead of array "float[3] xyz" "vec3f xyz", where vec3f
is:
struct vec3f {
float x, y, z;
...some functions...
}
where I have defined some operators for adding and multipliing vectors etc.
Is it possible? "xyz" must be exactly 3 floats in memory because I am sending
vertices array pointer into OpenGL rendering pipeline.
Will be struct vec3f represented just like 3 floats - aren't here some
additional metadata - because structure contains also some functions?
My additional question: What about effectivity? I would like keep struct
vertex_t as simple as possible, because I need do calculations fast. Will have
replacing float array to structure some impact on speed?
Thank you.
