www.digitalmars.com         C & C++   DMDScript  

D - stream conversion (format) specifiers

reply "Andrew Edwards" <edwardsac spamfreeusa.com> writes:
With operator overloading fully implemented, is there anyway to overload
an -> operator for printf and <- operator for scanf to automatically resolve
conversion (format) specifies based on datatype?

For example:

char[] printSomething = "some arbitrary string";
int scanSomething;
printf("->", printSomething);
scanf("<-", &scanSomething);

This would automatically resolve -> to %.*s and <- to %d. Of course, one
would still be able to explicitly specify conversion specifies when
necessary.

Just a thought!
Andrew
Jun 09 2003
parent reply Georg Wrede <Georg_member pathlink.com> writes:
In article <bc3eia$1mq8$1 digitaldaemon.com>, Andrew Edwards says...

With operator overloading fully implemented, is there anyway to overload
an -> operator for printf and <- operator for scanf to automatically resolve
conversion (format) specifies based on datatype?

For example:

char[] printSomething = "some arbitrary string";
int scanSomething;
printf("->", printSomething);
scanf("<-", &scanSomething);

This would automatically resolve -> to %.*s and <- to %d. Of course, one
would still be able to explicitly specify conversion specifies when
necessary.

Just a thought!
Andrew



First, this isn't operator overloading, at least if used as in the
above example. Second, I think this could be implemented in the
library instead of being part of the language. (I think the intent
here was to get something like C++ << and >>.)

Then the above could be written more conveniently as:

char[] printSomething = "some arbitrary string";
int scanSomething;

aprintf(printSomething);
ascanf(&scanSomething);

The new library functions aprintf and ascanf could then look at
the given parameters and scan or print accordingly. Naturally,
they'd throw the relevant exceptions. And both should take an
arbitrary number of parameters.

I think your idea is really handy!
Jun 10 2003
next sibling parent reply Ilya Minkov <webmaster midiclub.de.vu> writes:
Georg Wrede wrote:

 First, this isn't operator overloading, at least if used as in the
 above example. Second, I think this could be implemented in the
 library instead of being part of the language. (I think the intent
 here was to get something like C++ << and >>.)


One thing comes to my mind: if stream libraries are implemented through 
operator overloading, concatenation operator should  be considered. I'm 
being led to this by Sather where you write:

#OUT + something_to_output;

This means "Create an object of type OUT and execute operator add on it 
with something_to_output". The result would also be OUT, so you can keep 
concatenating further. As you can see, this is one of the cases which 
can be improved by the separate concatenation operator. The input stream 
works the same way.

-i.
Jun 10 2003
parent Georg Wrede <Georg_member pathlink.com> writes:
In article <bc5c29$cn4$1 digitaldaemon.com>, Ilya Minkov says...

Georg Wrede wrote:

 First, this isn't operator overloading, at least if used as in the
 above example. Second, I think this could be implemented in the
 library instead of being part of the language. (I think the intent
 here was to get something like C++ << and >>.)


One thing comes to my mind: if stream libraries are implemented through 
operator overloading, concatenation operator should  be considered. I'm 
being led to this by Sather where you write:

#OUT + something_to_output;

This means "Create an object of type OUT and execute operator add on it 
with something_to_output". The result would also be OUT, so you can keep 
concatenating further. As you can see, this is one of the cases which 
can be improved by the separate concatenation operator. The input stream 
works the same way.


And with several items at a time would it be the following?

OutStream + TheString + BrownString + FoxString;

Similarly one could write

InStream + TheString + BrownString + FoxString;

This looks simple enough. But this relies on the programmer
using descriptive names. Consider:

SerialPortStream + TheString + BrownString + FoxString;

Does this mean input or output? The computer knows, because
this stream is opened as input or output, but how about the
programmer?

Of course << and >> would be handy, people are either used
to using them or at least have seen them already. But then
maybe Walter has had a specific reason for not introducing
them yet?

Also, with the input stream, I at least don't visualize
reading as concatenating. Rather as splitting. So + would
not be appropriate there.
Jun 10 2003
prev sibling parent reply "Andrew Edwards" <edwardsac spamfreeusa.com> writes:
"Georg Wrede" <Georg_member pathlink.com> wrote in message
news:bc4goq$2k4i$1 digitaldaemon.com...


 First, this isn't operator overloading, at least if used as in the
 above example. Second, I think this could be implemented in the
 library instead of being part of the language. (I think the intent
 here was to get something like C++ << and >>.)


That is the general idea; however, I thought this could be accomplished by
modifying or providing a modified version of the printf/scanf functions in
the stream library. Forgive me if I use the incorrect terms for particular
programming concepts. I would, however, appreciate a small explanation of
exactly what this is called so that I can recognize what I'm looking at in
the future.


 Then the above could be written more conveniently as:

 char[] printSomething = "some arbitrary string";
 int scanSomething;

 aprintf(printSomething);
 ascanf(&scanSomething);

 The new library functions aprintf and ascanf could then look at
 the given parameters and scan or print accordingly. Naturally,
 they'd throw the relevant exceptions. And both should take an
 arbitrary number of parameters.


I rather like the printf/scanf way for doing I/O processing, which calls for
a string with optional embedded conversion specifiers and associated
variables as its parameters. I do however believe I/O can be handled
differently. My idea is to have four distinct functions: scan, print, open,
and close. Both scan and print would be bounded to the keyboard and monitor
respectively.  Additionally, two auxiliary functions (read, write) would be
defined and activated based on the current state of open( ).  The   would
resolve to the appropriate conversion specifier both print( ) and write ( ).
I do agree with your thoughts on the scan function, but do not believe it
necessary to explicitly specify the &. Afterall, everytime I've ever used
the scanf( ) function, I've intended for the scanned value(s) to be stored
in the identified variable(s). Exception handling, and parameters
implemented as you've described above.

For example:

// standard input/output
print("What is your name? ");
scan(name); // scan( ) determines desired input based on parameter type.
print("How the hell are you  ? Welcome to D programming.\n", name);

// file input/output
open( infile; outfile );
    read(name); // OK. read( ) determines desired input based on parameter
type.
    write("How the hell are ya  ?", name); // OK
open( infile; );
    write("How the hell are ya  ?", name); // illegal operation, outfile not
defined.
open( ; outfile );
    read(name); // illegal operation, infile not defined.
close( infile; );
    read(name); // illegal operation, infile not defined.
    write("Something to write"); // OK
close( ; outfile );
    read(name); // OK
    write("Something to write"); // illegal operation, outfile not defined.
close( );
    read(name); // illegal operation, infile not defined.
    write("Something to write"); // illegal operation, outfile not defined.



 I think your idea is really handy!
Jun 10 2003
parent reply Georg Wrede <Georg_member pathlink.com> writes:
 "Georg Wrede" <Georg_member pathlink.com> wrote in message
 news:bc4goq$2k4i$1 digitaldaemon.com...
 

 First, this isn't operator overloading, at least if used as in the
 above example. Second, I think this could be implemented in the
 library instead of being part of the language. (I think the intent
 here was to get something like C++ << and >>.)


 
 
 That is the general idea; however, I thought this could be accomplished by
 modifying or providing a modified version of the printf/scanf functions in
 the stream library. Forgive me if I use the incorrect terms for particular
 programming concepts. I would, however, appreciate a small explanation of
 exactly what this is called so that I can recognize what I'm looking at in
 the future.


Operator overloading means you can define an operator (+,= and others
are operators) to have meaning in new contexts. If a,b and c are 
integers then everybody knows what "c=a+b" means. If they are strings
then most of us assume "c=a+b" could mean concatenation. For example
c="Mary"+"Belle" gives "MaryBelle" in c. But what if you have a type
called RomanString? Would + mean concatenation or something else?
If you write "c=a+b" when a is "vi" and b is "mix", should c become
"vimix"? No, it should become "mxv". Likewise "vii"+"xv" should
become "xxii", as the Romans think.  The act of defining + to
work like this is called Operator Overloading.


 differently. My idea is to have four distinct functions: scan, print, open,
 and close. Both scan and print would be bounded to the keyboard and monitor
 respectively.  Additionally, two auxiliary functions (read, write) would be
 defined and activated based on the current state of open( ).  The   would
 resolve to the appropriate conversion specifier both print( ) and write ( ).
 I do agree with your thoughts on the scan function, but do not believe it
 necessary to explicitly specify the &. Afterall, everytime I've ever used
 the scanf( ) function, I've intended for the scanned value(s) to be stored
 in the identified variable(s). Exception handling, and parameters
 implemented as you've described above.
 
 For example:


So essentially you want what Pascal has? 

writeln('Hello, ',name);
write('Give your age: ');
readln(age);
writeln('Age of ',name, ' is ', age);

Where the defaults for read and write are stdin and stdout (the
keyboard and the screen, respectively) until altered with 

AssignFile(Input, sourceName);
Reset(Input);
AssignFile(Output, destName);
Rewrite(Output);

But this has a problem because there are many number formats. 
And you might want to read text fields of certain lengths.
Then just using scanf would be easier. BTW, scanf does read
from stdin (the keyboard), while fscanf reads from a specified
input stream (which can be a file), and sscanf reads from a
string in memory. The same with printf, fprintf and sprintf.
Jun 11 2003
next sibling parent Ilya Minkov <webmaster midiclub.de.vu> writes:
Georg Wrede wrote:

 Operator overloading means you can define an operator (+,= and others
 are operators) to have meaning in new contexts. If a,b and c are 
 integers then everybody knows what "c=a+b" means. If they are strings
 then most of us assume "c=a+b" could mean concatenation. 


That's why we have conceatenation operator: "a ~ b" means concatenattion 
only. This is especially important with arrays and other extensible 
agregates, since "a + b" would rather mean a memberwise addition.

-i.
Jun 11 2003
prev sibling parent reply "Andrew Edwards" <edwardsac spamfreeusa.com> writes:
"Georg Wrede" <Georg_member pathlink.com> wrote in message
news:bc7109$1s64$1 digitaldaemon.com...


 Operator overloading means <snip>


Much appreciated.



 So essentially you want what Pascal has?


I have no idea what Pascal have, however, if they do have what I've
explained earlier, then my answer is yes!


 Where the defaults for read and write are stdin and stdout (the
 keyboard and the screen, respectively) until altered with


Please note that I'm not trying to manipulate I/O by redirecting where
scan( ) gathers its information from or print( ) outputs its information to.
IMO read and write( ) will always point to a file or stream which is
determined by the current state some object open.


 But this has a problem because there are many number formats.


Why? There are already conversion specifiers defined to handle those
numbers. All you would need to do is define   to decern which to use based
on the parameters provided.


 And you might want to read text fields of certain lengths.


char[10] letters;
int number;
char[] word;

// implicit
for ( int i = 0; i < 10; i++ )
{
    scan(letters[i] );  //    == %c
    print("Letter scanned:  \n", letters[i] ); //   == %c
}

scan(number); //   == %d
print("Number scanned:  ", number); //   == %d

scan(word); //    == %.*s
print("Word scanned:  ", word); //   == %.*s

// explicit
scan("%.*s,%d,%c", word, number, letters[5]); // works just as well...

I do not know if this is possible, however, assuming that it is, I do not
see where the problem lies.

Andrew
Jun 12 2003
parent reply Andy Friesen <andy ikagames.com> writes:
Andrew Edwards wrote:

 "Georg Wrede" <Georg_member pathlink.com> wrote in message
 news:bc7109$1s64$1 digitaldaemon.com...
 
 

Operator overloading means <snip>


 
 
 Much appreciated.
 
 
 

So essentially you want what Pascal has?


 
 
 I have no idea what Pascal have, however, if they do have what I've
 explained earlier, then my answer is yes!
 
 

Where the defaults for read and write are stdin and stdout (the
keyboard and the screen, respectively) until altered with


 
 
 Please note that I'm not trying to manipulate I/O by redirecting where
 scan( ) gathers its information from or print( ) outputs its information to.
 IMO read and write( ) will always point to a file or stream which is
 determined by the current state some object open.
 
 

But this has a problem because there are many number formats.


 
 
 Why? There are already conversion specifiers defined to handle those
 numbers. All you would need to do is define   to decern which to use based
 on the parameters provided.
 
 

And you might want to read text fields of certain lengths.


 
 
 char[10] letters;
 int number;
 char[] word;
 
 // implicit
 for ( int i = 0; i < 10; i++ )
 {
     scan(letters[i] );  //    == %c
     print("Letter scanned:  \n", letters[i] ); //   == %c
 }
 
 scan(number); //   == %d
 print("Number scanned:  ", number); //   == %d
 
 scan(word); //    == %.*s
 print("Word scanned:  ", word); //   == %.*s
 
 // explicit
 scan("%.*s,%d,%c", word, number, letters[5]); // works just as well...
 
 I do not know if this is possible, however, assuming that it is, I do not
 see where the problem lies.


With the way varargs work right now, it's not.  No type information is 
kept at all, in fact, which is why printf has all those wacky symbols; 
there's no other way to guess the type.

Awhile ago, I took a cue from boost::format, and wrote a Formatter class 
in D.  It has its issues too, but it almost does what you want:

print(new Formatter("Word scanned: {0}") % word % Formatter.end);

(the Formatter.end bit is just a hack to convert the Formatter object to 
a string, since D doesn't provide any way to perform an implicit conversion)

Doing this sort of thing with operator overloading is the only way I can 
see to get the desired effect, though it suffers the problem of 
assigning an arbitrary meaning to the % operator. (I guess it depends on 
whether or not you like using >> and << for C++ streams)
Jun 12 2003
parent reply "Andrew Edwards" <edwardsac spamfreeusa.com> writes:
 With the way varargs work right now, it's not.  No type information is
 kept at all, in fact, which is why printf has all those wacky symbols;
 there's no other way to guess the type.


My question to this is: If there's no way determine the type of a particular
variable, how does the compiler know when you incorrectly assign a int to a
bit or how to silently promote an int to a double? It would seem to me the
only way to determine this is to know exactly what an int, bit, double, or
any particular data type look like.


 Doing this sort of thing with operator overloading is the only way I can
 see to get the desired effect, though it suffers the problem of
 assigning an arbitrary meaning to the % operator. (I guess it depends on
 whether or not you like using >> and << for C++ streams)


I don't too much care for C++.  I'm learning it right know simply because
there are no books or tutorials available for D.  I attempted to start one,
but I'm not knowledgeable enough in the programming department to accomplish
this on my own.  Additionally, there are not allot of people here with the
time to dedicate to such a trivial project in such an early stage of D's
development.  I even thought of plagiarizing the cpptutorial at
cplusplus.com but I'm not interested in being sued by anyone so I stopped.
I'm now learning C++ so that I can have a foundation on which to build a
solid understanding of programming in D.
Jun 12 2003
parent reply Georg Wrede <Georg_member pathlink.com> writes:
I don't too much care for C++.  I'm learning it right know simply because
there are no books or tutorials available for D.


Trying to learn C++ while waiting for a D book is a total waste of time.
If you would like to quickly learn the necessary programming concepts
and then later want to have an easy switch to D, I'd suggest you learn
Pascal.

And with this I don't mean Delphi, because it lures you into looking
at a lot of widgets and windowing stuff, instead of learning to program.
What I suggest is you download Free Pascal and go to the nearest 
library and find a first year textbook on programming in pascal.
There are piles of excellent books about learning to program --
if you want to do the learning with Pascal. After all, Pascal was
originally developed for this!

What you'll get from it all is you will learn to program. And that 
is not the same as "knowing C or D or Perl" or Pascal either.

Who am I to tell you what to learn? Well, I've spent 5 years 
teaching programming at a university. And I've taught others all
my life.

Now, there's even a serious perk hidden here: while D code looks
quite like C++, and quite unlike Pascal, in reality D and 
Pascal are very much alike -- much more alike than D and C++.
Especially in the issues that are covered in the first year.

(I know it's less cool to study Pascal than C++, but hey, 
which is more important, being cool or learning?)
Jun 13 2003
parent reply Ilya Minkov <webmaster midiclub.de.vu> writes:
Georg Wrede wrote:

I don't too much care for C++.  I'm learning it right know simply because
there are no books or tutorials available for D.




That means you have to learn C, but not that you have to learn C++. I 



 Trying to learn C++ while waiting for a D book is a total waste of time.
 If you would like to quickly learn the necessary programming concepts
 and then later want to have an easy switch to D, I'd suggest you learn
 Pascal.


I'm not sure i could second this. Well, the first serious programming 
language i learned was Delphi. I'm really thankful that i did. It allows 
one to get insight into clean, correct OO programming concepts without 
taking too much care about silly syntax-caused bugs: these can be a very 
annoying nuisance when learning C and its descendants, while with Pascal 
they get filtered out. I'm strictly opposed to the idea of learning C++ 
as the first object-oriented language, and i believe that Pascal is much 
better suited than e.g. Java.


 And with this I don't mean Delphi, because it lures you into looking
 at a lot of widgets and windowing stuff, instead of learning to program.
 What I suggest is you download Free Pascal and go to the nearest 
 library and find a first year textbook on programming in pascal.
 There are piles of excellent books about learning to program --
 if you want to do the learning with Pascal. After all, Pascal was
 originally developed for this!


Well, stop dreaming, Georg! these describe the old Turbo Pascal or 
something which is far away from Delphi and object-oriented programming. 
I really don't know any book which can be recommended, besides one 
russian Delphi book i learned by, which gives some (more than the 
others, but IMO too little) attention to important aspects. Can you make 
any more specific recommendation? Maybe there is some good book (lecture 
notes etc.) on the internet? I'm sorry, i have too little time to search 
the net, but if anyone drops a couple of links, i'm sure me and other 
people would be happy to review them.

As an alternative compiler, i would recommend GNU Pascal. It's not much 
difference, but it seems to be more contemporary and is not limited to 
x86 platforms. They both support Object Pascal pogramming model with 
some deviations. I remember trying to compile valid Delphi code with 
FreePascal, and it did, but the application would get a segfault. I 
believe the difference is, in Delphi i used implicit default values for 
the fields, while in FreePascal there is no such thing and all you get 
is garbage.


 What you'll get from it all is you will learn to program. And that 
 is not the same as "knowing C or D or Perl" or Pascal either.


Very true.


 Who am I to tell you what to learn? Well, I've spent 5 years 
 teaching programming at a university. And I've taught others all
 my life.


This is interesting. Do you have your lecture notes published? :)


 Now, there's even a serious perk hidden here: while D code looks
 quite like C++, and quite unlike Pascal, in reality D and 
 Pascal are very much alike -- much more alike than D and C++.
 Especially in the issues that are covered in the first year.


True. Dunno about the first year though, since we learn OCaml and 
functional programming in our first year. :)


 (I know it's less cool to study Pascal than C++, but hey, 
 which is more important, being cool or learning?)


There is only one reason for which i started learning C. Since there are 
so many people who know it, i expected to get some help with programming 
things which other people might also want. I didn't get much help. And i 
got bitten by the stupid bugs so often, that i decied C was unusable. 
That made me learn C++, which would help me to structure my code a bit 
better. I was very lucky to stumble over a very good book right from the 
start - Thinking in C++ from Bruce Eckel. It concentrates a lot on 
developing safe programming practices in C++, the importance of which 
cannot be overestimated. It also gives some insight into efficiency, but 
the best source for that would be "Efficient Algorithms and Data 
Structures" or something alike available from any university bookstore.

Another notable learning language i would like to mention is Sather. I 
would also like to know your opinion on it. The official tutorial is 
short, but explains all of the language and the OO concepts in about 100 
pages. Some programming skills are prerequisite, C/ Pascal/ Basic should 
suffice to be able to learn it by this tutorial.

-i.
Jun 13 2003
next sibling parent reply Georg Wrede <Georg_member pathlink.com> writes:
Ilya Minkov wrote:

 Georg Wrede wrote:



 And with this I don't mean Delphi, because it lures you into looking
 at a lot of widgets and windowing stuff, instead of learning to program.
 What I suggest is you download Free Pascal and go to the nearest 
 library and find a first year textbook on programming in pascal.
 There are piles of excellent books about learning to program --
 if you want to do the learning with Pascal. After all, Pascal was
 originally developed for this!


 
 Well, stop dreaming, Georg! these describe the old Turbo Pascal or 
 something which is far away from Delphi and object-oriented programming. 


You must be referring to seriously old Turbo Pascal. I have here
a number of different versions of them, and here's a quote from
the Turbo Pascal 5.5 manual, published 1989 (my translation from
Finnish to English):

"  The object oriented part of Turbo Pascal 5.5 is based on
"  ideas generated from "Object Pascal Report" by Larry Tesler
"  (Apple, 1985) and "The C++ Programming Language" by Bjarne
"  Stroustrup (Addison Wesley, 1986).

A quick run-through shows that this version had about everything
C++ had about OO, except multiple inheritance. (At the time I
remember thinking that this was left out because it was too hard
to implement, but now I'm starting to think that they knew it
was an unimportant feature for real-world programming.)

The debugger had object inspectors and it showed the hierarchy.

Between 1989 and about 1995 there were a number of good textbooks on
learning to program. Most used Turbo Pascal because it was a clean, well
thought out language which included OO, and it was readily available.
When Sun stormed the world with Java it suddenly became uncool to use
"ancient languages". The last year I touhgt Intro to Programming, I had
to spend half the first few lectures justifying to students why we used
Pascal instead of Java.

I am not going to give names of books here because if those 
particular books aren't available at the local university library,
then anyone interested is going to skip Pascal "because there
were no good books". Also, I haven't read _all_ good books about
the subject either.

How do I define a Good Book? Well, what you get from the book has
to have value for many years to come. A textbook on programming
has to be written so that you can clearly see what is programming
and what is just implementing it in the language at hand.

I still think one should use something like Free Pascal (or maybe
Gnu Pascal), instead of Delphi. There is nothing in the Delphi
version of Pascal that's missing in FP or GP -- at least nothing
that is relevant to our current discussion.

The difference between them seems to be that Free Pascal is
more in the spirit Borland kept with Pascal. Also, as a product
it feels somewhat easier and more polished to handle. (Your
mileage may vary on this.)

www.freepascal.org says FP is available on DOS, Win32, OS/2,
SunOS, Classic Amiga, Linux, FreeBSD, QNX, BeOS, and soon
PowerPC.

Further, "The language syntax is semantically compatible with TP
7.0 as well as most versions of Delphi (classes, rtti, exceptions,
ansistrings). Furthermore Free Pascal supports function 
overloading, operator overloading and other such features."


The experience of having written your entire program
yourself vs. just filling in lines and snippets in a machine-
written framework seems to have made a big difference, at least
with my students.

Particularly, one year we had half the students use BP7 as a 
command line compiler, and the other half used the windowed
interface. Interestingly, the command-line crowd fared much
better, both initially and after a few years.


 What you'll get from it all is you will learn to program. And that is 
 not the same as "knowing C or D or Perl" or Pascal either.


 
 Very true.


..

 There is only one reason for which i started learning C. Since there are 
 so many people who know it, i expected to get some help with programming 
 things which other people might also want. I didn't get much help. And i 
 got bitten by the stupid bugs so often, that i decied C was unusable. 


Exactly!
I've had the same experience.
Jun 16 2003
parent reply Ilya Minkov <Ilya_member pathlink.com> writes:
In article <bcl4ia$2d06$1 digitaldaemon.com>, Georg Wrede says...

 Georg Wrede wrote:





You must be referring to seriously old Turbo Pascal. I have here
a number of different versions of them, and here's a quote from
the Turbo Pascal 5.5 manual, published 1989 (my translation from
Finnish to English):


Knowing Finnish is by itself an Art. :>


"  The object oriented part of Turbo Pascal 5.5 is based on
"  ideas generated from "Object Pascal Report" by Larry Tesler
"  (Apple, 1985) and "The C++ Programming Language" by Bjarne
"  Stroustrup (Addison Wesley, 1986).

A quick run-through shows that this version had about everything
C++ had about OO...


Obviously, yes. But the object model in Turbo Pascal 7 is not the same as in
Delphi. And that of Delphi is much cleaner.

The one in  Turbo Pascal was blatantly copied from C++, namely that an "object"
is simply a kind of a struct. What it leads to, is a need to explicitly declare
*pointer* to this struct, then explicitly dereference it. But it works even
worse than in C++. The result is simply ugly. And this would lead to
unappropriate design klugdes or the urge to avoid the stuff altogether. For
example, this snippet, taken from the FreePascal reference:

--- 8< ---

Type
TParent = Object
..
procedure Doit;virtual;
..
end;
PParent = ^TParent;
TChild = Object(TParent)
..
procedure Doit;virtual;
..
end;
PChild = ^TChild;

Var ParentA,ParentB : PParent;
Child           : PChild;
ParentA := New(PParent,Init);
ParentB := New(PChild,Init);
Child := New(PChild,Init);
ParentA^.Doit;
ParentB^.Doit;
Child^.Doit;

--- >8 ---

The Delphi model brings following enhancements in:
- new keyword Class: pointer and dereferincing is implicit; it requieres some
explaination and trial for the students to understand this, but the ease-of-use
is much greater and leaves less space for bugs.
- operator new is implicit, but construction and destruction are still explicit;
- Getters, setters - properties which are described by methods and not
necessarily connected to classes' storage. Usually very useful to specify
processing when a fierld is assigned, or to implement lazy evaluation. Results
in definately cleaner client code;
- array properties with getters and setters.

Some of these changes - but i believe too few of them - were blatantly stolen by
Java and probably made it a market's dominant language.


I still think one should use something like Free Pascal (or maybe
Gnu Pascal), instead of Delphi. There is nothing in the Delphi
version of Pascal that's missing in FP or GP -- at least nothing
that is relevant to our current discussion.


Almost definately true. Gnu Pascal supports a superset of features of
FreePascal, which is a superset of fetures of Delphi. The Delphi classes
compile, but subtle differencies might prevent them from working properly. Gnu
Pascal is a bit more focused towards language feauteres from other Pascal
dialects, like the standardized dynamic array type as opposed to the Delphi one.


www.freepascal.org says FP is available on DOS, Win32, OS/2,
SunOS, Classic Amiga, Linux, FreeBSD, QNX, BeOS, and soon
PowerPC.


This "soon PowerPC" has been around for more than 2 years! The versions beside
some mainstream x86 ones have not been updated for long either.  The development
is stagnated, while Gnu Pascal is being developed actively, i guess at some
university in Germany. I believe FreePascal is based on the somewhat refractored
GCC source, which makes it possible but hard to port to different platforms. Gnu
Pascal compiles with unmodified GCC 3.x.x source on any platform, and benefits
from the recent optimiser improvements.


Further, "The language syntax is semantically compatible with TP
7.0 as well as most versions of Delphi (classes, rtti, exceptions,
ansistrings). Furthermore Free Pascal supports function 
overloading, operator overloading and other such features."


Gnu Pascal has all these features. RTTI and strings are probably not 100%
compatible though.


The experience of having written your entire program
yourself vs. just filling in lines and snippets in a machine-
written framework seems to have made a big difference, at least
with my students.


This is right. The book i mention contained a project template which was a .dpr
with a compiler pragma converting the generated program to console. You could
then code in exactly the same manner as in previous Pascal versions, and the IDE
would degrade to a convenient Editor with Debugger.


Particularly, one year we had half the students use BP7 as a 
command line compiler, and the other half used the windowed
interface. Interestingly, the command-line crowd fared much
better, both initially and after a few years.


The dependancy can be very subtle. Like, they might simply have previous
experience and thus both prefer commandline and study easier? Or maybe they are
simply less lazy?

-i.
Jun 17 2003
next sibling parent reply New comer <New_member pathlink.com> writes:
Hello, I am intertsting in learning to program . I happen to fall on to this
site and  I am convinced 
about the "D" language. and was following  this thread. So for somebody that has
no expirience in 
programing ,what is the bottom line, what would be  the most efficent way to
learn "d",
what would be the best way ? Meaning to start with which language and or books ?
for the basics.
Jun 17 2003
parent reply Bill Cox <bill viasic.com> writes:
New comer wrote:

 Hello, I am intertsting in learning to program . I happen to fall on to this
 site and  I am convinced 
 about the "D" language. and was following  this thread. So for somebody that
has
 no expirience in 
 programing ,what is the bottom line, what would be  the most efficent way to
 learn "d",
 what would be the best way ? Meaning to start with which language and or books
?
 for the basics.
 


There's a lot of different ways to go.  I recently advised my brother to 
learn Java first, and that seems to have worked out well.  Some people 
on this group have advocated learning Pascal first, which seems 
reasonable to me.

Bill
Jun 17 2003
parent reply New comer <New_member pathlink.com> writes:
In article <3EEF66BB.9060801 viasic.com>, Bill Cox says...

New comer wrote:

 Hello, I am intertsting in learning to program . I happen to fall on to this
 site and  I am convinced 
 about the "D" language. and was following  this thread. So for somebody that
has
 no expirience in 
 programing ,what is the bottom line, what would be  the most efficent way to
 learn "d",
 what would be the best way ? Meaning to start with which language and or books
?
 for the basics.
 


There's a lot of different ways to go.  I recently advised my brother to 
learn Java first, and that seems to have worked out well.  Some people 
on this group have advocated learning Pascal first, which seems 
reasonable to me.


Which is the closest in structure , syntext and logic ? What I understand , to
start with C/C++ is 
out of the question. Correct ?

Bill
Jun 17 2003
next sibling parent Georg Wrede <Georg_member pathlink.com> writes:
Which is the closest in structure , syntext and logic ? 
What I understand , to start with C/C++ is out of the 
question. Correct ?


If I had programs written in different languages and 
had to rewrite them in D, then, I think, the easiest 
to translate would be those in Pascal.

Add that to what has been discussed here, and the answer
would be Pascal.

((NOW, PLEASE, everybody else: let's not start another
lengthy and meandering discussion about this. Such long
ruminations, while fun for us, don't serve those for
whom these issues are important right now!))
Jun 18 2003
prev sibling next sibling parent Ilya MInkov <Ilya_member pathlink.com> writes:
In article <bcoqoc$2nol$1 digitaldaemon.com>, New comer says...

Which is the closest in structure , syntext and logic ? What I understand , to
start with C/C++ is 
out of the question. Correct ?


Throwing C and C++ into the same pot would be wrong here. And though i have said
that C is unusable, i didnt mean it being unlearnable. :)

It is suggested that you learn ObjectPascal or Java, which would give you the
programming skills, and understanding of Object-Oriented concepts. "Thinking in
Java" by Bruce Eckel comes to mind, and is freely available on his site.
Although i haven't read this book, i read some others of him and i consider him
the best programming book writer i ever came across. He would not only teach you
the language, but so much more.

What i meant, you shouldn't try to start doing any large project in C - since
what appears to be simple and straightforward in almost any language, would give
you tons of possibilities to make bugs in C. But i believe learning C wasn't
useless since it gave me a good understanding of Pointers which i didn't have
after learning Pascal. So, you may start with C if you like, then pass on to
object-oriented languages.

I wouldn't recommend learning C++ -- it would give you nothing if you want to
program in D. It may burn your brain since it's conceptually too impure. Java
and ObjectPascal are really much closer to D. Syntactically, Java, C and D
belong to the same family (american, AT&T), and Pascal is diferent (Wirth
school) - but Pascal syntax has never damaged anyone's brain yet, as opposed to
that of C. :>

So the path i would recommend could be Java/OPascal -> C -> D.

-i.
Jun 20 2003
prev sibling parent "Matthew Wilson" <matthew stlsoft.org> writes:
 Which is the closest in structure , syntext and logic ? What I understand


, to

 start with C/C++ is
 out of the question. Correct ?



slants. Since D will, in part, be a multi-paradigm language it seems to me
that if one wants to be a proficient D user, then it is wise not to get
mentally bogged down into one paradigmic rut, which any of those languages
alone will certainly do to you.

Actually, here's a thought. Why not learn Python. It supports procedural and
object-oriented programming, is much simpler to learn than any of the
others, and one can get a first Python program doing interesting things in
just a few hours.
Jul 09 2003
prev sibling parent reply Georg Wrede <Georg_member pathlink.com> writes:
Ilya Minkov wrote:

Georg Wrede wrote:






So, to sum it up, we seem to mostly agree!

Also, anyone reading this has probably by now a pretty good
understanding on what they should do about learning to program
while waiting for the ultimate text book in D.  ;-)
Jun 18 2003
parent "Andrew Edwards" <edwardsac spamfreeusa.com> writes:
"Georg Wrede" <Georg_member pathlink.com> wrote in message


 Also, anyone reading this has probably by now a pretty good
 understanding on what they should do about learning to program
 while waiting for the ultimate text book in D.  ;-)


I do...but it is certainly interesting to watch the conversation unfold.  On
the subject of "the ultimate text book in D," I'm under the impression that
Bruce Eckel does great work...especially with his "Thinking in" series.  I
urge anyone interested in seeing this book come to reality in the near
future to drop him a line showing interest in the product. Last I understood
was that he entertains the thought of taking on the project, but that the
user base wasn't large enough or at least doesn't seem to be.

Andrew
Jun 18 2003
prev sibling parent "Matthew Wilson" <matthew stlsoft.org> writes:
 I'm strictly opposed to the idea of learning C++
 as the first object-oriented language, and i believe that Pascal is much
 better suited than e.g. Java.


C++ is not an object-oriented language. It staggers me to hear people
characterise it as such. It is, in fact, a language that supports
object-orientation as one of several paradigms supported.


 That means you have to learn C, but not that you have to learn C++. I




better one, because it allows pointers and platform-dependent code to
pollute its language/libraries, and since D will always do the same, it
might be the more realistic introduction.
Jul 09 2003