C or C++

bruce woller brucewoller at comcast.net
Mon Oct 18 18:43:34 MDT 2004


Eric:
Try placing your declarations before your opening brace i.e.
> int c; int d=50; unsigned short Age; int e;
> main (){
> cout << Age << ", " << e << '\n';}
and see what you get.  Then read up on the difference between an 
uninitialized variable on the stack and one in BSS.

Have fun!
ps I'm surprised the compiler didn't yell at you for using an 
uninitialized variable try
gcc -Wall problem.cpp -o prob
On Oct 18, 2004, at 6:07 PM, Eric Dunbar wrote:

> I'm working my way through an on-line tutorial
> (<http://www.cplusplus.com/doc/tutorial/>), am also reading bits and
> bobs of the "Thinking in C" book (free, on-line, very easy read), will
> be living the student life (which I sorely miss... the mental
> stimulation of the working world just isn't the same) vicariously by
> snooping on Stefan's website, and I'm sure I'll find other things to
> learn off!
>
> In creating my first basic apps & have discovered a quirk with the g++
> compiler in YDL (gcc 3.2.2). If I compile the following (g++
> problem.cpp -o prob) (plus, it bitches about deprecated/antiquated
> headers in iostream.h):
>
> #include <iostream.h>
> main (){
> int c; int d=50; unsigned short Age; int e;
> cout << Age << ", " << e << '\n';}
>
> This is output:
> 32767, 268437604
>
> If I add:
> int a, b;
> before
> int c;
> I get:
> 0, 0
>
> I also manged to get Age to show up with 4068 at one point. Why does
> the default value for a newly defined variable change depending on the
> definition of another variable? Does this mean you cannot assume 0 as
> the default value?
>
> Anyhow, time for some more fun...
> Eric.
>
> On Mon, 18 Oct 2004 11:14:21 -0700, Longman, Bill 
> <longman at sharplabs.com> wrote:
>>> The site aside, I really believe that learning a programming language
>>> (especially a complex one like C++) is best done through books and
>>> practice.  Practice by itself does not solve anything though, you may
>>> learn to do C++ programs this way, but you will likely learn to do 
>>> bad
>>> programs if you don't teach yourself the good programming practice
>>> first (hence the requirement of a good book).  But then maybe this is
>>> only the opinion of a prof who works in formal methods and has some
>>> interest in programing languages...
>>
>> In my practical experience, I've found it, *hands down*, most 
>> fruitful to
>> work alongside a good programmer. You need an understanding of the 
>> language
>> syntax, obviously, but once you master that, it's the semantics that 
>> throws
>> you. That's when a helpful nudge in the right direction can help open 
>> your
>> eyes. "Oh, that's the way you do that!" I programmed in 4GLs for 
>> years and
>> *always* had the language book at my side. It takes a while to get 
>> familiar
>> with the libraries and by far the fastest I was ever able to get up 
>> to speed
>> was when I had my book nearby and I had a good chunk of existing code 
>> handy
>> in order to stare and compare with.
>>
>> When you don't have a programmer nearby, you have to find good code 
>> on your
>> own. Luckily, you've got an entire hard disk full of it (or at least 
>> could
>> have) on your Linux box. And if it isn't there, there's surely plenty 
>> of
>> great code at Sourceforge or Freshmeat.
>>
>>
>> _______________________________________________
>> yellowdog-general mailing list
>> yellowdog-general at lists.terrasoftsolutions.com
>> http://lists.terrasoftsolutions.com/mailman/listinfo/yellowdog-general
>> HINT: to Google archives, try  '<keywords> 
>> site:terrasoftsolutions.com'
>>
>
>
> -- 
> Sincerely, Eric Dunbar
> _______________________________________________
> yellowdog-general mailing list
> yellowdog-general at lists.terrasoftsolutions.com
> http://lists.terrasoftsolutions.com/mailman/listinfo/yellowdog-general
> HINT: to Google archives, try  '<keywords> site:terrasoftsolutions.com'
>



More information about the yellowdog-general mailing list