in reply to Using Array of Arrays

As an aside, it is strongly recommended that you declare variables as close to the point they are used as possible. Generally that means at the place where the first assignment is made to them. Consider:

while (my $inBuf = <csvFILE>) { chomp($inBuf); $inBuf =~ s/^\"//; # Take out any LEADING or $inBuf =~ s/\"$//; # TRAILING double quotes # OK, Process this record my @fields = split(/\,/,$inBuf); print "\nProcessing record $fields[0]"; push @rows, \@fields; # Can push \@fields because @fields is local t +o the loop } # End of csvFILE or we reached our Runaway count close csvFILE;

Note that the duplicated counters have gone. scalar @rows gives you the line count in any case. If you need an item count then the correct code would be:

my $items = 0; while (...) { ... $items += @fields; # Array in scalar context gives number of elemen +ts }

I presume you use strictures (use strict; use warnings;. If not you ought, always!

Also, parsing csv can be tricky. What will happen if your code meets the following line for example?

1,"This, or this and that",3

The better solution is to use one of the modules designed for the purpose such as Text::CSV.


DWIM is Perl's answer to Gödel

Replies are listed 'Best First'.
Re^2: Using Array of Arrays
by Aim9b (Monk) on Sep 20, 2007 at 13:18 UTC
    GrandFather, thanks for the tips. Yes I use strict and warnings. Also, I'd not heard of the declare when used (my) before, so I've been declaring all variables at the top of my program. Its a pain going back & forth, but I think it will help the next person, to see all fields at the outset. Right after my 'use' statements, I put the a string of  my $fieldname = 0  # What it's used for
    sort of as a quick ref for the next person...even if it's me.
    If I encounter the 1,"This... that you showed, I expect my array will just have 3 elements instead of the normal 10, and when I load the spreadsheet (via Win32::OLE), the other 7 cells in that row will be blank or 0.
    I'll try the Text::CSV, but I wanted to learn the raw "under the covers" way to do it first... it's a character flaw. ;-) but I think I then understand better what's happening.
    Thanks again. You folks have been a super help during this learning curve.

      There is a piece of common wisdom that says that you can remember about seven things at a time in your short term memory (Human register set I guess). So, given that limitation there is no reason at all to declare all your variables in one place at the start of anything - you'll forget them anyway.

      However, the much more important reason for declaring a variable as late as possible is that it is much easier to see where and how it is used. There is no need to know about a variable until the variable is needed so there is no need to burden the limited storage facility of the reader of your code by introducing variables before they are needed. Bottom line: Declaring variables early doesn't help anyone.

      There is nothing wrong with learning about the 'raw "under the covers" way to do it', but there are some tasks such as parsing generally, and parsing markup in particular that are much more subtle than one might first think. It is well worth being aware of the modules that are available for performing such tasks after your initial foray into rolling your own.


      Perl is environmentally friendly - it saves trees
        Ah, you are too wise, GrandFather. I'll convert from my COBOL thinking of 'Knowing where to look when my memory fails' to the perl way of 'it's right there in front of you'. However, what if I declare a field within a foreach loop, can I then use it after the loop exits? Thanks.
      If I encounter the 1,"This... that you showed, I expect my array will just have 3 elements instead of the normal 10

      1,"This, or this and that",3 will result in 4 (not 3) entries if you use a simple split. The important point is that split will not distinguish between the comma in the quoted string and a comma used to separate fields.

      If your data contains no strings then you won't have a problem. If it does contain strings you may encounter some rather subtle bugs including silently producing incorrect answers.


      Perl is environmentally friendly - it saves trees
        Yes, I see what you mean. I've been assurred that this will ALWAYS be numeric data, so embedded commas will never occur. Yeah right, until the day I put it into production. So, I think I'll just protect the user a little from himself. Thanks.