View mode: basic / threaded / horizontal-split · Log in · Help
December 15, 2005
Re: A safer/better C++?
"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
December 15, 2005
Re: A safer/better C++?
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.
> 
>
December 15, 2005
Re: A safer/better C++?
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
December 15, 2005
Bit-array cleanup?
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
December 15, 2005
languages: evolution and death
"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.
December 15, 2005
Re: Bit-array cleanup?
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
December 15, 2005
Re: languages: evolution and death
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 ;)
December 15, 2005
Re: A safer/better C++?
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
December 15, 2005
Re: A safer/better C++?
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."
December 15, 2005
Re: A safer/better C++?
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."
6 7 8 9 10 11 12 13
Top | Discussion index | About this forum | D home