www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Newbie: Standard Input? Readline? Convert to double?

reply matthew_hurne yahoo.com writes:
Lol, now I'm struggling through figuring out standard INPUT.  I have messed with
scanf, stdin.readLine(), readLine()...all to no avail.

If any suggestion I have...better basic documentation!  This website is great,
very detailed about the language, but it seems a bit short on talking about
things so practical and essential as standard ways of input and output.
Nov 19 2004
parent reply Sean Kelly <sean f4.ca> writes:
In article <cnm116$1bns$1 digitaldaemon.com>, matthew_hurne yahoo.com says...
Lol, now I'm struggling through figuring out standard INPUT.  I have messed with
scanf, stdin.readLine(), readLine()...all to no avail.
I've written an input package that is functionally similar to format/writef. The functions are called readf, and are functionally similar to writef in Phobos. You can download it here: http://home.f4.ca/sean/d/stdio.zip The final release is waiting on some compiler fixes, but the current version is feature-complete and, as far as I know, bug free. Sean
Nov 19 2004
parent reply matthew_hurne yahoo.com writes:
In article <cnm2ek$1dpn$1 digitaldaemon.com>, Sean Kelly says...
In article <cnm116$1bns$1 digitaldaemon.com>, matthew_hurne yahoo.com says...
Lol, now I'm struggling through figuring out standard INPUT.  I have messed with
scanf, stdin.readLine(), readLine()...all to no avail.
I've written an input package that is functionally similar to format/writef. The functions are called readf, and are functionally similar to writef in Phobos. You can download it here: http://home.f4.ca/sean/d/stdio.zip The final release is waiting on some compiler fixes, but the current version is feature-complete and, as far as I know, bug free. Sean
Sean, I'm getting the following error: stdio.d(101): undefined identifier WEOF If I change WEOF in that line to EOF, I get the following: /usr/bin/ld: Warning: size of symbol `_D3std6stdarg9va_arg_Aa6va_argFKPvZAa' changed from 23 in stdio.o to 34 in /usr/lib/gcc/i386-redhat-linux/3.4.2/../../../libphobos.a(format.o) /usr/bin/ld: Warning: size of symbol `_D3std6stdarg9va_arg_Au6va_argFKPvZAu' changed from 23 in stdio.o to 19 in /usr/lib/gcc/i386-redhat-linux/3.4.2/../../../libphobos.a(format.o) /usr/bin/ld: Warning: size of symbol `_D3std6stdarg9va_arg_Aw6va_argFKPvZAw' changed from 38 in stdio.o to 19 in /usr/lib/gcc/i386-redhat-linux/3.4.2/../../../libphobos.a(format.o)
Nov 20 2004
parent reply Thomas Kuehne <thomas-dloop kuehne.thisisspam.cn> writes:
matthew_hurne yahoo.com schrieb am Sat, 20 Nov 2004 20:02:57 +0000 (UTC):
Lol, now I'm struggling through figuring out standard INPUT.  I have messed with
scanf, stdin.readLine(), readLine()...all to no avail.
I've written an input package that is functionally similar to format/writef. The functions are called readf, and are functionally similar to writef in Phobos. You can download it here: http://home.f4.ca/sean/d/stdio.zip The final release is waiting on some compiler fixes, but the current version is feature-complete and, as far as I know, bug free. Sean
Sean, I'm getting the following error: stdio.d(101): undefined identifier WEOF If I change WEOF in that line to EOF, I get the following: /usr/bin/ld: Warning: size of symbol `_D3std6stdarg9va_arg_Aa6va_argFKPvZAa' changed from 23 in stdio.o to 34 in /usr/lib/gcc/i386-redhat-linux/3.4.2/../../../libphobos.a(format.o) /usr/bin/ld: Warning: size of symbol `_D3std6stdarg9va_arg_Au6va_argFKPvZAu' changed from 23 in stdio.o to 19 in /usr/lib/gcc/i386-redhat-linux/3.4.2/../../../libphobos.a(format.o) /usr/bin/ld: Warning: size of symbol `_D3std6stdarg9va_arg_Aw6va_argFKPvZAw' changed from 38 in stdio.o to 19 in /usr/lib/gcc/i386-redhat-linux/3.4.2/../../../libphobos.a(format.o)
That's a Phobos bug. Below is a patch for gdc-0.8. For dmd-0.106 you only need to apply the second part. After rebuilding and installing Phobos the problem should be gone. I don't know about Mac/BSD. You might have to look up "WEOF" in "wchar.h" and adapt the patch. Thomas --- d/phobos/std/c/stdio.d 2004-11-20 22:10:36.026884216 +0100 +++ d/phobos/std/c/stdio.d 2004-11-20 22:16:20.107576000 +0100 -40,6 +40,7 alias gcc.config.FILENAME_MAX FILENAME_MAX; alias gcc.config.TMP_MAX TMP_MAX; alias gcc.config.L_tmpnam L_tmpnam; + const uint WEOF = uint.max; } else version (linux) { -48,6 +49,7 const int FILENAME_MAX = 4095; const int TMP_MAX = 238328; const int L_tmpnam = 20; + const uint WEOF = uint.max; } enum { SEEK_SET, SEEK_CUR, SEEK_END }
Nov 20 2004
next sibling parent reply matthew_hurne yahoo.com writes:
In article <s8p472-vj2.ln1 kuehne.cn>, Thomas Kuehne says...
matthew_hurne yahoo.com schrieb am Sat, 20 Nov 2004 20:02:57 +0000 (UTC):
Lol, now I'm struggling through figuring out standard INPUT.  I have messed with
scanf, stdin.readLine(), readLine()...all to no avail.
I've written an input package that is functionally similar to format/writef. The functions are called readf, and are functionally similar to writef in Phobos. You can download it here: http://home.f4.ca/sean/d/stdio.zip The final release is waiting on some compiler fixes, but the current version is feature-complete and, as far as I know, bug free. Sean
Sean, I'm getting the following error: stdio.d(101): undefined identifier WEOF If I change WEOF in that line to EOF, I get the following: /usr/bin/ld: Warning: size of symbol `_D3std6stdarg9va_arg_Aa6va_argFKPvZAa' changed from 23 in stdio.o to 34 in /usr/lib/gcc/i386-redhat-linux/3.4.2/../../../libphobos.a(format.o) /usr/bin/ld: Warning: size of symbol `_D3std6stdarg9va_arg_Au6va_argFKPvZAu' changed from 23 in stdio.o to 19 in /usr/lib/gcc/i386-redhat-linux/3.4.2/../../../libphobos.a(format.o) /usr/bin/ld: Warning: size of symbol `_D3std6stdarg9va_arg_Aw6va_argFKPvZAw' changed from 38 in stdio.o to 19 in /usr/lib/gcc/i386-redhat-linux/3.4.2/../../../libphobos.a(format.o)
That's a Phobos bug. Below is a patch for gdc-0.8. For dmd-0.106 you only need to apply the second part. After rebuilding and installing Phobos the problem should be gone. I don't know about Mac/BSD. You might have to look up "WEOF" in "wchar.h" and adapt the patch. Thomas --- d/phobos/std/c/stdio.d 2004-11-20 22:10:36.026884216 +0100 +++ d/phobos/std/c/stdio.d 2004-11-20 22:16:20.107576000 +0100 -40,6 +40,7 alias gcc.config.FILENAME_MAX FILENAME_MAX; alias gcc.config.TMP_MAX TMP_MAX; alias gcc.config.L_tmpnam L_tmpnam; + const uint WEOF = uint.max; } else version (linux) { -48,6 +49,7 const int FILENAME_MAX = 4095; const int TMP_MAX = 238328; const int L_tmpnam = 20; + const uint WEOF = uint.max; } enum { SEEK_SET, SEEK_CUR, SEEK_END }
Cool but it doesn't compile: make[1]: Entering directory `/home/matthurne/dmd/src/phobos/etc/c/recls' g++ -Wall -O4 -mcpu=i686 -DNDEBUG -DUNIX -D_M_IX86 -c -I. -I../stlsoft -orecls_fileinfo_unix.o recls_fileinfo_unix.cpp ./stlsoft/stlsoft_null.h: In function `const recls::recls_fileinfo_t* recls::FileInfo_Allocate(size_t)': ./stlsoft/stlsoft_null.h:194: error: `stlsoft::NULL_v::NULL_v(const stlsoft::NULL_v&)' is private recls_fileinfo_unix.cpp:237: error: within this context ./stlsoft/stlsoft_null.h: In function `void recls::FileInfo_Release(const recls::recls_fileinfo_t*)': ./stlsoft/stlsoft_null.h:194: error: `stlsoft::NULL_v::NULL_v(const stlsoft::NULL_v&)' is private recls_fileinfo_unix.cpp:256: error: within this context ./stlsoft/stlsoft_null.h: In function `recls::recls_rc_t recls::FileInfo_Copy(const recls::recls_fileinfo_t*, const recls::recls_fileinfo_t**)': ./stlsoft/stlsoft_null.h:194: error: `stlsoft::NULL_v::NULL_v(const stlsoft::NULL_v&)' is private recls_fileinfo_unix.cpp:277: error: within this context make[1]: *** [recls_fileinfo_unix.o] Error 1 make[1]: Leaving directory `/home/matthurne/dmd/src/phobos/etc/c/recls' make: *** [etc/c/recls/recls_fileinfo_unix.o] Error 2
Nov 20 2004
parent reply Thomas Kuehne <thomas-dloop kuehne.thisisspam.cn> writes:
matthew_hurne yahoo.com schrieb am Sat, 20 Nov 2004 22:45:17 +0000 (UTC):
 Cool but it doesn't compile:

 make[1]: Entering directory `/home/matthurne/dmd/src/phobos/etc/c/recls'
 g++ -Wall  -O4 -mcpu=i686  -DNDEBUG -DUNIX -D_M_IX86 -c -I. -I../stlsoft
 -orecls_fileinfo_unix.o recls_fileinfo_unix.cpp
 ./stlsoft/stlsoft_null.h: In function `const recls::recls_fileinfo_t*
[snip] 1) get the install script from http://dmd.kuehne.cn 2) create a temp dir 3) put the script and the dmd.zip into that dir 4) run the script with the option ./dmd.zip note: no need to symlink / change the PATH (suggested by the readme) 6) change to dmd/src/phobos/std/c 7) apply the changes 8) change to dmd/src/phobos 9) run make -f linux.mak 10) replace your phobos.a with the newly generated one (!keep a back) 11) try if it's working ;) Thomas
Nov 20 2004
parent reply Thomas Kuehne <thomas-dloop kuehne.thisisspam.cn> writes:
Thomas Kuehne schrieb am Sun, 21 Nov 2004 00:09:43 +0100:
 1) get the install script from http://dmd.kuehne.cn
arr - I just realised that the link is botched .... http://dmd.kuehne.cn/archive.html download the 0.97 version and search for "stlsoft" Change your dmd source and do a normal phobos rebuilding/installation - and forget about the not existing script :P Thomas
Nov 20 2004
parent reply matthew_hurne yahoo.com writes:
In article <r50572-b64.ln1 kuehne.cn>, Thomas Kuehne says...
Thomas Kuehne schrieb am Sun, 21 Nov 2004 00:09:43 +0100:
 1) get the install script from http://dmd.kuehne.cn
arr - I just realised that the link is botched .... http://dmd.kuehne.cn/archive.html download the 0.97 version and search for "stlsoft" Change your dmd source and do a normal phobos rebuilding/installation - and forget about the not existing script :P Thomas
I edited dmd/src/phobos/etc/c/stlsoft/stlsoft_null.h with the following (this is what it appeared the patching would do...) Removed line 242: NULL_v(NULL_v const &); And moved it under public: I rebuilt with make -f linux.mak and copied the libphobos.a to /usr/lib, overwriting the original, ran /sbin/ldconfig, and then tried my compile again. And I got the same errors. *sigh* All this just to try to do basic input from the console? This is kinda silly...
Nov 20 2004
parent reply Thomas Kuehne <thomas-dloop kuehne.thisisspam.cn> writes:
matthew_hurne yahoo.com schrieb am Sun, 21 Nov 2004 00:23:45 +0000 (UTC):
 I edited dmd/src/phobos/etc/c/stlsoft/stlsoft_null.h with the following (this
is
 what it appeared the patching would do...)

 Removed line 242:
 NULL_v(NULL_v const &);

 And moved it under public:

 I rebuilt with make -f linux.mak and copied the libphobos.a to /usr/lib,
 overwriting the original, ran /sbin/ldconfig, and then tried my compile again.
 And I got the same errors.

 *sigh*  All this just to try to do basic input from the console?  This is kinda
 silly...
This is indeed a wierd bug. If the content of std.stdarg is copied into the downloaded stdio package and all imports for std.stdarg removed the test programm compiles - but doesn't read any input. Seems to be a compiler bug. gdc's output: stdio.d:48: cast(void*)(_argptr) is not an lvalue stdio.d:50: cast(void*)(_argptr) is not an lvalue stdio.d:52: cast(void*)(_argptr) is not an lvalue unformat.d: In function `unFormat': unformat.d:484: interner Compiler-Fehler: Segmentation fault Thomas
Nov 20 2004
parent Sean Kelly <sean f4.ca> writes:
In article <a56572-ho5.ln1 kuehne.cn>, Thomas Kuehne says...
matthew_hurne yahoo.com schrieb am Sun, 21 Nov 2004 00:23:45 +0000 (UTC):
 I edited dmd/src/phobos/etc/c/stlsoft/stlsoft_null.h with the following (this
is
 what it appeared the patching would do...)

 Removed line 242:
 NULL_v(NULL_v const &);

 And moved it under public:

 I rebuilt with make -f linux.mak and copied the libphobos.a to /usr/lib,
 overwriting the original, ran /sbin/ldconfig, and then tried my compile again.
 And I got the same errors.

 *sigh*  All this just to try to do basic input from the console?  This is kinda
 silly...
This is indeed a wierd bug. If the content of std.stdarg is copied into the downloaded stdio package and all imports for std.stdarg removed the test programm compiles - but doesn't read any input. Seems to be a compiler bug.
Might be worth grabbing my implementation of the standard C headers here: http://home.f4.ca/sean/d/stdc.zip They have everything written in terms of wint_t, etc, and so should be easier to adapt to unix systems. You can compile and link in all headers but stdio.d. For some reason including this compiled file breaks output--I haven't figured out why. I thought it might be something to do with the standard output haldes, but there's no warning about multiply defined symbols so I'm kind of stumped. Sean
Nov 21 2004
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Thomas Kuehne wrote:

 That's a Phobos bug. Below is a patch for gdc-0.8. 
 For dmd-0.106 you only need to apply the second part.
 After rebuilding and installing Phobos the problem should be gone.
 
 I don't know about Mac/BSD. You might have to look up "WEOF"
 in "wchar.h" and adapt the patch.
On Mac OS X, wint_t is a *signed* entity. (i.e. "int") But, unless I am mistaken, it should be the same as 0xFFFFFFFF ? /usr/include/wchar.h:
 #ifndef	_BSD_WINT_T_DEFINED_
 #define _BSD_WINT_T_DEFINED_
 typedef	_BSD_WINT_T_	wint_t;
 #endif

 #ifndef WEOF
 #define	WEOF 	((wint_t)-1)
 #endif
and
 wint_t	fgetwc(struct __sFILE *);
/usr/include/ppc/ansi.h: /usr/include/ppc/i386.h:
 #define _BSD_WINT_T_    _BSD_CT_RUNE_T_
and
 #define _BSD_CT_RUNE_T_ int /* arg type for ctype funcs */
So you can probably use "const uint WEOF = uint.max;" all over. Then again, shouldn't they have type wint_t? As in: "const wint_t WEOF = 0xFFFFFFFF;" and "extern (C) wint_t fgetwc(FILE *);" Pretending that the "wchar_t" typedef in C is the same as the wchar type in D is not true, or at least not portable? wchar_t is either wchar (on Windows), or dchar (on others) The type wint_t should be able to hold all wchar_t + WEOF. I suppose one could use the name wchar_t for it: "version (Windows) { alias wchar wchar_t; } else version (Unix) { alias dchar wchar_t; }" And then "wint_t" can just be a wchar_t alias? On some platforms, wchar_t is 32 bits while wint_t is 64 bits! But I guess that Phobos still have a few other 64 bit corners? --anders
Nov 21 2004