"I consider myself a fairly skilled programmer..."
-
Check out this posting. Amusing. http://cboard.cprogramming.com/cplusplus-programming/102155-any-cool-programming-project-ideas.html[^] and I quote... I guess I should mention, all of my programs have all of their code in one source code file, usually no more than 10 pages. I don't really know how to tell the compiler to compile multiple source code files that are supposed to form one program. I consider myself a fairly skilled programmer, in that I can write programs to solve complicated mathematical or scientific problems, or run cool simulations, like a basic 2D flight simulator (with VERY basic graphics, but very accurate flight modeling) or whatever. But these are usually short (<10 pages), one-source-code-file programs. I am kind of lost working on "big" projects like this. Unfortunately, most of the open source software I use, like OpenOffice, or Dev-C++, etc, are "big" (hundreds of pages of code, many source files, etc) and I wouldnt know where to start as far as adding a feature or fixing a bug. I know C++ very well, ie, how to use classes, pointers, inheritance, structures, loops, and pretty much all of the language features of C++, but I dont know how to work with "big" projects that use multiple source code files, libraries, data files, graphics resources, etc.
Everything makes sense in someone's mind
that Maunder's CV you're reading again? *grin* Bryce
MCAD --- To paraphrase Fred Dagg - the views expressed in this post are bloody good ones. --
Our kids books :The Snot Goblin, and Book 2 - the Snotgoblin and Fluff The Snotgoblin for the Ipad -
at least you were "thinking outside the box" :thumbsup:
Steve _________________ I C(++) therefore I am
Only because I couldn't find the appropriate box.
-
Did you link to the wrong post? When I click the link, I'm taken to a post over three years old in which someone is asking for programming ideas.
-
My first program, written on the Timex Sinclair, was printed out on "cash register" paper. I measured it in feet...
-
My first program, written on the Timex Sinclair, was printed out on "cash register" paper. I measured it in feet...
-
Check out this posting. Amusing. http://cboard.cprogramming.com/cplusplus-programming/102155-any-cool-programming-project-ideas.html[^] and I quote... I guess I should mention, all of my programs have all of their code in one source code file, usually no more than 10 pages. I don't really know how to tell the compiler to compile multiple source code files that are supposed to form one program. I consider myself a fairly skilled programmer, in that I can write programs to solve complicated mathematical or scientific problems, or run cool simulations, like a basic 2D flight simulator (with VERY basic graphics, but very accurate flight modeling) or whatever. But these are usually short (<10 pages), one-source-code-file programs. I am kind of lost working on "big" projects like this. Unfortunately, most of the open source software I use, like OpenOffice, or Dev-C++, etc, are "big" (hundreds of pages of code, many source files, etc) and I wouldnt know where to start as far as adding a feature or fixing a bug. I know C++ very well, ie, how to use classes, pointers, inheritance, structures, loops, and pretty much all of the language features of C++, but I dont know how to work with "big" projects that use multiple source code files, libraries, data files, graphics resources, etc.
Everything makes sense in someone's mind
If you cannot do things in C++ that virtually every C++ programmer can do, then your claim to be skilled is suspect. If you cannot learn to do new things, then your claim to be a skilled programmer is suspect. The entire point of object oriented programming is to break up a big problem into a series of small problems that can be solved in a few pages. If you have not grasped this fact, then your claim to have any skill whatsoever in C++ is suspect. It's entirely possible that you are using a C++ compiler, but your programs are more like C programs, or assembler. What is it you lost between the time you learned to program and today, so that you cannot learn to do separate compilation? Go find that thing, and get it back. Then learn to compile multiple files. It's not that hard. In fact, any other C++ programmer should be able to explain it o you in five minutes. Perhaps you don't know any other programmers. Then you have no basis on which to compare your skill. Perhaps you're missing very basic concepts like what a compiler, linker, and loader does. If so your claim to skill is maybe not supported by any factual data at all.
-
Also be sure to use double spacing to increase productivity 200%.
-
My first program, written on the Timex Sinclair, was printed out on "cash register" paper. I measured it in feet...
My first programs were input using punch cards, so I measured the deck thickness in inches. lol.
-
Back in the day when mainframes roamed the planet and ate punch cards, we used to measure code size by inches...thick. When I went to work at the headquarters of a major railroad, the largest program written had been 3-1/2" thick. I blew their minds when the first S/370 assembler program I wrote was 1-1/2 cartons long. They thought I was writing a compiler or something. I was writing a universal database editor (when databases were flat files and I'd go to calculator club meeting and there was this old gentleman raving about this new thing called "Sequel") so I'd never have to write another. It was mostly macro generated, it allowed multiple commands that did the same thing (edit, change, modify), columns were not fixed for data,...it was beautiful.
Psychosis at 10 Film at 11
-
Check out this posting. Amusing. http://cboard.cprogramming.com/cplusplus-programming/102155-any-cool-programming-project-ideas.html[^] and I quote... I guess I should mention, all of my programs have all of their code in one source code file, usually no more than 10 pages. I don't really know how to tell the compiler to compile multiple source code files that are supposed to form one program. I consider myself a fairly skilled programmer, in that I can write programs to solve complicated mathematical or scientific problems, or run cool simulations, like a basic 2D flight simulator (with VERY basic graphics, but very accurate flight modeling) or whatever. But these are usually short (<10 pages), one-source-code-file programs. I am kind of lost working on "big" projects like this. Unfortunately, most of the open source software I use, like OpenOffice, or Dev-C++, etc, are "big" (hundreds of pages of code, many source files, etc) and I wouldnt know where to start as far as adding a feature or fixing a bug. I know C++ very well, ie, how to use classes, pointers, inheritance, structures, loops, and pretty much all of the language features of C++, but I dont know how to work with "big" projects that use multiple source code files, libraries, data files, graphics resources, etc.
Everything makes sense in someone's mind
-
Not really. That used to be quite common back in the old Unix C days, and there were lots of highly skilled devs back then.
Forgive your enemies - it messes with their heads
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
Unfortunately true. Back in the day, some compilers and assemblers could only handle one compiler and there was no linker. Everything had to be defined in a single file. I remember working on an embedded 6802 assembly project that had a single source file that was over 1 million lines long. It was difficult to maneuver within that file. When we decided to print it out (on a dot matrix printer), we would use almost a whole ream of paper. It would take almost 3/4 of a day to print out. Also, by the end of the file, the ink would start to run out. Yes, long file are no fun. But, in those days, there were constraints.
-
Back in the day when mainframes roamed the planet and ate punch cards, we used to measure code size by inches...thick. When I went to work at the headquarters of a major railroad, the largest program written had been 3-1/2" thick. I blew their minds when the first S/370 assembler program I wrote was 1-1/2 cartons long. They thought I was writing a compiler or something. I was writing a universal database editor (when databases were flat files and I'd go to calculator club meeting and there was this old gentleman raving about this new thing called "Sequel") so I'd never have to write another. It was mostly macro generated, it allowed multiple commands that did the same thing (edit, change, modify), columns were not fixed for data,...it was beautiful.
Psychosis at 10 Film at 11
Wow, 3-1/2 inch! Best I got was about 2 inches, or a bit less (never measured it, this is just a guesstimate from memory). But then, it was just university assignments, and even for those I eventually switched to a terminal after getting hold of an unlimited terminal password (which was in fact only meant for use in an OS course I visited over the summer holidays). I have to say, though , that I was known to produce very compact solutions. more a matter of practicality than anything else, because the typewriter ribbon in our punch card writers were never replaced, and so we could never read our punch cards to check for errors... (it also meant that dropping the stack forced us to 'rewrite' the entire program, as sorting them was impossible without readable line numbers). I also on one occasion managed to 'blow their mind', when I expanded a programming task to build a min-max tree for a simple game into a full-blown game program, complete with a printout of the board after each move. I think that was the first (and last) time where the printout was in fact larger than the stack of program cards would have been, hadn't I used a terminal instead ;)
-
Wow, 3-1/2 inch! Best I got was about 2 inches, or a bit less (never measured it, this is just a guesstimate from memory). But then, it was just university assignments, and even for those I eventually switched to a terminal after getting hold of an unlimited terminal password (which was in fact only meant for use in an OS course I visited over the summer holidays). I have to say, though , that I was known to produce very compact solutions. more a matter of practicality than anything else, because the typewriter ribbon in our punch card writers were never replaced, and so we could never read our punch cards to check for errors... (it also meant that dropping the stack forced us to 'rewrite' the entire program, as sorting them was impossible without readable line numbers). I also on one occasion managed to 'blow their mind', when I expanded a programming task to build a min-max tree for a simple game into a full-blown game program, complete with a printout of the board after each move. I think that was the first (and last) time where the printout was in fact larger than the stack of program cards would have been, hadn't I used a terminal instead ;)
I might have been generous in saying 3 1/2", might have been less. Those guys were operating without a clue. Whereas my program was around 3000 lines long. I was trying to eliminate fixed columns for input and created something akin to PL/C's stream input. I also macro generated PL/C's ByName function to copy fields from one structure to another. The problem was that I was using S/370's DOS Assembler, which wouldn't allow strings larger than 8 characters. However you could make a Macro call and pass up to 255 characters. So I created a recursive Macro call that peeled apart the fieldname strings and reassembled a target string. I also used to blow their minds by using symbolic names instead of hardcoded register numbers. My program was intended to replace their usual database maintenance where they used to punch out the entire database to cards, interpret them, and then find and edit (repunch) the particular field in the particular record and then reload the entire database from those cards. This database was 300 characters wide so a record spanned several cards and some fields were only 1 character wide. I figured their probability of error was greater than their probability of a successful edit. So my program was intended to do an inplace replacement of the data. And I had to implement Create/Update/Delete against fields and records. It was a very fun program to write since it required so much. And with the intention that for other flatfile databases they would later throw at me, all I'd have to do is change the field declarations at the beginning (Macro generated) and write the custom fields, and I'd be done in short order. Typical programmer behavior: Work hard so you wouldn't have to later.
Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon it.