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 would recommend starting off with Delphi, Java or C#.
 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.

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

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

I'd suggest C + C#, or C + Java, then you get two completely different 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
 would recommend starting off with Delphi, Java or C#.

Agreed. I know nothing of Delphi. Of the other two, C# is probably the 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