On 10/18/2013 11:00 PM, Miles Fidelman wrote:
Jerry Stuckle wrote:On 10/18/2013 6:11 PM, Miles Fidelman wrote:Jerry Stuckle wrote:On 10/18/2013 11:48 AM, Miles Fidelman wrote:Jerry Stuckle wrote: In the REAL world, program behavior is very much driven by the properties of underlying hardware. And... when actually packaging code for compilation and/or installation - you need to know a lot about what tests to run, and what compile/link switches to set based on the characteristics of the build and run-time environments.Only if you're distributing source code. Look at the number of programs out there which DON'T have source code available. Outside of the Linux environment, there is very little source code available (other than scripting languages, of course). And even in Debian, most of the packages you get are binaries; sure, you can get the source code and compile it yourself - but it's not necessary to do so.In which case the installers/packages take machine dependencies into account. A package may be cross platform, but you download and install a DIFFERENT package for Windows, Macintosh, Solaris, AIX, various flavors of Linux (or you have an install CD that has enough smarts to detect its environment and install appropriately).Ok, please tell me - if the program is hardware dependent, how does an installer change the machine code to support different hardware? I don't argue that the same program requires recompilation for different OS's, but that's not what we've been talking about. The discussion is how the code can work on different hardware.What? Are you kidding me? What do you think package managers do when they reconcile dependencies, and load additional packages - dynamically linked libraries, kernel modules, and so forth - to put all the pieces in place that are necessary for a particular application package to run in a particular environment? And there's also the matter of setting up configuration files based on the specific run-time environment.
You still haven't told me how I can load exactly the same binaries on different machines with different hardware, and make them work. After all, it is you who claimed the code was dependent on hardware configuration.
Please explain in detail.
No, it is completely dependent on the compiler being used, as noted above.Bulltwaddle. It also depends on the linker, the libraries, compile-time switches, and lots of other things. Given what you have to say, I sure as hell wouldn't hire anybody who's learned programming from one of your classes.All of which depends on the compiler. Compile-time switches are dependent on the compiler. So are the libraries supplied with the compiler. And the linker only has to worry about pointers and such; it doesn't care if you're running 16, 32 or even 128 bit integers, for instance. You can take a COBOL compiler and libraries, develop a program with 100 digit packed decimal numbers. The linker doesn't care. The OS libraries don't care. The only thing outside of the compiler which does matter is the libraries supplied with the compiler itself.And as soon as you write something that does any i/o you get into all kinds of issues regarding install time dependencies, dynamic linking to various kernel modules and drivers, etc., etc., etc.Not at all. As I said above - your claim has been different HARDWARE requires different compilation options. Not different OS's. Please don't try to change the subject.Huh? Of course different hardware requires different compilation options - starting with the option specifying the target CPU architecture.
Nope. When I'm compiling for X86 on an X86 machine, I use a set of options. When I'm compiling the same program for ARM on an ARM machine, I use exactly the same set of compiler options.
You obviously have never done anything other than X86 programming.
And if my teaching is so bad, why have my customers (mostly Fortune 500 companies) kept calling me back? Maybe because my students come out of the class knowledgeable and productive? And my customers (mostly Fortune 500 companies) keep calling me back because the programmers I train are productive.Kind of hard to vet that. You're JDS Computer Training Corp., right? Now web site, no mention in any journals - pretty much all the Google shows is a bunch of business listings on sites that auto-scrape business registration databases. And when I search on Jerry Stuckle, all I find are a LinkedIn page that lists you as President of SmarTech Homes since 2003, which in turn has a 1-page, relatively content-free web site talking about the benefits of homes with simple automation systems. Pretty vaporous.No public website, no. And no, I don't have to advertise in journals. It's too expensive and I don't need it. As for the SmarTech homes - that's something I've played around with a bit - but that's really all. It's why you don't see much on the website. And my LinkedIn profile has nothing to do with my training. Not at all vaporous. But then when all else fails, trolls have to try to attack the messenger because they can't refute the facts. (They also try to change the subject).No. I'm just asking you to back up your claim that Fortune 500 customers keep calling you back.
No, you're the one who started the attacks. I don't have to back up ANYTHING to trolls.
But now it's time to <plonk> the troll. Jerry