"Georg Wrede" <georg.wrede@nospam.org> wrote in message news:440B99E1.6090000@nospam.org...
> Walter Bright wrote:
>> Should D support trigraphs?
> No. Period!

I agree <g>. No danger of that happening.

> A historical note: They never were more than a make-believe solution for "other peoples' problem". In the good Old Days, when we would have needed trigraphs, we still didn't use them.

I know. Trigraphs are a fine example of a solution that was so awful that people preferred the problem.

> Last, but not least: the problem trigraphs seek to remedy, is such pre-ancient history that it should not even be mentioned with a modern programming language.

Yup. Trigraphs are not the solution, UTF is.

Georg Wrede wrote:
> A historical note: They never were more than a make-believe solution for "other peoples' problem". In the good Old Days, when we would have needed trigraphs, we still didn't use them.

>> £include <stdio.h>
>>
>> int main(void)
>> ä
>>         char Ä5Å;
>>
>>         nÄ4Å = 'a';
>>         printf("%cÖn", nÄ4Å);
>>                 return Ü 0 ü 1 ö 2;
>> å
> 
> Incidentally, this same technique was usable (and was used) in all of the countries where non-US versions of ASCII were in use. It's based on the fact that any replacement of a US character was both typeable and printable. :-)

That's amazing! Thanks for that.

Now that I'm regularly using non-English keyboards regularly, I'm realizing how annoyingly English-centric the programming world is.
Example: ctrl-Z for undo. Great for US keyboard, really annoying on a German one, where the Z key is in the middle of the keyboard.
And [] {}, backslash and ~ are so hard to type...

I use a US keyboard with a custom layout -- I've defined AltGr to do
Ü etc, but without the stupidity of making "a = ä, which is the default "US international" setting. No C programmers involved with that decision, I reckon. I find it simply unbelievable that on Windows, the default US keyboard layout still had no € key, last time I checked.

Jeremy wrote:
> In article <duab09$1arn$1@digitaldaemon.com>, Walter Bright says...
>> I started a new thread for this:
>>
>> "Mike Capp" <mike.capp@gmail.com> wrote in message news:dua67i$12cr$1@digitaldaemon.com...
>>> 7. D has all (well, most of) the power of C++
>> I see this often and am a bit perplexed by it. What power do you feel is missing?
>>
>> And what about the missing power in C++ - inline assembler, nested functions, contract programming, unit testing, automatic documentation generation, static if, delegates, dynamic closures, inner classes, modules, garbage collection, scope guard?
>>
>> What does D have to do to have more power than C++? 
>>
> 
> I'm not a power programmer, so I can't talk much about what their needs are --
> it sounds like you've already gotten some good input on what could make it more
> powerful. However, I think D is already powerful enough to be a big hit.
> 
> I'm going to go out on a limb and say Java isn't nearly as powerful as C/C++ is,
> but Java is more popular than C++ (according to http://www.tiobe.com/tpci.htm).

Hey, D is in #21, ahead of Ruby and Fortran! It's almost achieved 'B' status. Although I doubt that index is very reliable. :-)

Once D gets IFTI it will be more powerful than C++0x in most respects.
The ability to make lightweight classes is the only other area where I think C++ could claim a significant advantage.

I think we'll soon reach the point where D is completely limited by libraries and IDE-type issues. Walter will probably get a bit frustrated at that point, because he won't be able to do much about it...

Hasan Aljudy wrote:
>> It is not const methods so much as const in parameters.
>>
>> class A
>> {
>>  int bar=1;//bar should bee read only
>> }
>>
>> void foo(in i a)//I want a to bee readonly
>> {
>>     i.bar=2;//here the value should not be writable but since a is
>>             //a reference it is
>> }
>>
>> A a=new A;//bar is 1
>> foo(a);
>> print(a.bar);//prints 2
>>
>> It is not so very usefull in smal examples but if you have a large program and do that by mistake it could cause a bug. Basicaly it is a message from the writer of a class to it's users of how member are to bee used, and aditionaly it has compiler suport to catch typos and mistakes, if a user realy want to change the data against the orginal authors recomendations he can use a explicit cast.
> 
> Maybe I'm missing something, but why don't you just mak A.bar private?

Because then i would have to call a method to read bar and that would bee inefective. I know it is no big deal when bar is only an ont but when larger structures is copied the overhead can bee a significant slowdown. also privat does not protect from misstakes in the same class but if you do a cast you will think about why it is readonly in the first place.

Johan Granberg wrote:
> Walter Bright wrote:
>> "Miles" <_______@_______.____> wrote in message news:dub8id$2rn3$1@digitaldaemon.com...
>>> I hardly post anything to the NG, most of the time I just read to see
>>> how D is maturing... but I would like to leave my opinion on this subject:
>>
>> It's good to hear the opinions now and then of the lurkers, too, as they are just as important as the prolific posters.
> 
> In that case here is another lurker opinion.
> 
>>> 1. const parameters and member functions
>>>
>>> Countless times this saved me. I just can't imagine references being
>>> passed in and out of functions without something explicitly saying that
>>> the function is expected or not to modify it.
> 
> You did not answer the above statement and i have seen this repeated all over this thread along with destructors in structs. I will not repeat all the arguments but to me this is important issues.
> If i should rank the most showstoping things in D (from my perspective) it would be
> 1. bugs
> 2. as far as I know no way of inporting somthing in a parent directory (as C++ #include "../myheader.hpp")
> 3. read only sematics that work as a strong reminder that one is not suposed to modify somthing (but can bee subverted by a cast)
> 4. overlodable assignment and copy constructors.
> 5. library and other minor issues
> 
>>> 4. library
>>> ...
>> I don't find the STL compelling, either, and that's the only library thing standard C++ has over libc. Furthermore, large chunks of STL are simply irrelevant in D because D has core arrays, strings, and associative arrays.
> 
> I agree on this one. So wath is your plan for the D standard library?

I remembered another thing that i would like as well. This probably is omited by design but I would realy like to write member funktion definitions outside of their class. This way i can get the class definition down to a single page and that helps when trying to read the code later on as you can easily see the properities of a class at a glance.

Johan Granberg wrote:
> Hasan Aljudy wrote:
> 
>>> It is not const methods so much as const in parameters.
>>>
>>> class A
>>> {
>>>  int bar=1;//bar should bee read only
>>> }
>>>
>>> void foo(in i a)//I want a to bee readonly
>>> {
>>>     i.bar=2;//here the value should not be writable but since a is
>>>             //a reference it is
>>> }
>>>
>>> A a=new A;//bar is 1
>>> foo(a);
>>> print(a.bar);//prints 2
>>>
>>> It is not so very usefull in smal examples but if you have a large program and do that by mistake it could cause a bug. Basicaly it is a message from the writer of a class to it's users of how member are to bee used, and aditionaly it has compiler suport to catch typos and mistakes, if a user realy want to change the data against the orginal authors recomendations he can use a explicit cast.
>>
>>
>> Maybe I'm missing something, but why don't you just mak A.bar private?
> 
> 
> Because then i would have to call a method to read bar and that would bee inefective. 

You know, CPUs are fast now a days, a single function call is not "ineffective".

>I know it is no big deal when bar is only an ont but 
> when larger structures is copied the overhead can bee a significant slowdown. 

Objects don't get copied when they are passed to functions ..

> also privat does not protect from misstakes in the same class but if you do a cast you will think about why it is readonly in the first place.

I don't understand what you mean.

Hasan Aljudy wrote:
>> Because then i would have to call a method to read bar and that would bee inefective. 
> 
> You know, CPUs are fast now a days, a single function call is not "ineffective".

That argument does not hold if you are in a tight loop it will matter.

>> I know it is no big deal when bar is only an ont but when larger structures is copied the overhead can bee a significant slowdown. 
> 
> Objects don't get copied when they are passed to functions ..

But large structs does and if you want an objects variabls to bee unchanged you muse use dup.

>> also privat does not protect from misstakes in the same class but if you do a cast you will think about why it is readonly in the first place.
> 
> I don't understand what you mean.

That readonly is for both the occasions when you misspell somthing and refer to the wrong variable. (hard to find bug) and to present a user of your library with a contract of use.

In article <duhcek$d8f$1@digitaldaemon.com>, Don Clugston says...
>
>Jeremy wrote:
>> In article <duab09$1arn$1@digitaldaemon.com>, Walter Bright says...
>>> I started a new thread for this:
>>>
>>> "Mike Capp" <mike.capp@gmail.com> wrote in message news:dua67i$12cr$1@digitaldaemon.com...
>>>> 7. D has all (well, most of) the power of C++
>>> I see this often and am a bit perplexed by it. What power do you feel is missing?
>>>
>>> And what about the missing power in C++ - inline assembler, nested functions, contract programming, unit testing, automatic documentation generation, static if, delegates, dynamic closures, inner classes, modules, garbage collection, scope guard?
>>>
>>> What does D have to do to have more power than C++?
>>>
>> 
>> I'm not a power programmer, so I can't talk much about what their needs are -- it sounds like you've already gotten some good input on what could make it more powerful. However, I think D is already powerful enough to be a big hit.
>> 
>> I'm going to go out on a limb and say Java isn't nearly as powerful as C/C++ is, but Java is more popular than C++ (according to http://www.tiobe.com/tpci.htm).
>
>Hey, D is in #21, ahead of Ruby and Fortran! It's almost achieved 'B' status. Although I doubt that index is very reliable. :-)
>
>Once D gets IFTI it will be more powerful than C++0x in most respects. The ability to make lightweight classes is the only other area where I think C++ could claim a significant advantage.
>
>I think we'll soon reach the point where D is completely limited by libraries and IDE-type issues. Walter will probably get a bit frustrated at that point, because he won't be able to do much about it...
>

"Although I doubt that index is very reliable. :-)"
Basic #5? What the...?

--
Sebastián.

In article <dui6d5$2134$1@digitaldaemon.com>, Johan Granberg says...
>
>Hasan Aljudy wrote:
>>> Because then i would have to call a method to read bar and that would bee inefective.
>> 
>> You know, CPUs are fast now a days, a single function call is not "ineffective".
>
>That argument does not hold if you are in a tight loop it will matter.

Why not just use a method to return a pointer to the private member and use that within your hypothetical tight loop, then use proper get/set methods when CPU time is not important?  It shouldn't use any more CPU time than referencing the member directly (because both the object reference and pointer need to be deferenced before what they referenced can be used through them).  Or what about copying the member to a temporary variable in the scope above the loop's, using the temporary variable within the loop, then setting the member to the value of the temporary var when the loop is finished?  (And even if there is an exception thrown and you still want the member to be set to the same value as the temp var, you could use on_scope_failure to call the set method in that event.)

Tyler Knott wrote:
> In article <dui6d5$2134$1@digitaldaemon.com>, Johan Granberg says...
>> Hasan Aljudy wrote:
>>>> Because then i would have to call a method to read bar and that would bee inefective. 
>>> You know, CPUs are fast now a days, a single function call is not "ineffective".
>> That argument does not hold if you are in a tight loop it will matter.
> 
> Why not just use a method to return a pointer to the private member and use that
> within your hypothetical tight loop, then use proper get/set methods when CPU
> time is not important?  It shouldn't use any more CPU time than referencing the
> member directly (because both the object reference and pointer need to be
> deferenced before what they referenced can be used through them).  Or what about
> copying the member to a temporary variable in the scope above the loop's, using
> the temporary variable within the loop, then setting the member to the value of
> the temporary var when the loop is finished?  (And even if there is an exception
> thrown and you still want the member to be set to the same value as the temp
> var, you could use on_scope_failure to call the set method in that event.)
> 
> 
I'm avare you can do that but I see it as a ugly workaround rather than a solution.