|
Thread Rules
1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution.
2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20)
3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible.
4. Use [code] tags to format code blocks. |
On March 19 2013 07:21 CecilSunkure wrote:You should look up inheritance and polymorphism, along with pointers and typecasting. If you know these then you can see A is treated as a base for other derived cases. The derived cases override a base function being called from A base pointers.
B doesn't override f, it overloads it. B's f will not be called.
|
Poland794 Posts
On March 19 2013 05:36 CecilSunkure wrote:Show nested quote +On March 19 2013 05:26 Ilintar wrote:
Agreed - coding OOP in C is like coding lambda abstractions in Java - might be fun or useful as an exercise, but in both cases there are simply languages better suited for the job. OOP in C was actually the language of choice for a lot of GBA games. But again the point isn't to learn it professionally, but just to have a solid understanding of how what you're using in C++ works. Using function pointers and typecasting in C for OOP isn't as difficult or tedious as you guys seem to think it is. On a different topic, if I could I'd code everything in C instead of C++. I really like C. It's just that templating in C++ is so useful, and there are some very nice C++11 features coming around. Whenever someone codes something in C it's almost always completely obvious as to what they are trying to do. With C++ though there are a lot of ways to hide a lot of things. Auto-generated code, things can be run in non-intuitive ways. It's a big problem when a poor C++ programmer is writing code within a team. Of course the solution isn't "lets all code in C", it's just to use C++ appropriately. Even at my school though it's hard to find solid programmers to work with. I can't imagine how hard it would be to find a fit for a team that works primarily with C++ out in the world. Perhaps if more people started "hitting the ground running" in C things would be different?
The problem is, miniscule optimization gains that you get by coding stuff in C over C++ (miniscule because both langauges are compiled, native languages, so the code will compile to basically the same assembly with a proper compiler, minus vtables and OOP-specific stuff, plus the C++ compiler can optimize a lot of OOP code that the C compiler cannot) is lost by programmer hours. C++ has type-checking for all sorts of OOP stuff that C does not - by definition, if you typecast pointers, you are basically telling the compiler "I know what I'm doing, I told you before that this was stuff of type Foo, but it's really stuff of type Bar". So the compiler will basically tell you "okay, but don't complain later when you get a segfault since you reference a non-existing function poiner". The issue here is, pointer arithmetic is notoriously hard to debug and takes away tons of valuable programmer time. Agreed - there are times when you need to do OOP-style programming in C and Linux kernel drivers are a fine example, but then again, most people don't program Linux kernel drivers. In normal, user-land applications, there is really not reason nowadays to use C over C++ if you want to do OOP.
|
On March 19 2013 07:37 Ilintar wrote:Show nested quote +On March 19 2013 05:36 CecilSunkure wrote:On March 19 2013 05:26 Ilintar wrote:
Agreed - coding OOP in C is like coding lambda abstractions in Java - might be fun or useful as an exercise, but in both cases there are simply languages better suited for the job. OOP in C was actually the language of choice for a lot of GBA games. But again the point isn't to learn it professionally, but just to have a solid understanding of how what you're using in C++ works. Using function pointers and typecasting in C for OOP isn't as difficult or tedious as you guys seem to think it is. On a different topic, if I could I'd code everything in C instead of C++. I really like C. It's just that templating in C++ is so useful, and there are some very nice C++11 features coming around. Whenever someone codes something in C it's almost always completely obvious as to what they are trying to do. With C++ though there are a lot of ways to hide a lot of things. Auto-generated code, things can be run in non-intuitive ways. It's a big problem when a poor C++ programmer is writing code within a team. Of course the solution isn't "lets all code in C", it's just to use C++ appropriately. Even at my school though it's hard to find solid programmers to work with. I can't imagine how hard it would be to find a fit for a team that works primarily with C++ out in the world. Perhaps if more people started "hitting the ground running" in C things would be different? The problem is, miniscule optimization gains that you get by coding stuff in C over C++ (miniscule because both langauges are compiled, native languages, so the code will compile to basically the same assembly with a proper compiler, minus vtables and OOP-specific stuff, plus the C++ compiler can optimize a lot of OOP code that the C compiler cannot) is lost by programmer hours. C++ has type-checking for all sorts of OOP stuff that C does not - by definition, if you typecast pointers, you are basically telling the compiler "I know what I'm doing, I told you before that this was stuff of type Foo, but it's really stuff of type Bar". So the compiler will basically tell you "okay, but don't complain later when you get a segfault since you reference a non-existing function poiner". The issue here is, pointer arithmetic is notoriously hard to debug and takes away tons of valuable programmer time. Agreed - there are times when you need to do OOP-style programming in C and Linux kernel drivers are a fine example, but then again, most people don't program Linux kernel drivers. In normal, user-land applications, there is really not reason nowadays to use C over C++ if you want to do OOP.
I really don't want to get back into this age-old Language A vs Language B argument, so let's just say that each has their benefits and drawbacks, and a good programmer should be able to choose the best language to fit the problem.
What actually is worth discussing is the implementation specific differences between C and C++, and why you would use one over the other. Please don't take this as an assault at you, or at C++, I am just trying to clear up a few misconceptions before others read them and take them for truth.
Misconception A: C++ is as fast as C, because they are both static typed compiled languages
+ Show Spoiler +Currently, there is a phenomenon known as the "C++ tax", which is, in effect, the overhead in using C++ over C to implement a data structure or algorithm. It isn't much, but it's there, and in plenty of applications, that is enough to warrant using C. Simple examples will compile to roughly the same assembly, but if you use templates or make excessive use of inheritance, then the overhead of C++ goes through the roof. You'll note that those are two of the biggest "advantages" C++ has to C as far as OOP goes. They are also the biggest performance drawbacks. I have benchmark data from my company's compiler running Adobe's C++ Test Suite to support this. We recently reduced this tax by a large factor with recent optimizations, but for real-world cases, the C++ tax is still very real. I wont release the specific numbers, but here are two commonly used sorting algorithms that were 3x faster in C until recently.
Vector Sort A 2.9 – 3.0x
Vector Sort B 1.6 – 1.8x
Misconception B: Pointer logic makes OOP in C harder to debug
+ Show Spoiler +"Pointer magic", as I like to call it, is the method of using pointers to functions, and applying those functions later. When doing this, you end up seeing really crazy function calls which are hard to revoke and end up causing confusion because you aren't even sure which function is being called. So, in effect, C is harder to read than C++. But is it harder to debug? + Show Spoiler +The tools behind developing for C have been advancing at a breakneck speed for decades now. There is capability in debuggers to step through this sort of program design, and tell you which function it's expecting to be there, then step into that function, knowing the values of everything passed through, etc.. We have an effective technological way to "read" our way through a C program rather well. C++ too, but it benefits less because of this, because in C++, the problem is not that the code isn't readable, the problem is that C++ code can lie through its teeth at you without the debugger picking it up. Well, C++ is more readable, especially when it comes to OOP, but with modern tools, C is pretty debuggable as well. What it really comes down to is the time it takes to identify, fix, and test after identifying a bug. The old adage that C++ gives you enough rope to shoot your whole leg off or something is dead-on. I only have anecdotal evidence, but it usually takes 3-4 times as long to identify a bug in C++ as it does in C. It takes less time to fix in C as well, because compile times are usually only a fraction of the time for the same size program, and generating a test is also quicker. Effectively, the maintenance cycle for C is much tighter, and thus, easier to work with.
Misconception C: No one writes Linux kernel drivers
+ Show Spoiler +The embedded market is enormous. There are way more microchips in this world than there are PC's. Even with the choice of using C++ in an embedded system, most developers opt for using C because its faster to write a program to do what you want, easier to debug when it doesn't do what you want, and faster running as well. It also takes less space and thus can be ran on cheaper microchips.
I won't go on to where the OOP feature of C can be seen on other platforms, but you can imagine that its not isolated into just one market. C is pervasive everywhere.
With that being said, I wouldn't dream of writing something like a game in C, because that isn't what it is good at. Still probably wouldn't use C++, but that is personal preference, and nothing against the language.
Source: I am an support engineer at an compiler company
|
Poland794 Posts
I agree with you, however, note that I was explicitly speaking about userland stuff. All of the things you described are quite valid within kernel land (and mission-critical code such as eg. game engines) but not usually relevant in userland code.
As for the drivers, you might be right, I did underestimate the embedded market.
Regarding debugging C code vs C++ code - sorry for using a mental shortcut, I meant not just the debugging process per se, but the entire bugfixing process. It's a simple matter of the compiler simply not informing you that you wanted to cast the foo_t pointer to bar_t, not to baz_t (and baz_t is very similar to bar_t, but lacks a single function pointer at the end that is only used in very specific situations). Any time you have to rely on the programmer's know how instead of the typing system, you are bound to spend more time fixing bugs. After all, that's the main reason low-level languages like C were pretty much abandoned in userland in the first place.
Finally, I also don't want to revisit Language A vs Language B wars and I fully agree that one must pick the right language for the job. What I'm simply saying that, unless your job involves very fine-tuned optimizations, for OOP applications C++ beats C. The fact that it's possible to hack OOP related stuff into C doesn't mean that C is as well suited natively for OOP programming as is C++ (or Java, or Ocaml, or any object-oriented language).
|
Poland794 Posts
For example, imagine the following scenario:
typedef struct { void (* do_one_thing)(), void (* do_another_thing)(), void (* do_a_third thing)() } foo_t;
typedef struct { void (* do_one_thing_differently)(), void (* do_another_thing_differently)(), void (* do_a_third_thing_differently)() } bar_t;
typedef struct { void (* do_one_thing)(), void (* do_another_thing)() } baz_t;
...
foo_t **array_of_foo_ts;
...
baz_t **array_of_bar_ts = (baz_t **)array_of_foo_ts;
*(array_of_bar_ts[1]->do_one_thing_differently)();
Now, this will be perfectly valid code, what's worse - it'll even probably work, since baz is shorter than bar, so you won't run out of the array. However, what this call will do is in fact call array_of_foo_ts[0]->do_a_third_thing() instead of the intended action. Now, if those functions are computations with side effects that are relevant much further in the code, such stuff will be extremely hard to catch and debug. Obviously, in C++, the compiler would prevent this from happening (as you'd likely have bar_t inherit from foo_t).
|
Guys, I need some help.
So I need to define several classes.
-Abstract class called Account that defines 2 virtual functions.
-Concrete class called VIPAcc
-Concrete class called SavingAcc
-Concrete class called CheckingAcc
All three concrete classes extending the base class Account.
My question is: How do I implement these files as a multi-source project? I was given a main function and I see the
#include "SavingAcc.h"
#include "CheckingAcc.h"
#include "VIPAcc.h"
but where does the Account abstract class go? I feel like I'm almost there. Help would be appreciated! actually, anyone who can skype/irc me to help out with my assignment would greatly be appreciated as well.
I swear to god this is my goto place for any programming help. I feel so bad for coming back here often.
|
All your concrete classes inherit from the abstract class, so
#include "Account.h"
in your concrete class headers will suffice, since only your concrete classes need to "know" about the abstract class (unless your main also does for polymorphism, which I don't think is in the scope of your assignment.
Also remember to have include guards.
|
On March 19 2013 12:31 Wry wrote:All your concrete classes inherit from the abstract class, so #include "Account.h" in your concrete class headers will suffice, since only your concrete classes need to "know" about the abstract class (unless your main also does for polymorphism, which I don't think is in the scope of your assignment. Also remember to have include guards.
What are guards?
|
Hi. Current junior in high school and am thinking about a future in programming.
Which majors/colleges should I be looking into?
+ Show Spoiler +
I know that CMU/MIT/Standford are the three of the best but what are some others?
|
On March 19 2013 12:38 MiyaviTeddy wrote:Show nested quote +On March 19 2013 12:31 Wry wrote:All your concrete classes inherit from the abstract class, so #include "Account.h" in your concrete class headers will suffice, since only your concrete classes need to "know" about the abstract class (unless your main also does for polymorphism, which I don't think is in the scope of your assignment. Also remember to have include guards. What are guards?
I typed in 'c++ guards' into google. It brought me this link: en.wikipedia.org/wiki/Include_guard
not bad... not bad at all!
|
On March 19 2013 12:53 JeanLuc wrote:Show nested quote +On March 19 2013 12:38 MiyaviTeddy wrote:On March 19 2013 12:31 Wry wrote:All your concrete classes inherit from the abstract class, so #include "Account.h" in your concrete class headers will suffice, since only your concrete classes need to "know" about the abstract class (unless your main also does for polymorphism, which I don't think is in the scope of your assignment. Also remember to have include guards. What are guards? I typed in 'c++ guards' into google. It brought me this link: en.wikipedia.org/wiki/Include_guard not bad... not bad at all!
After 5 minutes of posting, I slapped myself for not googling it first and it lead me to that wiki. Definitely help me out.
EDIT: Nevermind. I was being stupid.
--
Anyways, I just wanted to say thank you to everyone who answered my questions and helped me with my problems. If it weren't for you guys, I'd have some weird anxiety attack.
|
On March 19 2013 09:19 Ilintar wrote:
I agree with you, however, note that I was explicitly speaking about userland stuff. All of the things you described are quite valid within kernel land (and mission-critical code such as eg. game engines) but not usually relevant in userland code.
As for the drivers, you might be right, I did underestimate the embedded market.
Regarding debugging C code vs C++ code - sorry for using a mental shortcut, I meant not just the debugging process per se, but the entire bugfixing process. It's a simple matter of the compiler simply not informing you that you wanted to cast the foo_t pointer to bar_t, not to baz_t (and baz_t is very similar to bar_t, but lacks a single function pointer at the end that is only used in very specific situations). Any time you have to rely on the programmer's know how instead of the typing system, you are bound to spend more time fixing bugs. After all, that's the main reason low-level languages like C were pretty much abandoned in userland in the first place.
Finally, I also don't want to revisit Language A vs Language B wars and I fully agree that one must pick the right language for the job. What I'm simply saying that, unless your job involves very fine-tuned optimizations, for OOP applications C++ beats C. The fact that it's possible to hack OOP related stuff into C doesn't mean that C is as well suited natively for OOP programming as is C++ (or Java, or Ocaml, or any object-oriented language).
Well if you define userland as you do then C++ has also no business of being language of choice as all the arguments that you pointed at C can be pointed at C++ and you reach a conclusion that C#(/Java/D/..) should be used in userland.
|
On March 19 2013 12:52 Release wrote:Hi. Current junior in high school and am thinking about a future in programming. Which majors/colleges should I be looking into? + Show Spoiler +
I know that CMU/MIT/Standford are the three of the best but what are some others?
Computer science is the clear route to go if you are interested in a job as a programmer. Note that computer science is not programming, however, so be ready to take on a major that encompasses both programming as well as mathematical reasoning.
As for which colleges to look at, you can look at ranking lists such as U.S. News:
http://www.usnews.com/education/worlds-best-universities-rankings/best-universities-computer-science
Frankly, though, ranking lists like these are focused on performance in-discipline as a function of research output and not necessarily quality of undergraduate education. While most of these universities will offer excellent computer science programs, you should also look at liberal arts colleges, e.g.,
http://colleges.usnews.rankingsandreviews.com/best-colleges/rankings/national-liberal-arts-colleges
as they can offer an equal, if not superior, undergraduate experience than a research university.
|
On March 19 2013 09:05 RoyGBiv_13 wrote:Show nested quote +On March 19 2013 07:37 Ilintar wrote:On March 19 2013 05:36 CecilSunkure wrote:On March 19 2013 05:26 Ilintar wrote:
Agreed - coding OOP in C is like coding lambda abstractions in Java - might be fun or useful as an exercise, but in both cases there are simply languages better suited for the job. OOP in C was actually the language of choice for a lot of GBA games. But again the point isn't to learn it professionally, but just to have a solid understanding of how what you're using in C++ works. Using function pointers and typecasting in C for OOP isn't as difficult or tedious as you guys seem to think it is. On a different topic, if I could I'd code everything in C instead of C++. I really like C. It's just that templating in C++ is so useful, and there are some very nice C++11 features coming around. Whenever someone codes something in C it's almost always completely obvious as to what they are trying to do. With C++ though there are a lot of ways to hide a lot of things. Auto-generated code, things can be run in non-intuitive ways. It's a big problem when a poor C++ programmer is writing code within a team. Of course the solution isn't "lets all code in C", it's just to use C++ appropriately. Even at my school though it's hard to find solid programmers to work with. I can't imagine how hard it would be to find a fit for a team that works primarily with C++ out in the world. Perhaps if more people started "hitting the ground running" in C things would be different? The problem is, miniscule optimization gains that you get by coding stuff in C over C++ (miniscule because both langauges are compiled, native languages, so the code will compile to basically the same assembly with a proper compiler, minus vtables and OOP-specific stuff, plus the C++ compiler can optimize a lot of OOP code that the C compiler cannot) is lost by programmer hours. C++ has type-checking for all sorts of OOP stuff that C does not - by definition, if you typecast pointers, you are basically telling the compiler "I know what I'm doing, I told you before that this was stuff of type Foo, but it's really stuff of type Bar". So the compiler will basically tell you "okay, but don't complain later when you get a segfault since you reference a non-existing function poiner". The issue here is, pointer arithmetic is notoriously hard to debug and takes away tons of valuable programmer time. Agreed - there are times when you need to do OOP-style programming in C and Linux kernel drivers are a fine example, but then again, most people don't program Linux kernel drivers. In normal, user-land applications, there is really not reason nowadays to use C over C++ if you want to do OOP. I really don't want to get back into this age-old Language A vs Language B argument, so let's just say that each has their benefits and drawbacks, and a good programmer should be able to choose the best language to fit the problem. What actually is worth discussing is the implementation specific differences between C and C++, and why you would use one over the other. Please don't take this as an assault at you, or at C++, I am just trying to clear up a few misconceptions before others read them and take them for truth. Misconception A: C++ is as fast as C, because they are both static typed compiled languages + Show Spoiler +Currently, there is a phenomenon known as the "C++ tax", which is, in effect, the overhead in using C++ over C to implement a data structure or algorithm. It isn't much, but it's there, and in plenty of applications, that is enough to warrant using C. Simple examples will compile to roughly the same assembly, but if you use templates or make excessive use of inheritance, then the overhead of C++ goes through the roof. You'll note that those are two of the biggest "advantages" C++ has to C as far as OOP goes. They are also the biggest performance drawbacks. I have benchmark data from my company's compiler running Adobe's C++ Test Suite to support this. We recently reduced this tax by a large factor with recent optimizations, but for real-world cases, the C++ tax is still very real. I wont release the specific numbers, but here are two commonly used sorting algorithms that were 3x faster in C until recently.
Vector Sort A 2.9 – 3.0x
Vector Sort B 1.6 – 1.8x
Misconception B: Pointer logic makes OOP in C harder to debug + Show Spoiler +"Pointer magic", as I like to call it, is the method of using pointers to functions, and applying those functions later. When doing this, you end up seeing really crazy function calls which are hard to revoke and end up causing confusion because you aren't even sure which function is being called. So, in effect, C is harder to read than C++. But is it harder to debug? + Show Spoiler +The tools behind developing for C have been advancing at a breakneck speed for decades now. There is capability in debuggers to step through this sort of program design, and tell you which function it's expecting to be there, then step into that function, knowing the values of everything passed through, etc.. We have an effective technological way to "read" our way through a C program rather well. C++ too, but it benefits less because of this, because in C++, the problem is not that the code isn't readable, the problem is that C++ code can lie through its teeth at you without the debugger picking it up. Well, C++ is more readable, especially when it comes to OOP, but with modern tools, C is pretty debuggable as well. What it really comes down to is the time it takes to identify, fix, and test after identifying a bug. The old adage that C++ gives you enough rope to shoot your whole leg off or something is dead-on. I only have anecdotal evidence, but it usually takes 3-4 times as long to identify a bug in C++ as it does in C. It takes less time to fix in C as well, because compile times are usually only a fraction of the time for the same size program, and generating a test is also quicker. Effectively, the maintenance cycle for C is much tighter, and thus, easier to work with. Misconception C: No one writes Linux kernel drivers + Show Spoiler +The embedded market is enormous. There are way more microchips in this world than there are PC's. Even with the choice of using C++ in an embedded system, most developers opt for using C because its faster to write a program to do what you want, easier to debug when it doesn't do what you want, and faster running as well. It also takes less space and thus can be ran on cheaper microchips.
I won't go on to where the OOP feature of C can be seen on other platforms, but you can imagine that its not isolated into just one market. C is pervasive everywhere.
With that being said, I wouldn't dream of writing something like a game in C, because that isn't what it is good at. Still probably wouldn't use C++, but that is personal preference, and nothing against the language. Source: I am an support engineer at an compiler company
Misconception A is wrong. First of all, templates don't have any runtime overhead. It's literally zero, since templates are completely resolved at compile time.
Second, the inheritance overhead you speak of exclusively comes from virtual methods/functions. You'd be very hard pressed to show me a real world application where the overhead from virtual methods is actually measurable. In only an incredibly small application set you will actually see that suck up enough performance that it's actually noticeable (more than 0.01% of program performance taken up). You can pretty much only notice it when you have a ton of virtual methods being called in very tight loops an incredibly large amount of times relative to all other things that are going on. This almost never happens. I've been professionally active in coding high-performance code, and I can tell you with confidence that inheritance overhead is the one thing that people who don't know what they're talking about when it comes to speed optimization end up way overestimating (it usually doesn't measurably exist at all).
And that isn't even mentioning the fact that this isn't an inherent disadvantage of C++ at all. Virtual functions are the result of an architectural design decision, and if you were to implement the same architecture in C OOP, C would have the same amount of overhead.
Misconception B: Two things make no sense here: First of all, readability of code absolutely impacts debugging performance (the time of man hours you have to invest in order to find a bug). I don't know how that isn't obvious to you, so saying C OOP isn't harder to debug is a simple fallacy. Second, I'd like you to give some examples of C++ "lying through it's teeth" without debuggers picking it up, because it heavily sounds like you haven't used a decent C++ debugger ever or don't have much experience with C++ at all.
Misconception C:
Your point actually shows a great misconception that people have over the embedded community, that C is used over C++ because the used microprocessors are supposedly slow as fuck and somehow C is faster or more memory efficient than C++ to such a degree that most people prefer C. Yet the real reasons are two fold: Historical reasons, and safety reasons.
Historical reasons because there have naturally been more C programmers in the embedded community so when you start out in that community in a company, or even just as a hobby programmer, you will get a barrage of people telling you that C is better for it without knowing what they're talking about. Just like in the game development community, you will have most people suggest C++ to you over something easier to use like C# or Java even if you explicitly tell them you're targeting the PC indie market, because they don't know what they're talking about. C is simply the tool that all the bosses and partners you work with when you start out are by far the most comfortable with, so naturally the field will be filled with C programmers. It's the same in the mainframe community, where everyone still programs COBOL and all "seasoned, experienced" engineers in that field will tell you that it's the best language for the job even though that language is so terribly outdated and lacking a lot of features it isn't even funny, because the average programmer age in that community is over 50. I'm not even kidding with that average over 50.
As a bonus: I've talked to two people who've been active in that field for long years (in big companies, one in a research institute and one as head engineer for a big car manufacturer), and they both tell me that pretty much everyone with any sense at all is now migrating to C++ for new embedded projects for several reasons (like used development processes, most students coming out of universities only know Java, etc.) and suddenly the supposed performance and memory benefits that C is supposed to have aren't a problem anymore at all! Of course this change is happening extremely slowly (after all, most big companies still use the waterfall development process) and will take a long while (probably >50 years) to complete.
Safety reasons: Due to things like RAII, inheritance, exceptions and that whole C++ stuff, it can be hard (especially for bad engineers) to make confident statements (as in: get very high test coverage of all possible test cases with a high certainty) about a piece of software that is written in C++, over something that is written in C. This however is an absolutely huge requirement in many of the really big companies that program embedded stuff in the safety sector. Just think about any field where peoples health depends on the correct functioning of a program. So that's why they use C there.
|
Poland794 Posts
On March 19 2013 15:04 mcc wrote:
Well if you define userland as you do then C++ has also no business of being language of choice as all the arguments that you pointed at C can be pointed at C++ and you reach a conclusion that C#(/Java/D/..) should be used in userland.
And it's indeed so - C++ as a programming language has been slowly losing ground to the combo of Java/C#.
There's still one reason for using C++, namely that it compiles to native code and doesn't run on a virtual machine - that is still relevant eg. for the gaming industry, although increasingly less so (a lot of people nowadays code eg. with the Unity framework, where you can even write your logic in JavaScript).
|
On March 19 2013 12:52 Release wrote:Hi. Current junior in high school and am thinking about a future in programming. Which majors/colleges should I be looking into? + Show Spoiler +
I know that CMU/MIT/Standford are the three of the best but what are some others?
Most computer engineering and computer science majors in big name universities teach a lot of unnecessary courses. You don't need to build an operating system or compiler or build gates or use gaussian distributions or draw circuit diagrams etc...
You'll learn about the things we talk about eg. inheritance and type comparisons as well as value comparisons in any intro to computer programming class at any school. I can't say anything about the quality of other schools as I have not been to other schools. I do think that a degree at a well known school like the three you listed is worth more than one at a lesser known one though (to employers) and that first job sets you on a good path for the future.
|
<?php
$data = array(
'Select a State'=>"Select a State",
'AL'=>"Alabama",
'AK'=>"Alaska"
);
$selected = $_POST['state'];
?>
<div class="input">
<form action="in-test.php?state=<? echo http_build_query($data, '', '&'); ?>" method="post" onSubmit="return validateForm()" name="myform">
<div class="select">
<select name="state" id="state" class="uni">
<?php
foreach ( $data as $value=>$text ) {
if ( intval($selected) == intval($value) ) {
echo '<option value="'.$value.'" selected="yes">'.$text.'</option>'."\n";
} else {
echo '<option value="'.$value.'">'.$text.'</option>'."\n";
}
}
?>
</select>
</div>
<div class="btn_area">
<input name="getstarted" type="submit" class="input_btns" value="">
</div>
</form>
</div>
I need to be able to pull the state value into the URL with out using GET. Any clue on what syntax I should be using? - _ -; Been stuck on this for a while, right now it's giving me only the first array as AL=Alabama. I need it to be just the value (AL)... Reason I can't use method="get" is because of how the system we post into is set to HTTP POST and I can't change it.
|
Hyrule19173 Posts
I don't understand your question. You don't pull data into something, you pull it out.
|
I just need to get the value of the state selection depending on what the user picked into the URL with out using $_GET. So it passes to the next page. The syntax I am using right now in the action="" gets only the first array value and it returns it as AL=Alabama. I need just AL to be returned and the value of what the user selected.
|
Hyrule19173 Posts
Action is the submit. Remove it.
|
|
|
|
|
|
EPT
