[12383] in Perl-Users-Digest
Perl-Users Digest, Issue: 5983 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Jun 14 05:07:20 1999
Date: Mon, 14 Jun 99 02:00:15 -0700
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 14 Jun 1999 Volume: 8 Number: 5983
Today's topics:
Re: Afraid to ask about Y2K! (Abigail)
Case select statements: are they in Perl? <streaking_pyro@my-deja.com>
Re: Case select statements: are they in Perl? (Sam Holden)
Re: Case select statements: are they in Perl? (Michael Fuhr)
Re: Far shorter solution! <gellyfish@gellyfish.com>
Re: Fix this uglyness <bie@connect.ab.ca>
Re: Ooops, my bad <gellyfish@gellyfish.com>
Re: Perl "constructors" armchair@my-deja.com
Re: Perl "constructors" armchair@my-deja.com
Re: Perl "constructors" armchair@my-deja.com
Re: Perl "constructors" armchair@my-deja.com
Re: Perl "constructors" armchair@my-deja.com
Re: Perl "constructors" armchair@my-deja.com
Re: simple math question! Why doesn't the * multiply t (Larry Rosler)
Re: simple math question! Why doesn't the * multiply t <rootbeer@redcat.com>
Special: Digest Administrivia (Last modified: 12 Dec 98 (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 13 Jun 1999 17:58:06 -0500
From: abigail@delanet.com (Abigail)
Subject: Re: Afraid to ask about Y2K!
Message-Id: <slrn7m8eca.bmf.abigail@alexandra.delanet.com>
finsol@ts.co.nz (finsol@ts.co.nz) wrote on MMCXI September MCMXCIII in
<URL:news:7jspcn$2c4$1@nnrp1.deja.com>:
##
## Why don't the Perl faction act more responsibly and offer suggestions as
## to how Y2K audits are best done on Perl applications, the types of
## problems found, the types of environments more likely to exhibit
## problems, the percentage of problems found to lines of code checked, how
## many problems were found through application testing as opposed to code
## checking?, how many problems were found in supposedly remediated code?,
## how were these problems found? etc. etc.
While these problems might be interesting, they are not at all Perl
specific. Hence, they are OFF TOPIC in this newsgroup. They should be
discussed in either general programming groups, or (better IMO) the
specific Y2K groups.
This group discusses Perl. Perl DOES NOT HAVE A Y2K PROBLEM. (But you
keep shutting down your brain on that statement). Programmers might
not be Y2K compliant, hence they should be discussed in newsgroups for
programmers, not in the Perl newsgroups.
Go away.
Abigail
--
perl -we '$@="\145\143\150\157\040\042\112\165\163\164\040\141\156\157\164".
"\150\145\162\040\120\145\162\154\040\110\141\143\153\145\162".
"\042\040\076\040\057\144\145\166\057\164\164\171";`$@`'
-----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
http://www.newsfeeds.com The Largest Usenet Servers in the World!
------== Over 73,000 Newsgroups - Including Dedicated Binaries Servers ==-----
------------------------------
Date: Mon, 14 Jun 1999 06:27:01 GMT
From: R.Joseph <streaking_pyro@my-deja.com>
Subject: Case select statements: are they in Perl?
Message-Id: <7k27bg$h32$1@nnrp1.deja.com>
In VB you have CASE, in C/C++ you have Switch(), in Perl you have ____
(please fill in the blank). Is there a case select statement in Perl,
or am I looking forward to a wrechted life of writing "if" and "elsif"
alot? Any help is greatly apprecitaed!
--
R.Joseph
http://www.24-7design.com
http://bowdown.to
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
Date: 14 Jun 1999 07:29:36 GMT
From: sholden@pgrad.cs.usyd.edu.au (Sam Holden)
Subject: Re: Case select statements: are they in Perl?
Message-Id: <slrn7m9br0.imj.sholden@pgrad.cs.usyd.edu.au>
On Mon, 14 Jun 1999 06:27:01 GMT, R.Joseph <streaking_pyro@my-deja.com> wrote:
>In VB you have CASE, in C/C++ you have Switch(), in Perl you have ____
>(please fill in the blank). Is there a case select statement in Perl,
>or am I looking forward to a wrechted life of writing "if" and "elsif"
>alot? Any help is greatly apprecitaed!
You could try reading the documentation that comes with perl. You'll
find the answer faster, you'll learn your way around the documentation so
you can find other answers faster, and you won't ask a FAQ.
Which part of the answer to this FAQ did you not understand ?
perlfaq7: How do I create a switch or case statement?
Or did you completely ignore the documentation in front of you and
decide to ask in a newsgroup instead. Have you ever considered that other
people's time might actually be valuable and that you should do some research
before wasting it?
--
Sam
Many modern computer languages aspire to be minimalistic. They either
succeed in being minimalistic, in which case they're relatively useless,
or they don't succeed in being truly minimalistic, in which case you can
actually solve real problems with them. --Larry Wall
------------------------------
Date: 14 Jun 1999 01:34:21 -0600
From: mfuhr@dimensional.com (Michael Fuhr)
Subject: Re: Case select statements: are they in Perl?
Message-Id: <7k2b9t$i9o@flatland.dimensional.com>
R.Joseph <streaking_pyro@my-deja.com> writes:
> In VB you have CASE, in C/C++ you have Switch(), in Perl you have ____
> (please fill in the blank). Is there a case select statement in Perl,
> or am I looking forward to a wrechted life of writing "if" and "elsif"
> alot? Any help is greatly apprecitaed!
Many questions like this are answered in the Perl FAQ:
http://language.perl.com/faq/
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
Deja.com also has a search feature. It's always a good idea to see if
somebody has already answered a question before asking it again -- you
get the answer quicker and there's less newsgroup traffic for everybody
else.
Hope this helps.
--
Michael Fuhr
http://www.fuhr.org/~mfuhr/
------------------------------
Date: 14 Jun 1999 09:11:02 +0100
From: Jonathan Stowe <gellyfish@gellyfish.com>
Subject: Re: Far shorter solution!
Message-Id: <3764b916@newsread3.dircon.co.uk>
Larry Rosler <lr@hpl.hp.com> wrote:
> In article <7k0np5$3kp$1@nnrp1.deja.com> on Sun, 13 Jun 1999 16:55:03
> GMT, Brad Clawsie <bradclawsie@my-deja.com> says...
>> Most of the typing can be avoided with the -M file test.
>>
>> #!/usr/local/bin/perl -w
>> opendir(DIR, ".");
>> my @sorted_files = sort { -M $a <=> -M $b } readdir(DIR);
>> closedir(DIR);
>>
>> the last line can probably be omitted too, if you're a brevity freak.
>
> This naive solution is likely to be orders of magnitude slower than the
> quasi-"Schwartzian Transform" solution posted by Jonathan Stowe that you
> are comparing to. Sometimes shortest isn't best.
>
It might be worth pointing out that I was following the original poster
in the use of the hash to store the mtimes for each file and given that as
a starting point, this was what appeared to be the simplest solution.
/J\
--
"I was the chief make-up artist on the Titanic" - Tina Earnshaw, Chief
Make-Up Artist, Titanic
------------------------------
Date: Sun, 13 Jun 1999 22:11:57 -0600
From: Tim <bie@connect.ab.ca>
Subject: Re: Fix this uglyness
Message-Id: <3764810D.4DA6@connect.ab.ca>
You don't have the time so u look for some lacky to do it for you?
heh..good luck
Alan wrote:
>
> I haven't the time to do it myself, so could someone please fix the systeming
> I used when I got tired:
>
> system("cat /var/log/wtmp | uuencode wtmp.`date +%m-%d` | mail $WTMPBACK");
> system("mkdir /var/wtmp 2> /dev/null");
> system("mv /var/log/wtmp /var/wtmp/wtmp.`date +%m-%d`");
> system("touch /var/log/wtmp");
>
> I just need a good way of doing that.
>
> --
> | Alan L. * Webmaster of www.UnixPower.org |
> | Windsor Unix Users Group Founder: http://unix.windsor.on.ca/ |
> | Personal Page: http://www.unixpower.org/alanp/ |
--
-------------------------------------------------------
| TBE: http://tbe.virtualave.net |
| * 3:2 Ratio + 100 Free credits! * |
| Tim's Chat Doors: http://www.connect.ab.ca/~mundy/ |
-------------------------------------------------------
------------------------------
Date: 14 Jun 1999 09:06:44 +0100
From: Jonathan Stowe <gellyfish@gellyfish.com>
Subject: Re: Ooops, my bad
Message-Id: <3764b814@newsread3.dircon.co.uk>
Tom Christiansen <tchrist@mox.perl.com> wrote:
> [courtesy cc of this posting mailed to cited author]
>
> In comp.lang.perl.misc,
> Russ Allbery <rra@stanford.edu> writes:
> :I'm not aware of any Unix that places any (practically encounterable)
> :limits on the size of a directory, apart from the performance degredation
> :on file accesses through the directory that starts setting in at around
> :10,000 files.
>
> No, Linux kicks in before then. BSD seems to stand up to it fine,
> however.
>
Last I looked /var/spool/news/comp/lang/perl/misc on my system (Linux) had
in excess of 35,000 files and I dont *notice* any great hit ...
/J\
--
"Shhh! They're strapping down Liza Minelli" - Lisa Simpson
------------------------------
Date: Mon, 14 Jun 1999 07:07:00 GMT
From: armchair@my-deja.com
Subject: Re: Perl "constructors"
Message-Id: <7k29mh$hmv$1@nnrp1.deja.com>
In article <7jon25$ld3$1@nnrp1.deja.com>,
John Porter <jdporter@min.net> wrote:
> In article <7jo353$ea4$1@nnrp1.deja.com>,
> armchair@my-deja.com wrote:
> >
> > Let's just be clear that by your
> > rediculous and meaningless definition assembler is equivalent to all
> > languages, so your "portable assembler" applies to Perl as well.
>
> No, not really. By a meaningful and useful definition of "equivalent"
> (though not by others, it seems), C and asm are equivalent, but by
> that same definition, Perl is not. As I have mentioned previously,
> C and asm both model the real machine. The object code generated
> by a C compiler is executable on a real cpu, and in fact looks very
> much like what you would write by hand, if you were writing in asm.
> Perl, on the other hand, models a abstract, "virtual" machine,
> (implemented by the perl bytecode interpreter), for which no
> assembler exists. Translation of Perl code into the machine code of
> an existing real machine is, shall we say, an extremely non-trivial
> task; some people are working hard on it, but it's, um, not ready
> for prime time. Not that this should bother anyone; that's not what
> Perl was designed for. C, of course, was designed to be compiled
> directly into tight machine code -- just like assembler.
No amount of blather about object code, real machines, and virtual
machines can change the fact that we are talking about and
comparing source code.
>
> > My, someone who calls C equivalent to assembler then calls C/C++
> > if/while/for logic significantly different from Perl's due to things
> > that are "pretty subtle". Let me suggest that if you want to be
> > enlightened as to the equivalence feel free to read the Perl and the
> > C/C++ documentation. I have read them both and am quite certain that
> > should you, you will reach the proper conclusion.
>
> The differences are subtle, but significant, at least to some
> Perl programmers. If the differences aren't significant to you,
> there's not much I can say.
If only that were true.
>
> > Evidently however
> > different the "machine that Perl models", it still uses the same
> > if/while/for logic of "the machine that C models".
>
> The equivalence of the if/while/for logic of C and Perl (which I am
> not granting is the case) does not in anyway way confirm or deny the
> equivalence of C and asm, nor that Perl is a higher level language
> than C. Strange that you think it would.
The equivalence of the if/while/for logic of C and C++ was mentioned to
show a common feature with that of Perl, and to aptly demonstrate that
any comparison of C to assembler is absurd. And strangely, you are still
clinging to that thought, however tenously.
>
> > No you didn't, you gave an excellent example of why C and assembler
> > are
> > not equal or equivalent.
>
> No, I demonstrated that they are "equivalent" (and therefore
> "equal or equivalent").
You haven't demonstrated any such thing. But I will be happy to give you
another chance to do so. Give me the equivalent assembler statements for
the following C code:
int i = 0, j = 0;
for ( ; i < 10; i++)
for ( ; j < 10; j++ )
print ("i/j %d/%d\n",i,j);
>
> > But we are not talking about functional equivalence of course.
> We are
> > talking about syntactical equivalence,
>
> No, we're not talking about syntactic equivalence. That would be
> a very stupid thing to talk about. C and Pascal and identical in
> nearly every respect, yet syntactically are very different.
> Syntactic difference/equivalence is quite irrelevant.
Only to fellows who repeatedly try and argue that assembler is
equivalent to C. And we are talking about syntactic
equivalence/equality. By the way, syntactic equality would be if the
syntax of statements were virtually identical between languages, as in
if/while/for in C and Perl. Syntactic equivalence would be where the
languages have different syntax but that it is used in the same manner
or way as that of another language (as in Pascal is often sytactically
equivalent to C).
>
> > > > Again you have proven Assembler to not be the equivalent of C.
> > >
> > > No, I've shown they're equivalent, though not identical.
> >
> > Nope, not equivalent, not identical, not the same, not even related,
>
> Equivalent in every respect except syntactically -- which, of course,
> is neither here nor there.
I would have to agree, your attempt to argue that C and assembler are
equivalent is neither here, nor there. It's out there man.
>
> > > > I give you credit for being
> > > > big enough to disprove you own case.
>
> I did not "disprove my own case", and I don't need your credit for
> that or anything else I've done.
You have admitted repeatedly that it takes more lines of assembler to
equal C, and have on several occasions demonstrated that assembler code
is much more tedious than C. Allow me to give you credit for something.
>
> > You will have to come up with your definition of equivalent.
> > One that
> > will say that using C is equivalent to using assembler, although not
> > as
> > good, or as easy. Good luck.
>
> Nope, I'm not out to show that "using C is equivalent to using asm".
> I'm talking about the design of the languages themselves, primarily
> the semantics. Too much of the usability of a language is dependent
> on other things, like the availability and quality of development
> tools.
Ah, finally an admission that C is not equivalent to assembler. It took
you a while but we finally made it.
>
> > Give me the assembler code for this C code or put in terms that
> > may make
> > it easier for you, given this machine code model in C, show me how
> > the
> > assember "machine code model" is equivalent. As always, good luck.
>
> I won't waste my time writing assembly code for you.
> If you want the asm equivalent of this code, run it through your
> compiler with the "generate asm" option.
> I feel confident that you will not be convinced of the equivalence of
> the code, regardless of who or what does the translation.
Since we are talking about source code, looking at anything else would
be irrelevant. But you knew that.
>
> > Show me how this C code is not
> > more powerful than the equivalent assembler code by showing me the
> > equivalent assembler code...
>
> Ridiculous.
Certainly was, and yet you repeatedly contended assembler was equivalent
to C.
>
> > Uh oh, his is where old equivalence shows its capricious side, isn't
> > it.
> > While C and Assembler are equivalent because although syntactically
> > different, the code can do the same thing, a string in C++ is not
> > equivalent to a string in Perl, because although syntactically
> > similar,
> > they are implemented differently under the covers.
>
> More or less. But presumably one could write a C++ string class
> that would work very much like a Perl string. (That would be
> nice, I think.)
Before someone could right a C++ string class that "behaved like a Perl
string", you would have to come up with some differences in behaviour.
>
> > > > Were [classes] implemented in complex ways?
>
> I have enough faith in Bjarne's abilities to assume that the
> implementation of classes in C++ is no more complex that it has
> to be. And that, of course, is quite complex, by almost any
> standard.
Why don't you demonstrate how the creation of a class is so much more
complex in C++ than it is in Perl. As always, good luck.
>
> > We are only discussing language syntax here, not writing
> > compilers,
>
> No wonder we're arguing: we're talking about two different things.
We started out talking about the same thing. After I posted about 5 to
10 requests for the assembler equivalent to a C nested for loop one of
us began talking about "real machines" and "virtual machines".
> > > > Regarding this "portable assembler concept, would you be so
> > > > kind as to
> > > > give the assembly equivalent of the following C code:
> > >
> > > Look at the asm output of your C compiler.
> >
> > Okay, I did, and it's not equivalent to the C code.
>
> It is, you're just not seeing (or admitting) the equivalence.
It tisn't, you're just not seeing (or admitting) the equivalence.
>
> > The number lines is certainly relevant. That is one of the
> > metrics by
> > which we would test to see if the source code of one language
> > is like
> > that of another.
>
> Sure, but the results of that test say nothing about the equivalence
> of the two languages.
As a matter of fact they say a lot.
>
> > implying through your inability to
> > even give the requested sample code,
>
> Not unable, just unwilling. I have real work to do.
Unable. End of story.
>
> > > The complexity of the compiler is utterly dependent on the
> > > complexity
> > > of the language semantics. But I thought you knew that.
> >
> > But we are not discussing compiler design, but language sytax, so
> > the
> > complexity of the compiler is irrelevant.
>
> No, we are discussing language complexity, and that means grammar
> and semantics complexity, both of which are realized in the
> complexity of the compiler.
Nope, we are discussing language syntax. Nothing more, nothing less.
>
> > > A language is not just syntax. Even so, the syntax of C++ is an
> > > awful lot more complex than C. Compare the grammars.
> >
> > Yes, in our discussion a language is just syntax.
>
> I disagree. And C++ is more complex than C -- by a wide margin --
> by just about any measure you care to try. Even if you only
> wish to compare their syntax, you can see that C++ is far more
> complex than C. Unfortunate but true.
If you find anything unfortunate about C++ specific syntax, just write C
code. It handles it just fine.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
Date: Mon, 14 Jun 1999 07:19:36 GMT
From: armchair@my-deja.com
Subject: Re: Perl "constructors"
Message-Id: <7k2ae3$hsj$1@nnrp1.deja.com>
In article <7jltld$ksi$1@nnrp1.deja.com>,
John Porter <jdporter@min.net> wrote:
> In article <7jl9d5$e9k$1@nnrp1.deja.com>,
> armchair@my-deja.com wrote:
> > In article <7jjnr3$sn3$1@nnrp1.deja.com>,
> > John Porter <jdporter@min.net> wrote:
> > > In article <7jilf3$fr5$1@nnrp1.deja.com>,
> > > armchair@my-deja.com wrote:
> > > > Do elaborate on what you see as the major difference.
> > >
> > > I'll refer you to the standard Perl documentation.
> >
> > What pages of the standard Perl documentation, in your opinion,
> > best demonstrate it's higher level language status versus C++?
>
> Most of them. It would probably be more useful for me to tell
> which ones to skip. But the point is, when you know Perl, you
> know how it's qualitatively different from low-level languages
> and their object-oriented derivatives. I would encourage you
> and anyone else to learn Perl and experience this enlightenment
> for themselves.
You are starting to sound like an evangelist, my only concern is that
you do not consider Perl just a programming language. I will pass the
word though, that per John Porter, C++ is just object oriented portable
assembler.
>
> > Is it me or does Perl seem to be getting lower level?
>
> All those things are necessary in low-level languages, to compensate
> for lacking the power found in high-level languages. So, it's you.
I see, to you power comes in the form of a lack of compile time error
checking.
>
> > > Everything I've said about Perl being a HLL is still relevant,
> > > even if you only take in the context of comparison to C++.
> >
> > But you haven't made a case for Perl being a higher level
> > language by
> > discussing features.
>
> Sorry if what I said went over your head. I keep forgetting that
> not all my colleagues are computer science graduates.
I will be happy to summarize what you said, and feel free to point out
where you discuss Perl features:
"C is merely portable assembler".
"C/C++ are low-level and Perl is high-level. In what way is it higher
level? Why just read the manual and seek enlightenment".
"Anything in C++ that is not in Perl is just a result of the fact that
C++ is object oriented extentions to a low-level language".
>
> > ... along with trying to
> > downgrade C++ by claiming that you can do the same in Assembly,
>
> Does your C++ compiler have a "generate assembly" option?
> If so, then it would be possible for you to write that asm yourself
> (though who would want to). So I'm not simply "claiming"; it's fact.
Since I have repeatedly given you a chance to demonstrated the assembler
source code equivalent to a nested for loop in C, and you have been
unable to do so, I will have to assume that you realize what you are
doing, and what it is.
>
> > and
> > trying to downgrade C by calling it merely a portable version of
> > assembly language.
>
> I'm not "downgrading" anything. There's nothing despicable
> about being a low-level language. All these things have there
> strengths and their purposes.
Sure you are downgrading it. You are equating C and assembler. Even
though you are failing miserably to do so, you are doing it.
>
> > > Garbage Collection.
> > > Not that a C/C++ programmer would know what that was about.
> > >
> > With pre-canned objects, C++ programmers are starting to forget what
> > memory allocation is about.
>
> Unfortunately, most C++ programmers forget about it when they
> shouldn't. Object allocation and disposition is still a concern in
> C++. This is one of the reasons so many C++ programmers are
> switching to Java.
Object allocation and disposition are not still a concern if you are
using the STL and commercial or homegrown object libraries. They do it
for you. You instantiate - they allocate and delete.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
Date: Mon, 14 Jun 1999 07:22:18 GMT
From: armchair@my-deja.com
Subject: Re: Perl "constructors"
Message-Id: <7k2aj4$iv9$1@nnrp1.deja.com>
In article <928958797.413894@localhost>,
zenin@bawdycaste.org wrote:
> armchair@my-deja.com wrote:
> >snip<
> : What pages of the standard Perl documentation, in your opinion, best
> : demonstrate it's higher level language status versus C++?
>
> perl*
>
> Your definition of HLL seems to stem directly from total LOC.
> By this definition Perl is about as high level a language as one
> can get, typically weighing in at 1/10 to 1/20 the LOC of C/C++ for
> a given task.
Can you give an example of C++ code, and then the 1/10 equivalent Perl
code so I can better understand the difference?
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
Date: Mon, 14 Jun 1999 07:25:56 GMT
From: armchair@my-deja.com
Subject: Re: Perl "constructors"
Message-Id: <7k2apu$j29$1@nnrp1.deja.com>
In article <375f9e03.158941886@news.insnet.net>,
NukeEmUp@ThePentagon.com (David Cantrell) wrote:
> On Wed, 09 Jun 1999 08:42:15 GMT, armchair@my-deja.com said in
> response to John Porter:
>
> >> No? I believe I've done that, though admittedly not in much depth.
> >
> >If the Atlantic Ocean had that kind of depth and substance I would
> >backpack over to England.
>
> Yeah, he _did_ say "not in much depth". And please, don't try to come
> here by any other mode of transportation - we don't welcome those who
> neglect their duty to have a clue.
>
And I _did_ point out a "complete lack of depth". Or do you consider
walking on the floor of what was the Atlantic Ocean to be a sign of any
depth? And don't worry, if I make it to England, I won't be looking to
hang out with Perlies anymore than I will be looking to hang with
Moonies.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
Date: Mon, 14 Jun 1999 07:32:10 GMT
From: armchair@my-deja.com
Subject: Re: Perl "constructors"
Message-Id: <7k2b5r$j4o$1@nnrp1.deja.com>
In article <xkfg142my71.fsf@valdemar.col.hp.com>,
Eric The Read <emschwar@rmi.net> wrote:
> armchair@my-deja.com writes:
> > That is an error, absolutely. Int pointers should not point to Foo
> > classes or structs, and that pointer should not later
> > be dereferenced.
> > By the way, how did you come out on getting my code to compile.
> > I will
> > repeat it again here:
> >
> > int *a;
> > short b = 2;
> > a = &b;
>
> Compiles just fine in K&R mode. ANSI mode generates a warning:
>
> cc: "/tmp/tmp.c", line 5: warning 604: Pointers are not
assignment-compatible.
>
> But it compiles and generates a valid executable.
>
> Perhaps you should pick your examples more carefully?
Doesn't compile at all on my machine.
% CC -o test_p test_p.C
test_p.C: In function `int main(...)':
test_p.C:9: assignment to `int *' from `short int *'
Perhaps you could change it to /tmp/tmp.C and compile it with CC and not
cc as we were discussing C++ not C.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
Date: Mon, 14 Jun 1999 07:44:44 GMT
From: armchair@my-deja.com
Subject: Re: Perl "constructors"
Message-Id: <7k2btb$jad$1@nnrp1.deja.com>
In article <7jjp3c$t9i$1@nnrp1.deja.com>,
John Porter <jdporter@min.net> wrote:
> In article <7jimlo$g69$1@nnrp1.deja.com>,
> armchair@my-deja.com wrote:
> > In article <7jgi09$noj$1@nnrp1.deja.com>,
> > John Porter <jdporter@min.net> wrote:
> > > In article <7il85o$t0u$1@nnrp1.deja.com>,
> > > armchair@my-deja.com wrote:
> > > > my $variable.
> > > > This is not the same as C++ syntax.
> > >
> > > Obviously. I never said it was.
> >
> > Well, with your creative editing, you deleted what you said as
> > well, so
> > presumably you agree you were wrong as well.
>
> No doubt you will make such presumptions; but the entire transcript
> of our discussion is available for all to see. That you would
> complain that "my $var" is not C++ syntax, indicates to me that
> you weren't following the argument very attentively.
I will be happy to repost the applicable comments "for all to see", and
encourage you to pay attention when you read it:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> Variables in Perl (scalars, arrays, hashes) are, under the hood,
> pointers to data structures; but the language "sugar-coats" the use
> of these pointers. So your objection here is null. I was trying to
> show how Perl works using C++ syntax. I should perhaps have used
> references, rather than pointers, to make my point, since that is
> C++'s equivalent sugar-coating.
Scalar variables in Perl (numbers, strings, references to
(numbers,strings,hashes,arrays,objects)) are all identified the same.
my $variable.
This is not the same as C++ syntax. Nor is is that same as what takes
place under the hood.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>
> > > But you're telling me that
> > > Foo x;
> > > int* p = (int*) &x;
> > > int i = *p;
> > > is an error. That's news to me.
> >
> > That is an error, absolutely.
>
> As it happens, it is not an error; absolutely not.
> If you think it is, then you misunderstand the purpose and effect
> of typecasting. I got the above code to compile and run without
> so much as a warning.
It is an error. You would not want to assign Foo addresses to ints. You
would assign them to Foo pointers. Just because you can cast something
into compiling does not mean that you are making an error, as you have
aptly demonstrated.
>
> > Int pointers should not point to Foo
> > classes or structs, and that pointer should not
> > later be dereferenced.
>
> "Should not" does not an error make.
> The compiler assumed I knew what I really wanted to do.
And you were in error. So the syntax you gave was incorrect code.
>
> > int *a;
> > short b = 2;
> > a = &b;
>
> I got a warning about incompatible pointer types; but no errors;
> and the code ran fine. This power is C's two-edged sword.
You made the same mistake as another fellow, you compiled it as C code.
Try C++. Let me know what you find out.
>
> > > It's not in the core. Read perldoc overload if you're interested.
> >
> > Tell me
> > about what is in the Perl core my good man, not what someone has
> > coaxed
> > it into doing with unknown success.
>
> Trace back through this thread and see why we were talking about
> overloading in Perl in the first place. It was quite incidental
> to the argument.
I only need to trace back to you saying we can't talk about things added
on to C++ that are not in the core language. You were cut with your own
"double edged sword".
>
> So if you're not interested in overloading in Perl, then by all
> means, feel free not to read perldoc overload.
This doesn't change the fact that you consider perl modules a part of
Perl, and the Standard Template Library not a part of C++. Maybe your
should try perldoc inconsistency.
>
> > > It's simply a higher degree of abstraction.
> > > Some programmers see this as a feature.
> >
> > It's simply a higher degree of uncertainty.
>
> With abstraction comes some uncertainty (for the human, at least).
> Most professional programmers feel that the benefits of abstraction
> far outweigh the potential down-side of "uncertainty".
> I guess it's time I faced the fact that not all programmers are
> comfortable with abstraction.
I would gather there are quite a few Perl programmers not using objects,
but you are very correct in pointing out that they should not fear any
abstraction caused by the use of objects, as the Perl scalar declaration
itself already has them swimming in abstraction to begin with.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
Date: Sun, 13 Jun 1999 23:06:12 -0700
From: lr@hpl.hp.com (Larry Rosler)
Subject: Re: simple math question! Why doesn't the * multiply two numbers?
Message-Id: <MPG.11ce3b9563c7643e989bdc@nntp.hpl.hp.com>
[Posted and a courtesy copy sent.]
In article <37645E58.F740879A@earthling.net> on Sun, 13 Jun 1999
21:43:53 -0400, Ryan T. Rhea <ryan420@earthling.net> says...
> I have written the following script in perl. Everything works except
> the multiplication. What's going on?
>
> #!/usr/bin/perl
Put ' -w' on the line above.
> #
> # simple command line calculator
> # Copyright 1999 by Ryan T. Rhea
> $num1 = @ARGV[0];
> $oper = @ARGV[1];
> $num2 = @ARGV[2];
The '-w' will warn you that the three lines above are incorrect (though
they happen to do what you want).
...
> if ($oper eq "*")
> {
> print $num1 * $num2; print "\n";
> }
As this code is as correct as the others, obviously the program isn't
seeing a '*' as the argument. Why didn't you try to debug the program
yourself with print statements, instead of posting here?
The shell (command interpreter) is expanding it into a list of file
names. Try escaping it ('\*'). You should have found this for yourself
by printing the actual arguments the program received, instead of being
so helpless.
--
(Just Another Larry) Rosler
Hewlett-Packard Company
http://www.hpl.hp.com/personal/Larry_Rosler/
lr@hpl.hp.com
------------------------------
Date: Sun, 13 Jun 1999 23:45:18 -0700
From: Tom Phoenix <rootbeer@redcat.com>
Subject: Re: simple math question! Why doesn't the * multiply two numbers?
Message-Id: <Pine.GSO.4.02A.9906132342580.6999-100000@user2.teleport.com>
On Sun, 13 Jun 1999, Ryan T. Rhea wrote:
> I have written the following script in perl. Everything works except
> the multiplication. What's going on?
You're not using your shell properly. The asterisk is a shell
metacharacter. Check the arguments you're passing to your program by
giving the same args to echo and I think you'll find what I mean. See your
shell's manpage for more information. Cheers!
--
Tom Phoenix Perl Training and Hacking Esperanto
Randal Schwartz Case: http://www.rahul.net/jeffrey/ovs/
------------------------------
Date: 12 Dec 98 21:33:47 GMT (Last modified)
From: Perl-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Special: Digest Administrivia (Last modified: 12 Dec 98)
Message-Id: <null>
Administrivia:
Well, after 6 months, here's the answer to the quiz: what do we do about
comp.lang.perl.moderated. Answer: nothing.
]From: Russ Allbery <rra@stanford.edu>
]Date: 21 Sep 1998 19:53:43 -0700
]Subject: comp.lang.perl.moderated available via e-mail
]
]It is possible to subscribe to comp.lang.perl.moderated as a mailing list.
]To do so, send mail to majordomo@eyrie.org with "subscribe clpm" in the
]body. Majordomo will then send you instructions on how to confirm your
]subscription. This is provided as a general service for those people who
]cannot receive the newsgroup for whatever reason or who just prefer to
]receive messages via e-mail.
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.misc (and this Digest), send your
article to perl-users@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.
The Meta-FAQ, an article containing information about the FAQ, is
available by requesting "send perl-users meta-faq". The real FAQ, as it
appeared last in the newsgroup, can be retrieved with the request "send
perl-users FAQ". Due to their sizes, neither the Meta-FAQ nor the FAQ
are included in the digest.
The "mini-FAQ", which is an updated version of the Meta-FAQ, is
available by requesting "send perl-users mini-faq". It appears twice
weekly in the group, but is not distributed in the digest.
For other requests pertaining to the digest, send mail to
perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
sending perl questions to the -request address, I don't have time to
answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V8 Issue 5983
**************************************
