Is it possible to implement support for Google Android on the D?
davidl пишет:
>
> Actually I'm not sure about what kind of bugs my d apps usually have.
> But I notice that the harmonia project(I now make it uptodate) gets the
> problem of integer overlapping(actually I find it quite hard to detect
> and fix).
>
> What's your opinion and experience?
I
Piotrek пишет:
> Weed pisze:
>> Weed пишет:
>>> Hi!
>>>
>>> I want to offer the dialect of the language D2.0, suitable for use where
>>> are now used C/C++. Main goal of this is making language like D, but
>>> corresponding "zero-overhead
Weed пишет:
> Hi!
>
> I want to offer the dialect of the language D2.0, suitable for use where
> are now used C/C++. Main goal of this is making language like D, but
> corresponding "zero-overhead principle" like C++:
at least to something like this idea? )
BCS пишет:
> Reply to Weed,
>
>
>> It is designed not so. There will be a hidden dereferencing:
>>
>> const ref Obj object -> struct{ Obj* object;-> Obj object;
>> int counter; };
>
> Who deletes those structs and when?
>
>
When an object is deleted the struct also is deleted
BCS пишет:
>>>
>>> I figure unless it save me more times than it costs /all/ the users,
>>> run time cost trumps.
>>>
>> This is a philosophical dispute.
>>
>> A good and frequently used code can be written once and then used 10
>> years in 50 applications in 1 installations. Here, the costs of
Christopher Wright пишет:
+ Sometimes allocation and freeing of memory in an arbitrary
unpredictable time unacceptable. (in game development or realtime
software, for example. One hundred million times discussed about it
there, I guess)
>>> So you are optimizing for the uncomm
Simen Kjaeraas пишет:
> Weed wrote:
>
>> Simen Kjaeraas пишет:
>>> Weed wrote:
>>>
>>>>> I think the point you're trying to make is that a GC is more memory
>>>>> intensive.
>>>>
>>>> + Sometimes al
Christopher Wright пишет:
> Weed wrote:
>> + Sometimes allocation and freeing of memory in an arbitrary
>> unpredictable time unacceptable. (in game development or realtime
>> software, for example. One hundred million times discussed about it
>> there, I guess)
>
&
Yigal Chripun пишет:
> what you suggest is C++ with better syntax, *NOT* a variant of D. for that
> look at:
> http://en.wikipedia.org/wiki/Significantly_Prettier_and_Easier_C%2B%2B_Syntax
>
No! Only because of the "value semantic" returns used pointers instead
of references for pointing to obj
Simen Kjaeraas пишет:
> Weed wrote:
>
>>> I think the point you're trying to make is that a GC is more memory
>>> intensive.
>>
>> + Sometimes allocation and freeing of memory in an arbitrary
>> unpredictable time unacceptable. (in game develo
Christopher Wright пишет:
>>> And regarding performance, eventually it will come a lot from a good
>>> usage of multiprocessing,
>> The proposal will be able support multiprocessing - for it provided a
>> references counting in the debug version of binaries. If you know the
>>
BCS пишет:
> Hello Weed,
>
>> BCS ?:
>>
>>> Reply to Weed,
>>>
>>>> If you know the
>>>> best way for language *without GC* guaranteeing the existence of an
>>>> object without overhead - I have to listen!
>>>
Denis Koroskin пишет:
> On Thu, 19 Mar 2009 19:54:10 +0300, Weed wrote:
>
>> naryl пишет:
>>> Weed Wrote:
>>>> naryl яПНяПНяПНяПНяПН:
>>>>> Weed Wrote:
>>>>>> BCS яПНяПНяПНяПНяПНяПНяПНяПНяПНяПНяПНяПНяПНяПНяПН:
>>>
naryl пишет:
> Weed Wrote:
>> naryl яПНяПНяПНяПНяПН:
>>> Weed Wrote:
>>>> BCS яПНяПНяПНяПНяПНяПНяПНяПНяПНяПНяПНяПНяПНяПНяПН:
>>>>> Yes you can be
>>>>> very careful in keeping track of pointers (not practical) or use smart
>>>
Robert Jacques пишет:
> *sigh* All memory allocation must make some kernel calls. D's GC makes
> fewer calls than a traditional malloc. Actually, modern malloc
> replacements imitate the way GCs allocate memory since it's a lot
> faster. (Intel's threading building blocks mentions this as part of
naryl пишет:
> Weed Wrote:
>> BCS яПНяПНяПНяПНяПН:
>>> Yes you can be
>>> very careful in keeping track of pointers (not practical) or use smart
>>> pointers and such (might end up costing more than GC)
>> I am do not agree: GC overexpenditure CPU or memo
BCS пишет:
> Reply to Weed,
>
>> If you know the
>> best way for language *without GC* guaranteeing the existence of an
>> object without overhead - I have to listen!
>>
>
> Never delete anything?
>
> One of the arguments for GC is that it might
Robert Jacques пишет:
>>
>> Multiprocessing can only improve performance for tasks that can run in
>> parallel. So far, every attempt to do this with GC (that I know of)
>> has ended up slower, not faster. Bottom line, if GC is the
>> bottleneck, more CPU's won't help.
>>
>> For applications whe
Christopher Wright пишет:
> And regarding performance, eventually it will come a lot from a good
> usage of multiprocessing,
The proposal will be able support multiprocessing - for it provided a
references counting in the debug version of binaries. If you know the
best way
Christopher Wright пишет:
> Weed wrote:
>> bearophile пишет:
>>> Weed:
>>>> I want to offer the dialect of the language D2.0, suitable for use
>>>> where
>>>> are now used C/C++. Main goal of this is making language like D, b
bearophile пишет:
> Weed:
>> I want to offer the dialect of the language D2.0, suitable for use where
>> are now used C/C++. Main goal of this is making language like D, but
>> corresponding "zero-overhead principle" like C++:
>> ...
>> The code on this
Kagamin пишет:
> Kagamin Wrote:
>
>> Weed Wrote:
>>
>>> - Its does not contains garbage collection and
>>> - allows active using of a stack for the objects (as in C++)
>>> - Its uses syntax and a tree of objects taken from the D
>> you j
Weed пишет:
> Hi!
>
colorized example:
http://paste.dprogramming.com/dpd6j5co
Hi!
I want to offer the dialect of the language D2.0, suitable for use where
are now used C/C++. Main goal of this is making language like D, but
corresponding "zero-overhead principle" like C++:
- Its does not contains garbage collection and
- allows active using of a stack for the objects (as i
Daniel Keep пишет:
>
> Weed wrote:
>> bearophile пишет:
>>> Weed:
>>>> We do not schoolgirls! :) Who is afraid of the complexity should use BASIC.
>>> I like D1 mostly because it's quite less complex that C++, that's the first
>>> thin
bearophile пишет:
> Weed:
>> We do not schoolgirls! :) Who is afraid of the complexity should use BASIC.
>
> I like D1 mostly because it's quite less complex that C++, that's the first
> thing I ask to a new language like D. Complexity "kills".
I am cit
Don пишет:
> Weed wrote:
>> Don пишет:
>>
>>>>>>> That must mean that you inherit that class only to avoid duplicating
>>>>>>> code. And that is easily done with template mixins.
>>>>>> It is possible that this polymorphism
Christopher Wright пишет:
> Weed wrote:
>> As a result, classes will be slow, or require more code to achieve
>> speeds comparable to C++.
>>
>> That is actually a model of classes D harder than C++.
>
> Yes, C++ offers more unsafe optimizations than D.
Str
Don пишет:
> That must mean that you inherit that class only to avoid duplicating
> code. And that is easily done with template mixins.
It is possible that this polymorphism is not needed and should be
prohibited for operations by value. The class is ready, why it should
not
Don пишет:
> Weed wrote:
>> Weed пишет:
>>> Bill Baxter пишет:
>>>> On Sun, Feb 22, 2009 at 1:02 AM, Weed wrote:
>>>>> Bill Baxter пишет:
>>>>>> 2009/2/21 Weed :
>>>>>>> Weed пишет:
>>>>>>>
Christopher Wright пишет:
> Kagamin wrote:
>> Weed Wrote:
>>
>>>>> But why not allow this operation at the same speed that allows C++?
>>>> If you pass it by value you'll lose polymorphism.
>>> It is possible that this polymorphism is not nee
Don пишет:
> Weed wrote:
>> naryl пишет:
>>
>>>>>>>> --bb
>>>>>>> http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=83506
>>>>>>>
>>>>>>
naryl пишет:
>> --bb
> http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=83506
You should use a struct there! Your code does not show you doing
anything that would even remotely suggest using a class is worthwhile.
You're doi
Weed пишет:
> Bill Baxter пишет:
>> On Sun, Feb 22, 2009 at 1:02 AM, Weed wrote:
>>> Bill Baxter пишет:
>>>> 2009/2/21 Weed :
>>>>> Weed пишет:
>>>>>> Bill Baxter пишет:
>>>>>>
>>>>>>> Why don
Bill Baxter пишет:
> On Sun, Feb 22, 2009 at 1:02 AM, Weed wrote:
>> Bill Baxter пишет:
>>> 2009/2/21 Weed :
>>>> Weed пишет:
>>>>> Bill Baxter пишет:
>>>>>
>>>>>> Why don't you just show us the class in the way yo
Bill Baxter пишет:
> 2009/2/21 Weed :
>> Weed пишет:
>>> Bill Baxter пишет:
>>>
>>>> Why don't you just show us the class in the way you would like to
>>>> write it in C++, and we'll show you how to write it in D, or finally
>>>
Weed пишет:
> Bill Baxter пишет:
>
>> Why don't you just show us the class in the way you would like to
>> write it in C++, and we'll show you how to write it in D, or finally
>> agree with you that it's not possible. But as long as you continue
>&g
Bill Baxter пишет:
> Why don't you just show us the class in the way you would like to
> write it in C++, and we'll show you how to write it in D, or finally
> agree with you that it's not possible. But as long as you continue
> to be hand-wavy about "common base classes" we're at a bit of an
>
Kagamin пишет:
> Weed Wrote:
>
>> Good (I think) use cases have been in this thread
>
> They may be good, but they don't show what can be done in C++ and can't be
> done in D. You were advised to use structs for value semantic.
We are beginning to repeat itsel
Kagamin пишет:
> Weed Wrote:
>
>> Good (I think) use cases have been in this thread
>
> They may be good, but they don't show what can be done in C++ and can't be
> done in D. You were advised to use structs for value semantic.
We are beginning to repeat itsel
Don пишет:
> Weed wrote:
>> Don пишет:
>>> Weed wrote:
>>>> Christopher Wright пишет:
>>>>> Weed wrote:
>>>>>> Kagamin пишет:
>>>>>>> Weed Wrote:
>>>>>>>
>>>>>>>> Will
Don пишет:
> Weed wrote:
>> Christopher Wright пишет:
>>> Weed wrote:
>>>> Kagamin пишет:
>>>>> Weed Wrote:
>>>>>
>>>>>> Will the language change?
>>>>> Hmm... You already has Walter's answer. He'
Christopher Wright пишет:
> Weed wrote:
>> Kagamin пишет:
>>> Weed Wrote:
>>>
>>>> Will the language change?
>>> Hmm... You already has Walter's answer. He's the boss.
>>
>> I want a more specific answer (yes or no) if possible
Kagamin пишет:
> Weed Wrote:
>
>> Will the language change?
>
> Hmm... You already has Walter's answer. He's the boss.
I want a more specific answer (yes or no) if possible...
What is the result of the discussion?
Will the language change? Not once, could in 6-12 months?..
For me, the answer to that question was tantamount to answering the
question "whether or not to use D for new projects?"
Weed пишет:
> (Has started here:
> http://www.digital
Michel Fortin пишет:
> On 2009-02-09 07:00:56 -0500, Weed said:
>
>>> No. By forbiding the cases that leads to slicing, like returning a
>>> polymorphic object by value.
>>
>> Let's think, can there are other ways to solve problem?
&g
Christopher Wright пишет:
> Weed wrote:
>> And if I need some different such combinations? For each it is necessary
>> to write such 8-10 lines? This is terrible!
>
> You need to add those lines for every method you need virtual dispatch
> with for your value type. It'
Kagamin пишет:
> Weed Wrote:
>
>>>>> Well, D class code here is not equivalent to C++ class code. D code has
>>>>> more features, namely, it's polymorphic: C.opAdd is able to work with
>>>>> classes, derived from C, while corresponding C++
Michel Fortin пишет:
> On 2009-02-08 23:43:13 -0500, Weed said:
>
>> Michel Fortin пишет:
>>> On 2009-02-08 09:30:08 -0500, Weed said:
>>>
>>>> Let's assume, polymorphism is necessary to these objects
>>>
>>> Polymorphism doe
Kagamin пишет:
> Weed Wrote:
>
>>> Well, D class code here is not equivalent to C++ class code. D code has
>>> more features, namely, it's polymorphic: C.opAdd is able to work with
>>> classes, derived from C, while corresponding C++ code is unable to do so
Kagamin пишет:
> Weed Wrote:
>
>> The code on C++ is also approximately in 6 times faster a code with
>> classes on D. (I do not give an example on C++ because classes on C++
>> work just as structures in D.)
>
>> class C {
>> int i;
>> real[5
Kagamin пишет:
> Weed Wrote:
>
>> The code on C++ is also approximately in 6 times faster a code with
>> classes on D. (I do not give an example on C++ because classes on C++
>> work just as structures in D.)
>
>> class C {
>> int i;
>> real[5
naryl пишет:
> Weed Wrote:
>> naryl яПНяПНяПНяПНяПН:
>>> Weed Wrote:
>>>> Denis Koroskin яПНяПНяПНяПНяПНяПНяПНяПНяПНяПНяПНяПНяПНяПНяПН:
>>>>
>>>>> And here are results (best/average of 3 runs):
>>>>>
>>>>>
Michel Fortin пишет:
> On 2009-02-08 09:30:08 -0500, Weed said:
>
>> Let's assume, polymorphism is necessary to these objects
>
> Polymorphism doesn't work very well while passing objects by value, even
> in C++. This is called the slicing problem.
> <http
Christopher Wright пишет:
> Weed wrote:
>> Christopher Wright пишет:
>>> Weed wrote:
>>>> (Has started here:
>>>> http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=81359)
>>>>
>>>>
>>
Adam D. Ruppe пишет:
> On Mon, Feb 09, 2009 at 09:59:50AM +0700, Weed wrote:
>> Perfectly - it is necessary to leave this question to the programmer:
>> the class will be stored in a stack or in a heap is better will solve
>> the programmer instead of the compiler.
>
>
Radu пишет:
> While nor so orthodox, this improves the situation a bit:
>
> template stackAllocator(T) {
>new(size_t size, void* sp = alloca(T.classinfo.init.length)) {
>return sp;
>}
>
>delete(void* ptr) {
>}
> }
>
> final class C {
>int i;
>real[5] unused; // t
Walter Bright пишет:
> Frits van Bommel wrote:
>> Which helps (a bit) with the two instances allocated in main(), but is
>> rather unhelpful with the 100_000_000 allocated in opAdd() (they're
>> returned)...
>
> The use of classes in this example is like using a screwdriver as a
> hammer. It'll wo
Rainer Deyke пишет:
> Michel Fortin wrote:
>> Polymorphism doesn't work very well while passing objects by value, even
>> in C++. This is called the slicing problem.
>
> I have heard about the slicing problem. I know what it is. But in all
> my years of using C++ as my primary language, I have n
Christopher Wright пишет:
> Weed wrote:
>> (Has started here:
>> http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=81359)
>>
>>
>> To me still does not give rest performance of classes (in comparison
>> with C++ or wit
naryl пишет:
> Weed Wrote:
>> Denis Koroskin яПНяПНяПНяПНяПН:
>>
>>> And here are results (best/average of 3 runs):
>>>
>>> DMD2.023 - 12.492/12.576 ms (-O -inline)
>>> DMC8.42n - 13.941/14.131 ms (-O -inline)
>>>
>>>
>> T
Denis Koroskin пишет:
> And here are results (best/average of 3 runs):
>
> DMD2.023 - 12.492/12.576 ms (-O -inline)
> DMC8.42n - 13.941/14.131 ms (-O -inline)
>
>
Try to return from value() a class instance
Denis Koroskin пишет:
>>
>> [skip]
>>
>>> Apparently, it doesn't work at the moment because ctor can't be a
>>> template :(
>>> Is there an enhancement request in bugzilla? It prevents this pattern
>>> from working.
>>
>> + it is difficult and also it will be even more difficult if it will be
>> n
Denis Koroskin пишет:
> Your C objects have value semantics. For value semantics you should use value
> types.
At present in D is not contain support of value types for objects.
(I consider that it is necessary)
> Alternatively you may want to use the following trick (I used it for lazy
> stri
Weed пишет:
> Daniel Keep пишет:
>> Weed wrote:
>>> [snip]
>> If I had to take a guess, I'd say that it's six times slower because
>> you're performing 100 million allocations. You aren't benchmarking
>> class/struct overhead, you're
Daniel Keep пишет:
> Weed wrote:
>> [snip]
>
> If I had to take a guess, I'd say that it's six times slower because
> you're performing 100 million allocations. You aren't benchmarking
> class/struct overhead, you're benchmarking the overhead o
(Has started here:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=81359)
To me still does not give rest performance of classes (in comparison
with C++ or with D structs)
I still think that it is a serious problem.
Colleagues from our national D forum have as
Weed пишет:
> Denis Koroskin пишет:
>> On Sun, 11 Jan 2009 05:04:11 +0300, Weed wrote:
>>
>>> Bill Baxter пишет:
>>>> 2009/1/11 Weed :
>>>>> Bill Baxter пишет:
>>>>>
>>>>>> But since classes can be polymorphi
Weed пишет:
> Denis Koroskin пишет:
>> On Sun, 11 Jan 2009 05:04:11 +0300, Weed wrote:
>>
>>> Bill Baxter пишет:
>>>> 2009/1/11 Weed :
>>>>> Bill Baxter пишет:
>>>>>
>>>>>> But since classes can be polymorphi
Andrei Alexandrescu пишет:
> Brad Roberts wrote:
>> Andrei Alexandrescu wrote:
>>> Weed wrote:
>>>> Weed пишет:
>>>>
>>>>>>> 4. Java and C# also uses objects by reference? But both these of
>>>>>>> language are
Weed пишет:
>>> 4. Java and C# also uses objects by reference? But both these of
>>> language are interpreted. I assume that the interpreter generally with
>>> identical speed allocates memory in a heap and in a stack, therefore
>>> authors of thes
Denis Koroskin пишет:
> On Sun, 11 Jan 2009 05:04:11 +0300, Weed wrote:
>
>> Bill Baxter пишет:
>>> 2009/1/11 Weed :
>>>> Bill Baxter пишет:
>>>>
>>>>> But since classes can be polymorphic, value copying gets you into
>>>>
Bill Baxter пишет:
> 2009/1/11 Weed :
>> Bill Baxter пишет:
>>
>>> But since classes can be polymorphic, value copying gets you into
>>> slicing problems. That's why value copying is disabled to begin with.
>>> So disabling value copies is a good th
Bill Baxter пишет:
> 2009/1/11 Weed :
>> Bill Baxter пишет:
>>
>>> But since classes can be polymorphic, value copying gets you into
>>> slicing problems. That's why value copying is disabled to begin with.
>>> So disabling value copies is a good th
Bill Baxter пишет:
> But since classes can be polymorphic, value copying gets you into
> slicing problems. That's why value copying is disabled to begin with.
> So disabling value copies is a good thing.
It is not always a good thing.
I propose to prohibit only the copying by value of the base
Christopher Wright пишет:
> Weed wrote:
>> Denis Koroskin пишет:
>>
>>> I'd suggest you to state you ideas as simple and keep your posts as
>>> small as possible (trust me, few people like reading long posts).
>>
>> The extra-short formulati
Christopher Wright пишет:
> Weed wrote:
>> Denis Koroskin пишет:
>>
>>> I'd suggest you to state you ideas as simple and keep your posts as
>>> small as possible (trust me, few people like reading long posts).
>>
>> The extra-short formulati
Denis Koroskin пишет:
> I'd suggest you to state you ideas as simple and keep your posts as
> small as possible (trust me, few people like reading long posts).
The extra-short formulation of my idea:
Objects should be divided on POD (struct) and non-POD (class).
Instead of such division as now:
Bill Baxter пишет:
>>
>> Please, state critical remarks
>
> Your English is really hard to make sense of.
> That's my guess for why there are no responses.
> Heck, I'd *like* to respond, but I just can't tell what you're trying to say.
All is absolutely poor? If not everything, can you select th
Denis Koroskin пишет:
> Back to topic, C++ doesn't have any meaningful separation between
> classes and structs. D does - (one of it is that) classes are heap
> allocated by default whereas structs are stack allocated by default. You
> can override either behavior:
>
> class C {}
> struct S {}
>
Weed пишет:
> Weed пишет:
>> (Here I generalise my sentence with supplement)
>>
>>
>> The POD data and the data supporting polymorphism are necessary to us.
>> POD the data is stored in structs and polymorphic objects is classes.
>>
>> Both types (class
Bill Baxter пишет:
> On Fri, Jan 9, 2009 at 2:43 PM, Weed wrote:
>> Weed пишет:
>>> Bill Baxter пишет:
>>>> 2009/1/9 Weed :
>>>>> Bill Baxter пишет:
>>>>>> Another thread just reminded me of something I use frequently in
Nick Sabalausky пишет:
> "Weed" wrote in message
> news:gk6n29$218...@digitalmars.com...
>> Bill Baxter ?????:
>>> 2009/1/9 Weed :
>>>> Bill Baxter ?:
>>>>> Another thread just reminded me of something I use frequently in C++
Bill Baxter пишет:
> On Fri, Jan 9, 2009 at 2:22 PM, Weed wrote:
>> Bill Baxter пишет:
>>> 2009/1/9 Weed :
>>>> Bill Baxter пишет:
>>>>> Another thread just reminded me of something I use frequently in C++
>>>>> that doesn'
Weed пишет:
> Bill Baxter пишет:
>> 2009/1/9 Weed :
>>> Bill Baxter пишет:
>>>> Another thread just reminded me of something I use frequently in C++
>>>> that doesn't work in D because ++x is not an lvalue:
>>>>
>>>>int x
Bill Baxter пишет:
> 2009/1/9 Weed :
>> Bill Baxter пишет:
>>> Another thread just reminded me of something I use frequently in C++
>>> that doesn't work in D because ++x is not an lvalue:
>>>
>>>int x,N;
>>> ...
>>>
Bill Baxter пишет:
> Another thread just reminded me of something I use frequently in C++
> that doesn't work in D because ++x is not an lvalue:
>
>int x,N;
> ...
>++x %= N;
>
> So is there some deep reason for not making it an lvalue like in C++?
>
++x is x+=1 in D:
void main() {
Weed пишет:
> (Here I generalise my sentence with supplement)
>
>
> The POD data and the data supporting polymorphism are necessary to us.
> POD the data is stored in structs and polymorphic objects is classes.
>
> Both types (class and struct) can be instanced in a heap
(Here I generalise my sentence with supplement)
The POD data and the data supporting polymorphism are necessary to us.
POD the data is stored in structs and polymorphic objects is classes.
Both types (class and struct) can be instanced in a heap or on a stack.
(And in invariant ROM too, but ther
Weed пишет:
> Bill Baxter пишет:
>> On Tue, Jan 6, 2009 at 1:41 PM, Christopher Wright
>> wrote:
>>> Weed wrote:
>>>> Who agrees with me? There are still ideas as it is possible to solve
>>>> this problem and not to destroy language?
>>>
Bill Baxter пишет:
> On Tue, Jan 6, 2009 at 1:41 PM, Christopher Wright wrote:
>> Weed wrote:
>>> Who agrees with me? There are still ideas as it is possible to solve
>>> this problem and not to destroy language?
>> When you reply to your reply to your r
Christopher Wright пишет:
> Weed wrote:
>> Who agrees with me? There are still ideas as it is possible to solve
>> this problem and not to destroy language?
>
> When you reply to your reply to your reply to your post and nobody else
> replies to any of your posts, you m
Weed пишет:
> Weed пишет:
>> Weed пишет:
>>> Andrei Alexandrescu пишет:
>>>> Weed wrote:
>>>> [about structs vs. classes]
>>>>> It is very a pity.
>>>>> My small opinion: it is impossible to reduce performance for strug
Don пишет:
> Weed wrote:
>> Don пишет:
>>> Weed wrote:
>>>> Don пишет:
>>>>> Weed wrote:
>>>>>> Don пишет:
>>>>>>> Weed wrote:
>>>>>>>> Frits van Bommel пишет:
>>>>>>>&g
Weed пишет:
> Weed пишет:
>> Andrei Alexandrescu пишет:
>>> Weed wrote:
>>> [about structs vs. classes]
>>>> It is very a pity.
>>>> My small opinion: it is impossible to reduce performance for struggle
>>>> against potential errors -
Don пишет:
> Weed wrote:
>> Don пишет:
>>> Weed wrote:
>>>> Don пишет:
>>>>> Weed wrote:
>>>>>> Frits van Bommel пишет:
>>>>>>> Don wrote:
>>>>>>>> Frits van Bommel wrote:
>
Don пишет:
> Weed wrote:
>> Don пишет:
>>> Weed wrote:
>>>> Frits van Bommel пишет:
>>>>> Don wrote:
>>>>>> Frits van Bommel wrote:
>>>>>>> Don wrote:
>>>>>>>> A straightforward first step w
Don пишет:
> Weed wrote:
>> Frits van Bommel пишет:
>>> Don wrote:
>>>> Frits van Bommel wrote:
>>>>> Don wrote:
>>>>>> A straightforward first step would be to state in the spec that "the
>>>>>> compiler is e
Weed пишет:
> Andrei Alexandrescu пишет:
>> Weed wrote:
>> [about structs vs. classes]
>>> It is very a pity.
>>> My small opinion: it is impossible to reduce performance for struggle
>>> against potential errors - such languages already are, it more
1 - 100 of 131 matches
Mail list logo
