Announcement

Collapse
No announcement yet.

Newbie question about string declarations

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Newbie question about string declarations

    Hi

    PB newbie question. I'm trying to understand the difference between these two options for string declarations in PB. The manual does not seem to differentiate between then clearly. Are they essentially the same thing.

    DIM a$
    DIM a as STRING

    Would appreciate if anyone shed some light please

    Thanks

  • #2
    They are the same. It's a throwback to the original BASIC syntax, which is why there are no type specifiers for ASCIIZ or VARIANTs (amongst others). Once you have declared the variable, the type specifier is optional.

    I prefer the latter.
    kgpsoftware.com | Slam DBMS | PrpT Control | Other Downloads | Contact Me

    Comment


    • #3
      Yes, they are the same.
      When passing a value and using #DIM ALL (which you should always use)
      the "a AS STRING" must be used instead of "a$" or each occurrance of
      "a" must be defned as "a$" within the SUB or FUNCTION.
      Personally, I use DIM a AS STRING unless in a hurry. Same answer as Kev.

      Code:
      #DIM ALL
      FUNCTION PBMAIN () AS LONG
           test("abc")
      END FUNCTION
      SUB test(a$)
        ? a
      END SUB
      SUB test2(a AS STRING)
        ? a
      END SUB

      Comment


      • #4
        FYI: It's the same way with numbers.

        dim a as long
        a = 14

        will compile as will:

        a! = 14 (without the dim statement)

        That is, of course, you need to not use the #DIM ALL compiler directive.
        There are no atheists in a fox hole or the morning of a math test.
        If my flag offends you, I'll help you pack.

        Comment


        • #5
          You might consider using LOCAL instead of DIM.

          Code:
          #DIM ALL
          GLOBAL gs AS STRING
          FUNCTION PBMAIN () AS LONG
            gs = "abc"
            test
            ? "The value of gs> " + gs
            WAITKEY$
          END FUNCTION
          SUB Test
            LOCAL gs AS STRING  'assure value is local  scope
            'DIM   gs as STRING  'value takes the global scope
            gs = "def"
            ? "The value of gs> " + gs
          END SUB

          Comment


          • #6
            Originally posted by Mel Bishop View Post
            FYI: It's the same way with numbers.

            dim a as long
            a = 14

            will compile as will:

            a! = 14 (without the dim statement)

            That is, of course, you need to not use the #DIM ALL compiler directive.
            Not quite. It will compile as a& = 14. Bang is a single.
            Neil Croft (cissp)

            Comment


            • #7
              Technically "Dim" is for arrays, "Local" is for variables, although "Dim" compiles just as well for a variable (But its a bad habit I am trying to break myself )

              Code:
              Local MyString as String
              Local MyLong as Long
              Dim MyArrayString(0) as String
              Dim MyArrayLong(0) as Long
              Engineer's Motto: If it aint broke take it apart and fix it

              "If at 1st you don't succeed... call it version 1.0"

              "Half of Programming is coding"....."The other 90% is DEBUGGING"

              "Document my code????" .... "WHYYY??? do you think they call it CODE? "

              Comment


              • #8
                Originally posted by Cliff Nichols View Post
                ..."Dim" is for arrays, "Local" is for variables...
                Why?

                global a() as string
                -and-
                dim a() as global string
                -and-
                global t as long
                -and-
                dim t as global long

                Perform the same function so why is one "correct" and the other isn't? Both syntax styles are completely interchangeable.

                To my way of thinking, it's all a matter of preference and going with whatever floats your boat.

                If it ain't broke, don't fix it.
                There are no atheists in a fox hole or the morning of a math test.
                If my flag offends you, I'll help you pack.

                Comment


                • #9
                  Neil, I don't believe that Mel was implying that
                  dim a as long
                  a=14

                  and
                  a!=14

                  were equivalent statements but rather to show that the numeric type
                  identifier could be used or declared and both are valid.
                  Client Writeup for the CPA

                  buffs.proboards2.com

                  Links Page

                  Comment


                  • #10
                    Maybe so but that not what it said and it nearly gave me a heart attack as I know Longs are much faster than other data types and I have a lot of software running here that I suddenly thought was badly wrong.
                    Neil Croft (cissp)

                    Comment


                    • #11
                      Technically "Dim" is for arrays, "Local" is for variables, although "Dim" compiles just as well for a variable (But its a bad habit I am trying to break myself
                      DIM for scalar variables is a compiler-directing statement only (no executable code generated) .

                      DIM for arrays is both compiler-directing and executable, except when it is ignored completely (this is documented BTW).

                      Because of its schizophrenic behavior, DIM is not fun to work with. It is, however, a source of a 'warm and fuzzy' feeling because it is familiar.

                      Your mileage may vary.
                      Michael Mattias
                      Tal Systems (retired)
                      Port Washington WI USA
                      [email protected]
                      http://www.talsystems.com

                      Comment


                      • #12
                        My bad... amend that.....

                        " It is, however, for some a source of a 'warm and fuzzy' feeling ..."
                        Michael Mattias
                        Tal Systems (retired)
                        Port Washington WI USA
                        [email protected]
                        http://www.talsystems.com

                        Comment


                        • #13
                          Thanks folks that clears it up nicely

                          Comment


                          • #14
                            **deleted**
                            Last edited by Fred Buffington; 26 Feb 2009, 01:46 PM.
                            Client Writeup for the CPA

                            buffs.proboards2.com

                            Links Page

                            Comment

                            Working...
                            X