"Niko Korhonen" <niktheblak@hotmail.com> wrote in message news:dnrcn8$2n9f$1@digitaldaemon.com...
> Dave wrote:
>> MyClass mc = new MyClass; // heap
>> MyClass mc2 = MyClass; // RAII (stack or heap, depending on implementor
>> choice (i.e.: GC and machine architecture))
>
> So, is 'new MyClass;' equivalent to 'new MyClass();' now? Why not add


IIRC, it has been that way for as long as I've been playing with D (over a year).

> 'int x(5);' in addition to 'int x = 5;' as well...

No, but maybe 'int x = int(5);' because along with the new RAII syntax for classes, I think that would be very useful for templates to cut down on 'static if(is(...))' and still be able to use the same templates. For example:

// T could now be a native data type, or
//  a struct with a static opCall() and opMul(), or
//  a class with a copy ctor and opMul() returning a new'd (on the heap)
class
//  In another words, trully 'generic' in that the same template could be
used for all w/o
//   using conditional compilation.
template Foo(T)
{
    T Foo(T i)
    {
        T x = T(i);
        return x * x;
    }
}

One other thing to fill that out would be ctors for structs., but the new RAII syntax for classes should go a long way in this area I think.

I see the argument you're making w.r.t. different coding standards, but IMHO, one of the big reasons C++ is still as popular as it is, is because one can allocate objects on the stack with it and Java can't, making it much better performing for a lot of problem domains out there.

>> Maybe I'm misunderstanding you but that sounds pretty definitive; where are you getting this information? Walter made no such commitments that I've ever seen for v0.142.
>
> No, I just pulled the version number out of my hat :) Let's call it v0.1xy instead.
>
> -- 
> Niko Korhonen
> SW Developer

Right on dude!!
I didn't really like type inference, but oh well, it can come in handy sometimes with long class names ..

However, I'm very worried about this stack allocation thing (when and where did Walter say that he was gonna implement it?!), IMO it'll be a step in the wrong direction (C++).

One of the things I hate most about C++ is the fact that you can allocate objects (class instances) on the stack OR on the heap, you have this choice, and it's always hard to make a decision, if it was up to me, I'd always create objects on the heap, but the problem is, the STL has alot of objects which are meant to be allocated on the stack, i.e. string, vector, list, map ... etc. The problem is, these classes have much of their functionality in overloaded operators, i.e. the implementation relies on operator overloading, and if you allocate these objects on the heap, you'd have to use pointers, in which case you won't be able to use the overloaded operators without some nasty, ugly work-arounds.

I liked java because there's only one way to create objects, and one way to use them!!
One of the main things that attracted me to D was that it's (C++)-like, yet it borrowed the right things from java (class syntax).
Another thing that attracted me is the fact that classes are written in one block, no seperate declaration and implementation (.h and .cpp) crap.
One more thing is that D has no confusing things like
> void func(const MyClass& myClass);
> void func(const MyClass* myClass);


etc ..

Just my two cents, but the I'm seeing it (or that's how it seems to me)  is that D is somehow moving in the wrong direction.


Niko Korhonen wrote:
> Tom S wrote:
> 
>> What complexity ? We already have it. It's all about the syntactic sugar.
> 
> 
> No, not as such IMO. Struct semantics are different enough from class semantics for them not to get mixed in that manner and the current stack allocation scheme for classes (using alloca) is so ugly and obscure that no one uses it unless it's absolutely necessary.
> 
> After the new stack allocation syntax addition we have a simple, viable way of creating class instances both on the heap and on the stack. So now we have to *choose whether we want stack or heap instances whenever we are creating a class instance*.
> 
> Each time you fork the language construct in two, you get two schools of thought. These two schools of thought will wage war on each indefinitely. This is exactly what happened with C++ (in an extreme manner) and nowadays every C++ programmer knows and uses a different subset of the language and wages war with the other programmers.
> 
> Consider:
> 
> int x = 5;
> int x(5);
> 
> Which is better?
> 
> MyClass a;
> MyClass a = MyClass();
> 
> Again, which is better?
> 
> void func(const MyClass& myClass);
> void func(const MyClass* myClass);
> 
> Again, which is better?
> 
> C++ has created millions of ways to do the same thing, i.e. the language is full of redundant constructs. A couple of recent additions to D (type inference and stack allocation) have forked/will fork the language in two, now we have to choose between:
> 
> auto c = new MyClass();
> MyClass c = new MyClass(); // Which is better?
> 
> and soon:
> 
> auto c = MyClass();
> auto c = new MyClass();
> 
> People are bound to create Coding Guidelines for D with one saying 'Always use type inference' and the other saying 'Never use type inference'. I've read three different company internal style guides for C++ and all of them are completely different. I don't want the same to happen to D.
> 
> The point that I'm desperately (and rather poorly come to think of it) trying to make is that we should keep the number of lanugage constructs to a bare minimum and absolutely ban any redundant constructs. This helps to keep the language shareable, clean and easy to understand and easy to parse.
> 
> Whenever there is a choice between language constructs programmers will fight about which one is better. The only historically proven way to alleviate this issue is to reduce the number of choices. The C++ gurus standard answer of 'educating the programmers better' hasn't worked in the real world.
> 
> Only if and only if there are no choices between language constructs to fight about, programmers will not fight about them. Otherwise they will.
> 
> 

Walter Bright wrote:
> In article <dnoru3$mgr$1@digitaldaemon.com>, Niko Korhonen says...
>> I also would like to see bit arrays and AA's in the standard library instead of the language; IMO D isn't high-enough level language for that.
> 
> While I agree that bit arrays in the core language, in retrospect, were probably
> a mistake they are in the language, are used, and so need to stay.

But how often are they used in a way that would be incompatible with arrays of 1-byte bits?  I'll admit that I do like being able to use packed bit arrays from time to time (their use with slicing can be pretty cool), but just as often I don't want them.  Most recently, it was when I wanted to do this:

bit[] set;

foreach( inout bit; set ) { ... }

Obviously impossible with a packed array so I was forced to choose between double lookups (not a big deal with arrays, but annoying) and using another data type... I chose to use an array of ubytes, instead, and suffer the slight lack of value restrictions.  This almost has me wishing there were a bool type in addition to the bit type, simply so both options were available.


Sean

Since Walter feels that bit-arrays in the core-language were (in retrospect) probably a mistake, I think there's a really good opportunity to heal a wart.

Suppose there were a nice library-based bitset ~ just how much effort would be needed to clean up now rather than later? Is most of the usage actually within Phobos? Would those people who actually use bit-arrays kick and scream all the way to hell and back?

How about it?

- Kris



"Sean Kelly" <sean@f4.ca> wrote in message news:dnsch6$enq$1@digitaldaemon.com...
> Walter Bright wrote:
>> In article <dnoru3$mgr$1@digitaldaemon.com>, Niko Korhonen says...
>>> I also would like to see bit arrays and AA's in the standard library instead of the language; IMO D isn't high-enough level language for that.
>>
>> While I agree that bit arrays in the core language, in retrospect, were
>> probably
>> a mistake they are in the language, are used, and so need to stay.
>
> But how often are they used in a way that would be incompatible with arrays of 1-byte bits?  I'll admit that I do like being able to use packed bit arrays from time to time (their use with slicing can be pretty cool), but just as often I don't want them.  Most recently, it was when I wanted to do this:
>
> bit[] set;
>
> foreach( inout bit; set ) { ... }
>
> Obviously impossible with a packed array so I was forced to choose between double lookups (not a big deal with arrays, but annoying) and using another data type... I chose to use an array of ubytes, instead, and suffer the slight lack of value restrictions.  This almost has me wishing there were a bool type in addition to the bit type, simply so both options were available.
>
>
> Sean

"Walter Bright" <Walter_member@pathlink.com> wrote
> In article <dnos3h$mp9$1@digitaldaemon.com>, Niko Korhonen says...
>>I've seen a project at my work place that has stuck into Java 1.3.1_b24 forever because of some nasty breaking changes in the immediately following JDK version. It's horrible when that happens. Probably the worst thing that can happen in software development.
>
> I agree this can happen - and it does happen with every language. The flip
> side
> is that if D doesn't constantly improve as a language, it will die. Show
> me a
> language that is unchanging and I'll show you a dead language. D has no
> choice
> but to move forward.

The great grand-daddy of OOP is Simula. For those who don't know anything about it, you might be rather surprised at just how little things have changed since 1967 (yes, almost 40 years).

Simula died because it was deliberately and explicitly fixed in stone.

On Thu, 15 Dec 2005 10:40:45 -0800, Kris wrote:

> Since Walter feels that bit-arrays in the core-language were (in retrospect) probably a mistake, I think there's a really good opportunity to heal a wart.
> 
> Suppose there were a nice library-based bitset ~ just how much effort would be needed to clean up now rather than later? Is most of the usage actually within Phobos? Would those people who actually use bit-arrays kick and scream all the way to hell and back?
> 
> How about it?

I don't use bit arrays but I do you bool associative arrays.

-- 
Derek Parnell
Melbourne, Australia
16/12/2005 6:32:53 AM

Kris wrote:

> "Walter Bright" <Walter_member@pathlink.com> wrote
>> In article <dnos3h$mp9$1@digitaldaemon.com>, Niko Korhonen says...
>>>I've seen a project at my work place that has stuck into Java 1.3.1_b24 forever because of some nasty breaking changes in the immediately following JDK version. It's horrible when that happens. Probably the worst thing that can happen in software development.
>>
>> I agree this can happen - and it does happen with every language. The
>> flip side
>> is that if D doesn't constantly improve as a language, it will die. Show
>> me a
>> language that is unchanging and I'll show you a dead language. D has no
>> choice
>> but to move forward.
> 
> The great grand-daddy of OOP is Simula. For those who don't know
antioything
> about it, you might be rather surprised at just how little things have changed since 1967 (yes, almost 40 years).
> 
> Simula died because it was deliberately and explicitly fixed in stone.

In the first year of my studies (in '98), I was so lucky to attend a lecture by Kristen Nygaard, one of the two original designers of Simula. Inspirational beyond belief. A man for the programming legends, even compared to Walter ;)

On Thu, 15 Dec 2005 11:11:44 -0700, Hasan Aljudy <hasan.aljudy@gmail.com> wrote:
> One of the things I hate most about C++ is the fact that you can allocate objects (class instances) on the stack OR on the heap, you have this choice, and it's always hard to make a decision, if it was up to me, I'd always create objects on the heap, but the problem is, the STL has alot of objects which are meant to be allocated on the stack, i.e. string, vector, list, map ... etc. The problem is, these classes have much of their functionality in overloaded operators, i.e. the implementation relies on operator overloading, and if you allocate these objects on the heap, you'd have to use pointers, in which case you won't be able to use the overloaded operators without some nasty, ugly work-arounds.

It's my impression (because Walter has been rather closed mouthed about the idea) that heap or stack allocation will have no effect (and/or should have no effect) on how a class reference behaves, eg:

MyClass a = MyClass(); //stack
MyClass b = new MyClass(); //heap
MyClass c;

a.foo();
b.foo();
c = a * b;

Therefore none of your above comments will apply to D :)

Regan

Niko Korhonen wrote:
> Tom S wrote:
> 
>>> auto class StackObj;
>>> class HeapObj;
>>>
>>> StackObj obj0; // Stack-allocated, default-value initialized
>>> StackObj obj1 = new StackObj(); // Stack-allocated
>>> HeapObj obj2 = new HeapObj(); // Heap-allocated
>>
>>
>> Sometimes I'd like to have a class object defined on the stack, sometimes on the heap (without RAII), would I have then to make 2 classes ?
> 
> 
> Yes, this is true, I actually didn't think about that very much. In the C# scheme the allocation information is a part of the type itself and cannot be decided during instantiation. This is rather limiting, and can already be done in D with structs.
> 
C# has auto? Where did you see that? I don't think it has auto in C# 2.0, and for what I've searched, neither in 3.0 .

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."

Lucas Goss wrote:
> JT wrote:
> 
> I also think D is an ideal game programming language. In fact, game programming is how I found D in the first place. I was looking for a language that took all of the intentions of C++ but got rid of all of the bad (or difficult) things of trying to be compatible with C (or use C as a subset).
> 
Same here. I first heard about D in a slashdot article some years ago. I
looked at it at a glance and found some of the basic features(i.e. C++ fixes)
very cool (no header files, defined primitive types size, etc.) but then
left it at that.
It was only a year later, after working on my first "real" (and by real,
I mean a big enough one to get some good perspective on C++, not just some 2-3 cpp files projects) C++ academic semester-length project (which
was a game), that I immediately and irrevocably got sick of C++. How
could any one ever program in *that*? I fraking gives me shivers.. :/ So I then starting looking into D, and i've since stopped any hobbying multimedia_app/game learning and instead
starting learning about D, participating in the newsgroup, etc.


-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to
be... unnatural."