"Derek Parnell" <derek@psych.ward> wrote in message news:1ltc1ir9rny3r.1vwocglyyu3uu.dlg@40tude.net...
> 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.


me too, but I think that's implemented akin to a byte-AA instead? That is, I doubt it would be impacted.

Bruno Medeiros wrote:
>
> 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.. :/

That's the big problem with C++: it supports so many different programming techniques that maintaining a coherent design philosophy in a team can be extremely difficult.  I found that with D my productivity quite rapidly exceeded what it is in C++ (and I'm no slouch at C++), and the code was more readable and easier to maintain.  That alone makes D a big win in my book.


Sean

Bruno Medeiros wrote:
> 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 .
> 

2.0 no, but 3.0 yes, it is called var instead of auto.

Regan Heath wrote:
> 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

I don't mind if the question of "where to allocate objects" is implementation-dependent, so that an implementation can create raii objects on the stack if the compiler author wishes to do so ..

However, doing it in a cpp-like way /maybe/ a step in the wrong direction.
You're right, this alone wouldn't be so bad, but I'm worried a bit about the future :P

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.
> I'll disagree with the AA's. I use them and like them a lot. It's a well used
> data structure, and having them in the core makes them just sweet.

Why? I find them very convenient (and cool), although I haven't used them in a serious project/program.
It's kind of a nice way to market D, you know ..

# import std.stdio;
# void main()
# {
# 	int someThing = 23421; //whatever
# 	writefln( someThing );
# 	bit * b = cast(bit* )&someThing;
# 	b[3] = 0;
# 	b[6] = 1;
# 	b[4] ^= 0;
# 	writefln( someThing );
# }


looks attractive to me!

Lucas Goss wrote:
> I also think D is an ideal game programming language. 

Even a newbie like myself can concur on that note :-P

> But anyways I've used Torque, OGRE, GeometricTools (used to be Wild-Magic), and lately I've been using OSG. My main problem is that all of those are in C++, which means I would have to redo all (or parts) of those libraries. Guess I better get coding...

Hrm.. well it isn't that bad. You can help out the Sinbad folks once that gets rolling ( http://www.dsource.org/projects/sinbad/ ).

Also, you don't necessarily have to convert all C++ code to D, you can create a C++ --> C --> D wrapper.

In article <dnsbkv$e59$1@digitaldaemon.com>, Hasan Aljudy says...
>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.

You raise a very important issue. I think the answer is that, athough a class object can be located on the stack or on the heap, the syntax with which you access it always remains the same. You don't have to worry about whether to use , ->, or & (by reference). Not only is the syntax all the same for D (the .), but the *semantics* are all the same.

The difference will be that stack objects will go away when the function exits.

The reason to have the stack allocated objects is that it opens up a large avenue of applications for templates.

Walter Bright wrote:
> The reason to have the stack allocated objects is that it opens up a large
> avenue of applications for templates.

I couldn't help but noticing that a very large portion of the recent D feature additions have to do with template (meta)programming.

Does allowing templates in a language necessarily lead to gradually increasing complexity until the language's template mechanism and supporting features start to look like C++?

-- 
Niko Korhonen
SW Developer

Bruno Medeiros wrote:
>> 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 .

No, what I mean is that C# has a stack allocated data type 'struct'. Therefore if you declare your object as 'struct' they are always stack allocated (even when they are instantiated with the 'new' syntax) and if you declare your object 'class' they are always heap-allocated. Like such:

struct MyStruct { }
class MyClass { }

MyStruct m = new MyStruct(); // stack allocation
MyClass c = new MyClass(); // heap allocation

C# has the 'using' pattern which emulates RAII to some extent:

using (MemoryStream m = new MemoryStream())
{
} // m.Dispose() is called at the end of the scope

-- 
Niko Korhonen
SW Developer

Walter Bright wrote:
 > 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.

C++ has been unchanging for almost eight years now unless it counts that the compiler vendors have just recently started to implement *all* of the C++98 specification <g>

C has been theoretically unchanging for six years since the C99 standard but practically for a whopping 16 years since C89 standard!

But really, I agree with you. I'm basically just hoping that the D 1.0 spec would happen.

> That said, there is good reason to fork D once 1.0 is set - one fork will be
> purely bug fixes, the language improvements go into the other fork.

Sweet :)

-- 
Niko Korhonen
SW Developer