This looks like the right newgroup for FreePascal
questions...

I have the lastest FreePascal, as well as the TP/BP
compilers installed.  I am teaching myself Pascal this
year... just for fun and experience with alternative languages.
So far, I am not very impressed with Pascal; but that just
means finding different ways to accomplish things I guess.


I am trying to obtain the Integer value of the
first series of Digits (left-most characters)
found in a string...

examples:

"1abc"          We need to know the base for this to work right.
"123xyz"      
"15,..."          Basic and C have no problems with this one!
"100 54 7"    Basic and C have no problems with this one!

In each case, I need a routine smart enough to
be able to return:

1        (as integer)
123    (as integer)
15      (as integet)

when   Val(Str, intVar, errpos)   is used, then
all I ever get is  
  intVar == 0
and
  errpos == 1,2,3, etc...

INSTEAD of simply returning a VALID integer
value up to first invalid character found, just like
Qbasic, VBdos, and 'C' would do normally !!

Another factor here that I've noticed:

C offers the means to set the Base of the value
to be parsed from a string, I see no such function
offered in the TP/BP or FreePascal default supplied
library....    so how is that done?

where's sscanf() when you need it...
where's atoi() when you need it....
where's strtol() when you need it...

AIM: 'SirSkeptic'

Radical NetSurfer wrote:
> 
> This looks like the right newgroup for FreePascal
> questions...
> 
> I have the lastest FreePascal, as well as the TP/BP
> compilers installed.  I am teaching myself Pascal this
> year... just for fun and experience with alternative languages.
> So far, I am not very impressed with Pascal; but that just
> means finding different ways to accomplish things I guess.
> 
> I am trying to obtain the Integer value of the
> first series of Digits (left-most characters)
> found in a string...
> 
> examples:
> 
> "1abc"          We need to know the base for this to work right.
> "123xyz"
> "15,..."          Basic and C have no problems with this one!
> "100 54 7"    Basic and C have no problems with this one!
> 
> In each case, I need a routine smart enough to
> be able to return:
> 
> 1        (as integer)
> 123    (as integer)
> 15      (as integet)
> 
> when   Val(Str, intVar, errpos)   is used, then
> all I ever get is
>   intVar == 0
> and
>   errpos == 1,2,3, etc...
> 
> INSTEAD of simply returning a VALID integer
> value up to first invalid character found, just like
> Qbasic, VBdos, and 'C' would do normally !!

I have no idea what Val etc. does, it is not standard.  I assume it
tries to extract integers from strings.  However read, when applied
to the input file (not string) should return those values when
reading into an integer.  Any failure to do so means that some
requirement of the various standards has not been met.

IIRC the problem with Turbo and its descendants is that they expect
integers to be terminated with end-of-line (or possibly a blank)
and return 0 with a failure signal otherwise.  This is incorrect. 
The character that caused termination should be the next char in
the input file (or string), and available for examination.

The simplest thing is to write your own read (and Val) functions. 
read will require the use of get and f^, which is again missing
from Turbo.  Don't know about FreePascal.  For Turbo you can get my
txtfiles unit at:

  <http://cbfalconer.home.att.net/download/>

which, IIRC, will also give you proper read functions.  You can
adapt the code if you really need to parse from strings.  Maybe
call them sread, and pass a string and VAR index.

-- 
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson

Radical NetSurfer wrote:
> This looks like the right newgroup for FreePascal
> questions...
>
> I have the lastest FreePascal, as well as the TP/BP
> compilers installed.
>
> I am trying to obtain the Integer value of the
> first series of Digits (left-most characters)
> found in a string...
>
> examples:
>
> "1abc"          We need to know the base for this to work right.
> "123xyz"
> "15,..."          Basic and C have no problems with this one!
> "100 54 7"    Basic and C have no problems with this one!
>
> In each case, I need a routine smart enough to
> be able to return:
>
> 1        (as integer)
> 123    (as integer)
> 15      (as integet)
>
> when   Val(Str, intVar, errpos)   is used, then
> all I ever get is
>   intVar == 0
> and
>   errpos == 1,2,3, etc...
>
> INSTEAD of simply returning a VALID integer
> value up to first invalid character found, just like
> Qbasic, VBdos, and 'C' would do normally !!
>
> Another factor here that I've noticed:
>
> C offers the means to set the Base of the value
> to be parsed from a string, I see no such function
> offered in the TP/BP or FreePascal default supplied
> library....    so how is that done?
>
> where's sscanf() when you need it...
> where's atoi() when you need it....
> where's strtol() when you need it...

The policy of the fellows at Borland when creating TurboPascal was
to provide tools like Val() that only handled the simplest cases.
Sure, that made it a hell of a lot harder for the _users_ of the
compiler, but it made it easier for the _makers_ of the compiler,
the lovable fellows at Borland, and that's what was most important,
don't you think?

Borland was one of the main causes of the decline of Pascal.
Their version was a toy language for toy problems.  It's very
sad to see that the creators of FreePascal are proud to follow
in Borland's footsteps.

I attempted to reproduce strtol() in FreePascal:


*function strtol( s:string; var stopped:longint;
*                 base:longint) : longint;
*const gap = ord('a') - ord('0') - 10;
*var val,v,sign,p : longint;
*begin
*  s := lowercase(s);
*  val := 0; sign := 1;  p :=1;
*  // Skip blanks and '+'.
*  while pos( copy(s,p,1), ' +') > 0 do
*    inc(p);
*  if '-' = copy(s,p,1) then begin
*    sign := -1;  inc(p)
*  end;
*  if 0 = base then begin
*    base := 10;
*    if copy(s,p,1) = '0' then begin
*      base := 8;   inc(p);
*      if copy(s,p,1) = 'x' then begin
*        base := 16;   inc(p);
*      end
*    end
*  end;
*  for p := p to length(s) do begin
*    v := ord(s[p]) - ord('0');
*    if v>9 then
*      dec(v,gap);
*    if (v<0) or (v>=base) then begin
*      dec(p);   break;
*    end;
*    val := val*base + v;
*  end;
*  stopped := succ(p);
*  exit(val*sign)
*end;
*
*procedure test( s:string; base:longint);
*var p:longint;
*begin
*  writeln('String >>', s, '<<');
*  writeln('Value: ', strtol(s,p,base));
*  writeln('Leftover >>', copy(s,p,length(s)-p+1),'<<');
*end;
*
*begin
*  test( '1234?',10 );
*  test( '  +1234xyz', 10 );
*  test( '  -1234 foo bar', 10 );
*  test( 'ffglad', 16 );
*  test( '0Xff glad', 0 );
*  test( ' -ffff{', 16 );
*  test( ' -0xffff?', 0 );
*  test( '  -0778', 0 );
*end.

On 2005-02-20, Radical NetSurfer <RadSurfer@yahoo.com> wrote:
> first series of Digits (left-most characters)
> found in a string...
>
> examples:
>
> "1abc"          We need to know the base for this to work right.
> "123xyz"      
> "15,..."          Basic and C have no problems with this one!
> "100 54 7"    Basic and C have no problems with this one!
>
> In each case, I need a routine smart enough to
> be able to return:
>
> 1        (as integer)
> 123    (as integer)
> 15      (as integet)

Use strtoint in the sysutils unit (Delphi compat)

> when   Val(Str, intVar, errpos)   is used, then
> all I ever get is  
>   intVar == 0
> and
>   errpos == 1,2,3, etc...
>
> INSTEAD of simply returning a VALID integer
> value up to first invalid character found, just like
> Qbasic, VBdos, and 'C' would do normally !!

That's because VAL is meant as primitive for string->integer conversions,
and you are supposed to build your own over it.

Building an interpreter that takes care of all cases (base, trailing garbage) is
the C way, but the slow way.

Check the strutils, sysutils and string units in the documentation, and you'll find plenty
of string routines.

> Another factor here that I've noticed:
>
> C offers the means to set the Base of the value
> to be parsed from a string, I see no such function
> offered in the TP/BP or FreePascal default supplied
> library....    so how is that done?

Did you really read all the manuals?

> where's sscanf() when you need it...

Nowhere. Pascal is a compiled language, and its feature set
is large enough to not need various input/output interpreting
state machines.

> where's atoi() when you need it....
> where's strtol() when you need it...

In libc. If you really want it that much, just import it, will you?
FPC has excellent C import facilities.

On 2005-02-20, William James <w_a_x_man@yahoo.com> wrote:
>> where's atoi() when you need it....
>> where's strtol() when you need it...
>
> The policy of the fellows at Borland when creating TurboPascal was
> to provide tools like Val() that only handled the simplest cases.
> Sure, that made it a hell of a lot harder for the _users_ of the
> compiler, but it made it easier for the _makers_ of the compiler,
> the lovable fellows at Borland, and that's what was most important,
> don't you think?

A bit unfair isn't it? As this was to create both the fastest _and_
the cheapest compiler of its era.

> Borland was one of the main causes of the decline of Pascal.
> Their version was a toy language for toy problems.  It's very
> sad to see that the creators of FreePascal are proud to follow
> in Borland's footsteps.

Simply use strtoint, and please read the manuals before you make
unfounded claims.

http://www.freepascal.org/docs-html/rtl/strutils/numb2dec.html

Marco van de Voort wrote:
> On 2005-02-20, Radical NetSurfer <RadSurfer@yahoo.com> wrote:
> > first series of Digits (left-most characters)
> > found in a string...
> >
> > examples:
> >
> > "1abc"          We need to know the base for this to work right.
> > "123xyz"
> > "15,..."          Basic and C have no problems with this one!
> > "100 54 7"    Basic and C have no problems with this one!
> >
> > In each case, I need a routine smart enough to
> > be able to return:
> >
> > 1        (as integer)
> > 123    (as integer)
> > 15      (as integet)
>
> Use strtoint in the sysutils unit (Delphi compat)

The docs state:
-----------------------
StrToInt

Declaration:
    Function StrToInt(const s: string): integer;
Description:
    StrToInt will convert the string Sto an integer. If the string
  contains invalid characters or has an invalid format, then an
  EConvertError is raised.

    To be successfully converted, a string can contain a combination of
  numerical characters, possibly preceded by a minus sign (-). Spaces
are
  not allowed.
-------------------------

Why did you tell him to use a function thats even more primitive than
Val(), which at least allows leading spaces?


>
> > when   Val(Str, intVar, errpos)   is used, then
> > all I ever get is
> >   intVar == 0
> > and
> >   errpos == 1,2,3, etc...
> >
> > INSTEAD of simply returning a VALID integer
> > value up to first invalid character found, just like
> > Qbasic, VBdos, and 'C' would do normally !!
>
> That's because VAL is meant as primitive for string->integer
conversions,
> and you are supposed to build your own over it.

Did you get that?  FreePascal is intended to be an even lower level
language than ANSI Forth, whose >NUMBER will convert a string to an
integer even if there is trailing garbage.  If you want anything
medium-level, you have to roll it yourself.

>
> Building an interpreter that takes care of all cases (base, trailing
garbage) is
> the C way, but the slow way.

Slow for the writers of the compiler, but fast for the users of
the compiler---they don't have to write their own strtol().
Speaking of slowness, since FreePascal is a lower-level language
than C, why are FreePascal programs so much slower than those
written in GCC?

>
> Check the strutils, sysutils and string units in the documentation,
and you'll find plenty
> of string routines.

Did you really read all the manuals?  Does one of those units
really contain a function equal to strtol()?  If so, why didn't
you give us the name of the function?

>
> > Another factor here that I've noticed:
> >
> > C offers the means to set the Base of the value
> > to be parsed from a string, I see no such function
> > offered in the TP/BP or FreePascal default supplied
> > library....    so how is that done?
>
> Did you really read all the manuals?
>
> > where's sscanf() when you need it...
>
> Nowhere. Pascal is a compiled language, and its feature set
> is large enough to not need various input/output interpreting
> state machines.

What does that mean?  You seem not to realize that C is also a
compiled language.

>
> > where's atoi() when you need it....
> > where's strtol() when you need it...
>
> In libc. If you really want it that much, just import it, will you?
> FPC has excellent C import facilities.

Marco is angry because you expect Pascal to have functions as
sophisticated as those in C.  You're too demanding.  Remember,
the goal is to make things as easy as possible for the compiler
makers.  Can't you see the logic of that?  If the compiler makers
wrote a certain function that handled all cases, that would only
consume X man-hours.  By forcing each of the users to write it himself,
10000*X man-hours are wasted.  And if you churlishly refuse to write
it yourself, Marco angrily tells you to look to C.

When implementors of Pascal have attitudes like this, it's not
hard to see why C eclipsed Pascal.

Marco van de Voort wrote:
> On 2005-02-20, William James <w_a_x_man@yahoo.com> wrote:
> >> where's atoi() when you need it....
> >> where's strtol() when you need it...
> >
> > The policy of the fellows at Borland when creating TurboPascal was
> > to provide tools like Val() that only handled the simplest cases.
> > Sure, that made it a hell of a lot harder for the _users_ of the
> > compiler, but it made it easier for the _makers_ of the compiler,
> > the lovable fellows at Borland, and that's what was most important,
> > don't you think?
>
> A bit unfair isn't it? As this was to create both the fastest _and_
> the cheapest compiler of its era.

You don't get it.  There are 2 things that are far more important
than speed of compilation.

1. The speed and ease with which programs can be written.  Having
Val() instead of strtol() didn't help.

2. The speed of the executable produced by the compiler.  The compiler
is used by 1 programmer to create the program, but the program
executable may be used by hundreds of thousands of people.
It would have been better if the compiler compiled 4 times as
slowly but produced programs that ran twice as fast.

>
> > Borland was one of the main causes of the decline of Pascal.
> > Their version was a toy language for toy problems.  It's very
> > sad to see that the creators of FreePascal are proud to follow
> > in Borland's footsteps.
>
> Simply use strtoint, and please read the manuals before you make
> unfounded claims.
>
> http://www.freepascal.org/docs-html/rtl/strutils/numb2dec.html

The link documents Numb2Dec(), not strToInt().

The specs don't equal those of strtol(); a string's base can't
be inferred from a leading '0' or '0x'.  The doc states
"It assumes the number is represented using Base as the base.
No checking is performed to see whether S contains a valid number
using base Base."  Does that mean trailing garbage is ignored?

Using FreePascal 1.9.4, I tried this:

uses strutils;
begin
  writeln( Numb2Dec('  999zzwi',10) );
end.

and got this

numb2dec.pp(3,12) Error: Identifier not found "Numb2Dec"

Even if this function does allow garbage characters, it has
only recently been added.  A day late and a dollar short.

In article <1108894634.552808.26880@g14g2000cwa.googlegroups.com>,
 "William James" <w_a_x_man@yahoo.com> wrote:

> The specs don't equal those of strtol()

And the specs of strcpy() don't equal those of an ansistring assignment 
in Pascal, because an ansistring can contain null characters. Different 
languages have different base functionality, period.

All this trolling about how some particular C function is better than 
what Pascal has to offer on default of course incites annoyed replies 
from Pascal programmers (and if you're annoyed, you're less inclined to 
check whether you get the details right, so then the other party can 
again complain he got wrong or incomplete information).

Is it really that hard to see that all this whining about how C is 
sooooooooo much better and so much easier than Pascal is 
counterproductive if you're genuinely interested in learning Pascal? 
(which I somehow doubt given everything I've read until now)


Jonas

On 2005-02-20, William James <w_a_x_man@yahoo.com> wrote:
>> > 1        (as integer)
>> > 123    (as integer)
>> > 15      (as integet)
>>
>> Use strtoint in the sysutils unit (Delphi compat)
>
> The docs state:
> -----------------------
> StrToInt
>
> Declaration:
>     Function StrToInt(const s: string): integer;
> Description:
>     StrToInt will convert the string Sto an integer. If the string
>   contains invalid characters or has an invalid format, then an
>   EConvertError is raised.
>
>     To be successfully converted, a string can contain a combination of
>   numerical characters, possibly preceded by a minus sign (-). Spaces
> are
>   not allowed.
> -------------------------
>
> Why did you tell him to use a function thats even more primitive than
> Val(), which at least allows leading spaces?

Because it matches his examples.

>> > Qbasic, VBdos, and 'C' would do normally !!
>>
>> That's because VAL is meant as primitive for string->integer
> conversions,
>> and you are supposed to build your own over it.
>
> Did you get that?  FreePascal is intended to be an even lower level
> language than ANSI Forth,

I assume so.

> whose >NUMBER will convert a string to an integer even if there is
> trailing garbage.  If you want anything medium-level, you have to roll it
> yourself.

That is a bit simplistic way of looking at it isn't it? Based on one minor
feature?

I had to look up the numb2dec procedure myself, since I never needed it for
anything else then base 10 and the typical powers of 2 (that are supported
by e.g. strtoint)

>> Building an interpreter that takes care of all cases (base, trailing
> garbage) is
>> the C way, but the slow way.
>
> Slow for the writers of the compiler, but fast for the users of
> the compiler---they don't have to write their own strtol().

If the users are C converts that exist on strtol. Most don't insist on C
functions. Even the ones that do don't use insecure ancient unbounded
functions

> Speaking of slowness, since FreePascal is a lower-level language
> than C, why are FreePascal programs so much slower than those
> written in GCC?

You are twisting my words. That particular thing (the base IO primitives
being highlevel) is a problem with lowlevel working. Hence the cut down
derivatives like C51 are more cut down then necessarily needed.

>> Check the strutils, sysutils and string units in the documentation,
> and you'll find plenty
>> of string routines.
>
> Did you really read all the manuals?

Over time, except maybe of the newer parts: yes. As FPC devel I went through them
for correcting purposes. So I really read all the 2000 pages, yes, and even
wrote (relatively small) parts.

But looking which units there are in the base RTL is not the same as
memorising the 2000 pages, and can be done by an average user before posting
braindead rants.

>  Does one of those units
> really contain a function equal to strtol()? 

Who cares? Imitation insecure unbounded C functions is not a design
objective. Making programs in Pascal is.

You can now try to think up some insanely irrelevant bordercase just to make
a point (like base 17 with leading and trailing garbadge), but fact is
strtoint(trim(s)) or numb2dec(trim(s)) will come a long way in most cases.
strutils has been seriously expanded during the 1.9.x period, so it could
be that it is new in 1.9.6 or 1.9.8+

>> > where's sscanf() when you need it...
>>
>> Nowhere. Pascal is a compiled language, and its feature set
>> is large enough to not need various input/output interpreting
>> state machines.
>
> What does that mean?  You seem not to realize that C is also a
> compiled language.

I do of course know that. That's exactly why I wondered why doing basic
input/output is either insanely stupid (manually convert to string and then
write()) or interpretive (printf/scanf have to interpret the format string).

>> > where's atoi() when you need it....
>> > where's strtol() when you need it...
>>
>> In libc. If you really want it that much, just import it, will you?
>> FPC has excellent C import facilities.
>
> Marco is angry because you expect Pascal to have functions as
> sophisticated as those in C.  

Sophisticated and C in one line. You are funny!

> You're too demanding.  Remember,
> the goal is to make things as easy as possible for the compiler
> makers.

Yeah, that's why we bother to crack up to implement a complex language as Delphi
with a full scale RAD and thousands of pages of docs, instead of wasting time
on base 17 conversions :_)

>  Can't you see the logic of that?  If the compiler makers wrote a certain
> function that handled all cases, that would only consume X man-hours.

But implementing border cases would take developer time away from actually much used
parts of the devlepment process. (and believe me, even though I'm FPC devel, I know FPC
is far from perfect and there is enough left to do, as you already remarked,
there is a delphi incompat in strtoint.....)

Look C, just happens to have this one border case. The large 

> By forcing each of the users to write it himself, 10000*X man-hours
> are wasted.  And if you churlishly refuse to write it yourself, Marco
> angrily tells you to look to C.

There will be a few users that need odd bases, and most will be doing homework,
and will have to implement it manually for their teacher anyway.

> When implementors of Pascal have attitudes like this, it's not
> hard to see why C eclipsed Pascal.

If you really believe that, then you obviously have no clue.

Jonas Maebe wrote:
> In article <1108894634.552808.26880@g14g2000cwa.googlegroups.com>,
>  "William James" <w_a_x_man@yahoo.com> wrote:
>
> > The specs don't equal those of strtol()
>
> And the specs of strcpy() don't equal those of an ansistring
assignment
> in Pascal, because an ansistring can contain null characters.
Different
> languages have different base functionality, period.
>
> All this trolling about how some particular C function is better than

> what Pascal has to offer on default of course incites annoyed replies

> from Pascal programmers (and if you're annoyed, you're less inclined
to
> check whether you get the details right, so then the other party can
> again complain he got wrong or incomplete information).
>
> Is it really that hard to see that all this whining about how C is
> sooooooooo much better and so much easier than Pascal is
> counterproductive if you're genuinely interested in learning Pascal?
> (which I somehow doubt given everything I've read until now)

Geez! It is about _time_ someone said something! I'm sick of Rad and
his attacks. He is making statements about C that are, at the least,
not completely true. C doesn't even have the functions he mentions.
They are present in C libraries. Don't confuse library routines with
the language!

The language of C contains less than 30 functions. Most Pascal dialects
have more than this, and most (non-Standard) have built-in String
functions, such as Length, Copy, Delete, Insert, Concat, Pos, etc.
These are built-in to my compiler, not in some library somewhere. And
whether or not library routines exists, depends on the version of
Pascal. Mine has span and break in a library, two useful routines that
can be used to build a better library if I need it.

As for the Val function, and how it works... in
comp.lang.pascal.borland, Rad posted a similar message, whining about
Val and how even Basic can take a VAL of a string containing
non-numeric characters. THIS ISN'T TRUE OF ALL BASICS.

Just a question? If you find Pascal so distasteful, why are you using
it?

Or are you a troll. You smell like one...

Ben

"Marco van de Voort" <marcov@stack.nl> wrote in message
news:slrnd1h2gk.1mjs.marcov@turtle.stack.nl...

You have the patience of Job. I salute you. :^)

BTW: This is the first time I've seen C-Disciples trolling in
teams. Does this happen often?

-- 
Charles Appel
"A generation which ignores history has no past - and no future."
      Robert Anson Heinlein

On 2005-02-20, Charles Appel <charlesappel@mindspring.com> wrote:
> "Marco van de Voort" <marcov@stack.nl> wrote in message
> news:slrnd1h2gk.1mjs.marcov@turtle.stack.nl...
>
> You have the patience of Job. I salute you. :^)

I actually see myself as quickly inflammable one. Jonas is the calm one:-)

> BTW: This is the first time I've seen C-Disciples trolling in
> teams. Does this happen often?

Yes and no. Usually they are not as persistant, and give up after 1 or 2
attempts, and continue with their homework (which is why they discovered
this NG in the first place)

They typically think they are ueberhackers because they wrote a few thousand
lines of C (that wouldn't hold up to any sourcecode review standard, note
their use of unbounded functions forbidden since 1990), and look down on
Pascal without knowing the simplest things, and now are forced to use it for
their first ever structured programming.

The current set seems to be fairly typical.

Some other typical elements:
- Being unable to detangle from a C mind set (typically only done VB and then
	moved to C(++) and never seen anything except some HTML and webscript
 	languages) (defintely guilty)
- "if you would do this, and X users would benefit"  (Current set typical as can be)
- don't knowing publically known C downsides like the interpretive IO and/or
  unsafe unbounded funcs. Real C hacks have seen the ugly sides of the language
  (current set: typical)	
- thinking that lowlevel _looking_ stuff is faster without profiling (current
 set is not guilty of this. In that sense they are atypical, they don't focus as
 much on the perceived performance aspect as usual)
- Not realising I'm helping them voluntarily with their homework (current set: typical)

"Marco van de Voort" <marcov@stack.nl> wrote in message
news:slrnd1h8q3.1pjc.marcov@turtle.stack.nl...
> The current set seems to be fairly typical.
>
> Some other typical elements:
> - Being unable to detangle from a C mind set (typically only done VB and
then
> moved to C(++) and never seen anything except some HTML and webscript
>   languages) (defintely guilty)
> - "if you would do this, and X users would benefit"  (Current set typical
as can be)
> - don't knowing publically known C downsides like the interpretive IO
and/or
>   unsafe unbounded funcs. Real C hacks have seen the ugly sides of the
language
>   (current set: typical)
> - thinking that lowlevel _looking_ stuff is faster without profiling
(current
>  set is not guilty of this. In that sense they are atypical, they don't
focus as
>  much on the perceived performance aspect as usual)
> - Not realising I'm helping them voluntarily with their homework (current
set: typical)

Thanks. Very interesting.

-- 
Charles Appel
"A generation which ignores history has no past - and no future."
      Robert Anson Heinlein

JRS:  In article <4217F40A.84371621@yahoo.com>, dated Sun, 20 Feb 2005
02:33:31, seen in news:comp.lang.pascal.misc, CBFalconer
<cbfalconer@yahoo.com> posted :
>
>IIRC the problem with Turbo and its descendants is that they expect
>integers to be terminated with end-of-line (or possibly a blank)
>and return 0 with a failure signal otherwise.  

The problem with CBF is that he often DNRC about TP/BP; though sometimes
he RCs nearly enough correctly to be plausible.

Standard-pascal-fanatic type answers are not appropriate in c.l.p.misc;
there is a c.l.p.ansi-iso group for them, which the OP has chosen not to
use.
 
-- 
 � John Stockton, Surrey, UK.  ?@merlyn.demon.co.uk   Turnpike v4.00   MIME. �
  <URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links;
  <URL:http://www.merlyn.demon.co.uk/clpb-faq.txt>   RAH Prins : c.l.p.b mFAQ;
  <URL:ftp://garbo.uwasa.fi/pc/link/tsfaqp.zip> Timo Salmi's Turbo Pascal FAQ.

Marco van de Voort wrote:
> On 2005-02-20, William James <w_a_x_man@yahoo.com> wrote:
> 
.... snip ...
>>
>> The policy of the fellows at Borland when creating TurboPascal was
>> to provide tools like Val() that only handled the simplest cases.
>> Sure, that made it a hell of a lot harder for the _users_ of the
>> compiler, but it made it easier for the _makers_ of the compiler,
>> the lovable fellows at Borland, and that's what was most important,
>> don't you think?
> 
> A bit unfair isn't it? As this was to create both the fastest _and_
> the cheapest compiler of its era.

Not really.  The fundamental thing missing was f^, put, and get.  I
successfully bolted on f^ and get (with unfortunately varying
syntax) without too much trouble.  They could have easily done as
much in the compiler when they made the major upgrade to V4 circa
'87.  AFAIK my txtfiles unit has worked on all their versions from
then on.  I don't know if it works with FreePascal.  Once again:

    <http://cbfalconer.home.att.net/download/>

All Borland really had to do was read the standard.  It had been
out for at least 6 years.

-- 
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson

William James wrote:
> 
.... snip ...
> 
> Marco is angry because you expect Pascal to have functions as
> sophisticated as those in C.  You're too demanding.  Remember,
> the goal is to make things as easy as possible for the compiler
> makers.  Can't you see the logic of that?  If the compiler makers
> wrote a certain function that handled all cases, that would only
> consume X man-hours.  By forcing each of the users to write it
> himself, 10000*X man-hours are wasted.  And if you churlishly
> refuse to write it yourself, Marco angrily tells you to look to C.
> 
> When implementors of Pascal have attitudes like this, it's not
> hard to see why C eclipsed Pascal.

No, the primary reason was Borlands refusal to follow the
standards.  C functions, in general, are not at all sophisticated. 
Some are complex and bug traps, such as variadic functions.  Most C
functions cannot even detect bad parameters.

OTOH Pascal can often detect bad calls at compile time, and has no
variadic functions to foul.  (The shorthand expansion of read,
readln, write, writeln as specified in the standards, is not a
variadic function.  It just looks that way.)

-- 
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson

On 2005-02-20, CBFalconer <cbfalconer@yahoo.com> wrote:
> Marco van de Voort wrote:
>> On 2005-02-20, William James <w_a_x_man@yahoo.com> wrote:
>> 
> ... snip ...
>>>
>>> The policy of the fellows at Borland when creating TurboPascal was
>>> to provide tools like Val() that only handled the simplest cases.
>>> Sure, that made it a hell of a lot harder for the _users_ of the
>>> compiler, but it made it easier for the _makers_ of the compiler,
>>> the lovable fellows at Borland, and that's what was most important,
>>> don't you think?
>> 
>> A bit unfair isn't it? As this was to create both the fastest _and_
>> the cheapest compiler of its era.
>
> Not really.  The fundamental thing missing was f^, put, and get.  I
> successfully bolted on f^ and get (with unfortunately varying
> syntax) without too much trouble.  They could have easily done as
> much in the compiler when they made the major upgrade to V4 circa
> '87.  AFAIK my txtfiles unit has worked on all their versions from
> then on.  I don't know if it works with FreePascal.  Once again:
>
>     <http://cbfalconer.home.att.net/download/>
>
> All Borland really had to do was read the standard.  It had been
> out for at least 6 years.

How do you solve the case it is not in a file standards compliant?

In many ways I tend to agree with this accessment of Borlands
implementation of their dialect of Pascal; it never struct me as
anywhere as mature (for a complile) for the time...  

Numb2Dec()  does NOT exist in my 1.0.10 version version either...

StrToInt()       exists but again does not take a Base.

There are different conventions (ie. Dialects) of Pascal and C.
Granted, of most languages, more and more mature programmers
eventually move to 'C' because it accomplishes a lot more in far
less time of development.

A language is a language... A dialect is a slightly different
implementation of a language (not always for the better),
and the support libraries, *.lib and *.tpu, *.ppu (whatever),
are EXTENSIONS to help ease coding...

There was absolutely no reason for Borland to be so sloppy
with their Turbo and Borland Pascal ...
of course that is like expecting Microsoft to not steal from
others and only try to develop in house; we know that will never
happen... let alone fix the 4000+ known bugs to date.

BTW: I was given another version of StrToL, and LtoA to try,
         if you're interested, look at the
comp.language.pascal.borland... great people there.
Most of them are willing to take a little criticism.
We still value their comments and help :-)

On 20 Feb 2005 00:18:59 -0800, "William James" <w_a_x_man@yahoo.com>
wrote:

>Radical NetSurfer wrote:
[ snippity snip ]
>> INSTEAD of simply returning a VALID integer
>> value up to first invalid character found, just like
>> Qbasic, VBdos, and 'C' would do normally !!
>>
>> Another factor here that I've noticed:
>>
>> C offers the means to set the Base of the value
>> to be parsed from a string, I see no such function
>> offered in the TP/BP or FreePascal default supplied
>> library....    so how is that done?
>>
>> where's sscanf() when you need it...
>> where's atoi() when you need it....
>> where's strtol() when you need it...

>The policy of the fellows at Borland when creating TurboPascal was
>to provide tools like Val() that only handled the simplest cases.
>Sure, that made it a hell of a lot harder for the _users_ of the
>compiler, but it made it easier for the _makers_ of the compiler,
>the lovable fellows at Borland, and that's what was most important,
>don't you think?
>
>Borland was one of the main causes of the decline of Pascal.
>Their version was a toy language for toy problems.  It's very
>sad to see that the creators of FreePascal are proud to follow
>in Borland's footsteps.
>
>I attempted to reproduce strtol() in FreePascal:
>
>
>*function strtol( s:string; var stopped:longint;
>*                 base:longint) : longint;
>*const gap = ord('a') - ord('0') - 10;
>*var val,v,sign,p : longint;
>*begin
>*  s := lowercase(s);
>*  val := 0; sign := 1;  p :=1;
>*  // Skip blanks and '+'.
>*  while pos( copy(s,p,1), ' +') > 0 do
>*    inc(p);
>*  if '-' = copy(s,p,1) then begin
>*    sign := -1;  inc(p)
>*  end;
>*  if 0 = base then begin
>*    base := 10;
>*    if copy(s,p,1) = '0' then begin
>*      base := 8;   inc(p);
>*      if copy(s,p,1) = 'x' then begin
>*        base := 16;   inc(p);
>*      end
>*    end
>*  end;
>*  for p := p to length(s) do begin
>*    v := ord(s[p]) - ord('0');
>*    if v>9 then
>*      dec(v,gap);
>*    if (v<0) or (v>=base) then begin
>*      dec(p);   break;
>*    end;
>*    val := val*base + v;
>*  end;
>*  stopped := succ(p);
>*  exit(val*sign)
>*end;
>*
>*procedure test( s:string; base:longint);
>*var p:longint;
>*begin
>*  writeln('String >>', s, '<<');
>*  writeln('Value: ', strtol(s,p,base));
>*  writeln('Leftover >>', copy(s,p,length(s)-p+1),'<<');
>*end;
>*
>*begin
>*  test( '1234?',10 );
>*  test( '  +1234xyz', 10 );
>*  test( '  -1234 foo bar', 10 );
>*  test( 'ffglad', 16 );
>*  test( '0Xff glad', 0 );
>*  test( ' -ffff{', 16 );
>*  test( ' -0xffff?', 0 );
>*  test( '  -0778', 0 );
>*end.

On Sun, 20 Feb 2005 17:17:55 -0500, Radical NetSurfer
<RadSurfer@yahoo.com> wrote:

>Granted, of most languages, more and more mature programmers
>eventually move to 'C' because it accomplishes a lot more in far
>less time of development.

Huh???

---
Replace you know what by j to email

Previous version used copy(s,p,1) instead of s[p].
Mea culpa.

*function strtol( s:string; var stopped:longint;
*                 base:longint) : longint;
*const gap = ord('a') - ord('0') - 10;
*var val,v,sign,p : longint;
*begin
*  s := lowercase(s);
*  val := 0;  sign := 1;  p :=1;
*  // Skip blanks and '+'.
*  while pos( s[p], ' +') > 0 do
*    inc(p);
*  if '-' = s[p] then begin
*    sign := -1;  inc(p)
*  end;
*  if 0 = base then begin
*    base := 10;
*    if '0' = s[p] then begin
*      base := 8;   inc(p);
*      if 'x' = s[p] then begin
*        base := 16;   inc(p);
*      end
*    end
*  end;
*  for p := p to length(s) do begin
*    v := ord(s[p]) - ord('0');
*    if v>9 then
*      dec(v,gap);
*    if (v<0) or (v>=base) then begin
*      dec(p);   break;
*    end;
*    val := val*base + v;
*  end;
*  stopped := succ(p);
*  exit(val*sign)
*end;

In article <q84i11507amapnmncg6pnu7j3t1f604g6i@4ax.com>,
 Jud McCranie <youknowwhat.mccranie@adelphia.net> wrote:

> >Granted, of most languages, more and more mature programmers
> >eventually move to 'C' because it accomplishes a lot more in far
> >less time of development.
> 
> Huh???

Well Jud, that's not a very helpful answer! Didn't you read his remark 
that the people in clpb are much more helpful? This way, that stance is 
never going to change, and we really do want to be liked by this great 
person with all his insightful and thought-provoking contributions, 
don't we?


Jonas

Marco van de Voort wrote:
> On 2005-02-20, CBFalconer <cbfalconer@yahoo.com> wrote:
>> Marco van de Voort wrote:
>>> On 2005-02-20, William James <w_a_x_man@yahoo.com> wrote:
>>>
>> ... snip ...
>>>>
>>>> The policy of the fellows at Borland when creating TurboPascal was
>>>> to provide tools like Val() that only handled the simplest cases.
>>>> Sure, that made it a hell of a lot harder for the _users_ of the
>>>> compiler, but it made it easier for the _makers_ of the compiler,
>>>> the lovable fellows at Borland, and that's what was most important,
>>>> don't you think?
>>>
>>> A bit unfair isn't it? As this was to create both the fastest _and_
>>> the cheapest compiler of its era.
>>
>> Not really.  The fundamental thing missing was f^, put, and get.  I
>> successfully bolted on f^ and get (with unfortunately varying
>> syntax) without too much trouble.  They could have easily done as
>> much in the compiler when they made the major upgrade to V4 circa
>> '87.  AFAIK my txtfiles unit has worked on all their versions from
>> then on.  I don't know if it works with FreePascal.  Once again:
>>
>>     <http://cbfalconer.home.att.net/download/>
>>
>> All Borland really had to do was read the standard.  It had been
>> out for at least 6 years.
> 
> How do you solve the case it is not in a file standards compliant?

I fail to parse this :-)

-- 
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson

On 2005-02-21, CBFalconer <cbfalconer@yahoo.com> wrote:
>>> then on.  I don't know if it works with FreePascal.  Once again:
>>>
>>>     <http://cbfalconer.home.att.net/download/>
>>>
>>> All Borland really had to do was read the standard.  It had been
>>> out for at least 6 years.
>> 
>> How do you solve the case it is not in a file standards compliant?
>
> I fail to parse this :-)

The original question was about strtol, to parse a string with leading spaces
and trailing junk.

You replied it was a defect in Borland (as usual) that it could be done in a
single procedure, and refered to Ansi ISO file details.

How would you solve it by using a standard procedure in Ansi ISO (I believe
you used the original standard?) for the string, not file, case?

"Jonas Maebe" <Jonas.Maebe@rug.SPAM.ac.ME.be.NOT> wrote in message
news:Jonas.Maebe-74FBDC.09470121022005@gaudi2.ugent.be...
> In article <q84i11507amapnmncg6pnu7j3t1f604g6i@4ax.com>,
>  Jud McCranie <youknowwhat.mccranie@adelphia.net> wrote:
>
> > >Granted, of most languages, more and more mature programmers
> > >eventually move to 'C' because it accomplishes a lot more in far
> > >less time of development.
> >
> > Huh???
>
> Well Jud, that's not a very helpful answer! Didn't you read his remark
> that the people in clpb are much more helpful? This way, that stance is
> never going to change, and we really do want to be liked by this great
> person with all his insightful and thought-provoking contributions,
> don't we?

No.

-- 
Charles Appel
"A generation which ignores history has no past - and no future."
      Robert Anson Heinlein

Marco van de Voort wrote:
> 
> On 2005-02-21, CBFalconer <cbfalconer@yahoo.com> wrote:
> >>> then on.  I don't know if it works with FreePascal.  Once again:
> >>>
> >>>     <http://cbfalconer.home.att.net/download/>
> >>>
> >>> All Borland really had to do was read the standard.  It had been
> >>> out for at least 6 years.
> >>
> >> How do you solve the case it is not in a file standards compliant?
> >
> > I fail to parse this :-)
> 
> The original question was about strtol, to parse a string with leading spaces
> and trailing junk.
> 
> You replied it was a defect in Borland (as usual) that it could be done in a
> single procedure, and refered to Ansi ISO file details.
> 
> How would you solve it by using a standard procedure in Ansi ISO (I believe
> you used the original standard?) for the string, not file, case?

I would adapt the code that reads integers in the above mentioned
txtfiles units.  In place of file it requires a string and a
starting index, and should probably indicate an ending index
somehow.  The first task is to design the interface.
-- 
 Some informative links:
   news:news.announce.newusers
   http://www.geocities.com/nnqweb/
   http://www.catb.org/~esr/faqs/smart-questions.html
   http://www.caliburn.nl/topposting.html
   http://www.netmeister.org/news/learn2quote.html

The following function would do what you need.

function myval(s: string): integer;

var i, v: integer;

begin

    i := 1;
    v := 0;
    while i <= length(s) do begin

       if not (s[i] in ['0'..'9']) then i := maxint
       else begin

          v := v*10+ord(s[i])-ord('0');
          i := i+1

       end

    end;

    myval := v

end;

Radical NetSurfer wrote:
> This looks like the right newgroup for FreePascal
> questions...
> 
> I have the lastest FreePascal, as well as the TP/BP
> compilers installed.  I am teaching myself Pascal this
> year... just for fun and experience with alternative languages.
> So far, I am not very impressed with Pascal; but that just
> means finding different ways to accomplish things I guess.
> 
> 
> I am trying to obtain the Integer value of the
> first series of Digits (left-most characters)
> found in a string...
> 
> examples:
> 
> "1abc"          We need to know the base for this to work right.
> "123xyz"      
> "15,..."          Basic and C have no problems with this one!
> "100 54 7"    Basic and C have no problems with this one!
> 
> In each case, I need a routine smart enough to
> be able to return:
> 
> 1        (as integer)
> 123    (as integer)
> 15      (as integet)
> 
> when   Val(Str, intVar, errpos)   is used, then
> all I ever get is  
>   intVar == 0
> and
>   errpos == 1,2,3, etc...
> 
> INSTEAD of simply returning a VALID integer
> value up to first invalid character found, just like
> Qbasic, VBdos, and 'C' would do normally !!
> 
> Another factor here that I've noticed:
> 
> C offers the means to set the Base of the value
> to be parsed from a string, I see no such function
> offered in the TP/BP or FreePascal default supplied
> library....    so how is that done?
> 
> where's sscanf() when you need it...
> where's atoi() when you need it....
> where's strtol() when you need it...
> 
> AIM: 'SirSkeptic'
> 


-- 
Samiam is Scott A. Moore

Personal web site: http:/www.moorecad.com/scott
My electronics engineering consulting site: http://www.moorecad.com
ISO 7185 Standard Pascal web site: http://www.moorecad.com/standardpascal
Classic Basic Games web site: http://www.moorecad.com/classicbasic
The IP Pascal web site, a high performance, highly portable ISO 7185 Pascal
compiler system: http://www.moorecad.com/ippas

Good does not always win. But good is more patient.