|
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 July 19 2013 08:44 nunez wrote:Show nested quote +On July 19 2013 08:08 RoyGBiv_13 wrote:On July 19 2013 07:40 nunez wrote:On July 18 2013 18:09 Tobberoth wrote:On July 18 2013 10:40 Pawsom wrote:On July 18 2013 10:21 holdthephone wrote:
Alright, C++:
Have a text input file, want to read it into char array, but size of file is variable (could be 8 chars, 64, 512, etc...). How can I accommodate for the right amount of characters, besides simply creating an ultra huge char array?
Vectors if its C++ This would be my advice as well. You can use new (or malloc though if it's C++ I don't see why you would), but in modern C++, using vectors would probably be considered best practice. use vector! don't use new unless you can't not heap it. if you are also looking to parse the files contents check out boost spirit qi! excellent parser generator library for cpp. example parsing file into vector of chars... look how cute. #include <fstream>
#include <vector>
#include <boost/spirit/include/qi.hpp>
namespace spirit = boost::spirit;
namespace qi = boost::spirit::qi;
std::vector<char> data;
qi::parse(spirit::istream_iterator(std::ifstream("input.txt") >> std::noskipws), spirit::istream_iterator(), *qi::char_, data)
A more generic question would be: "how do I keep a variable amount of memory reserved for X purpose". The more generic answer is: "on the heap, on the stack, or within ROM (a file on the file system, typically) [and secret option D, manually defined memory]" You typically don't want to use the stack for unbounded amounts of memory, as it can cause a stack overflow, which could be a security hole. This is typically why you don't have unbounded recursion either. In this case, you are trying to buffer a variable amount of memory in RAM for processing data typically stored in ROM. This would mean you will dynamically request memory from the heap. Boost's Array, std's Vector, and C's malloc library all use heap. Typical OS behaviour states that your heap can continue to grow as long as you have pages left for the kernel to assign, so it is bounded by the amount of RAM on your system. Because the malloc library uses operating system hooks, it does not have (major) security issues like the stack does. Vector and Array are pretty good at heap management, trying to keep your data in a contiguous virtual block if possible, but calling malloc directly also has it's benefits. The keyword "new" is a wrapper around malloc that also calls the constructor for that class. The third option would be to directly process the file in ROM without buffering the entire thing into RAM. This is a strategy used by many of the GNU utilities, as streaming data does not need a variable size buffer. Probably the fastest way, but definitely overkill in most applications. [secret option D is just assigning a pointer to some place in memory, clearing it and using it, but why do this whenever such smart people have already build a malloc library?] i didn't mean to imply vector does not use heap if you extrapolated that from my post (the vector itself is ofc on the stack), it usually does (does not have to). maybe i should have been more explicit instead of going for a bad pun, he he. rather to use vector instead of new for a dynamically sized array of chars, felt it was a safe bet considering the perceived context.
Wasn't meaning to correct or otherwise flame. Everything in your post was correct. I am just somewhat knowledgeable about the low-level bits, and like to drop knowledge bombs, so newbies can get a bit of context surrounding the answers to their questions. Vector is probably what he wants to use, but he may not know why its better than the alternatives... which I didn't exactly explain either...
|
On July 19 2013 09:14 RoyGBiv_13 wrote:Show nested quote +On July 19 2013 08:44 nunez wrote:On July 19 2013 08:08 RoyGBiv_13 wrote:On July 19 2013 07:40 nunez wrote:On July 18 2013 18:09 Tobberoth wrote:On July 18 2013 10:40 Pawsom wrote:On July 18 2013 10:21 holdthephone wrote:
Alright, C++:
Have a text input file, want to read it into char array, but size of file is variable (could be 8 chars, 64, 512, etc...). How can I accommodate for the right amount of characters, besides simply creating an ultra huge char array?
Vectors if its C++ This would be my advice as well. You can use new (or malloc though if it's C++ I don't see why you would), but in modern C++, using vectors would probably be considered best practice. use vector! don't use new unless you can't not heap it. if you are also looking to parse the files contents check out boost spirit qi! excellent parser generator library for cpp. example parsing file into vector of chars... look how cute. #include <fstream>
#include <vector>
#include <boost/spirit/include/qi.hpp>
namespace spirit = boost::spirit;
namespace qi = boost::spirit::qi;
std::vector<char> data;
qi::parse(spirit::istream_iterator(std::ifstream("input.txt") >> std::noskipws), spirit::istream_iterator(), *qi::char_, data)
A more generic question would be: "how do I keep a variable amount of memory reserved for X purpose". The more generic answer is: "on the heap, on the stack, or within ROM (a file on the file system, typically) [and secret option D, manually defined memory]" You typically don't want to use the stack for unbounded amounts of memory, as it can cause a stack overflow, which could be a security hole. This is typically why you don't have unbounded recursion either. In this case, you are trying to buffer a variable amount of memory in RAM for processing data typically stored in ROM. This would mean you will dynamically request memory from the heap. Boost's Array, std's Vector, and C's malloc library all use heap. Typical OS behaviour states that your heap can continue to grow as long as you have pages left for the kernel to assign, so it is bounded by the amount of RAM on your system. Because the malloc library uses operating system hooks, it does not have (major) security issues like the stack does. Vector and Array are pretty good at heap management, trying to keep your data in a contiguous virtual block if possible, but calling malloc directly also has it's benefits. The keyword "new" is a wrapper around malloc that also calls the constructor for that class. The third option would be to directly process the file in ROM without buffering the entire thing into RAM. This is a strategy used by many of the GNU utilities, as streaming data does not need a variable size buffer. Probably the fastest way, but definitely overkill in most applications. [secret option D is just assigning a pointer to some place in memory, clearing it and using it, but why do this whenever such smart people have already build a malloc library?] i didn't mean to imply vector does not use heap if you extrapolated that from my post (the vector itself is ofc on the stack), it usually does (does not have to). maybe i should have been more explicit instead of going for a bad pun, he he. rather to use vector instead of new for a dynamically sized array of chars, felt it was a safe bet considering the perceived context. Wasn't meaning to correct or otherwise flame. Everything in your post was correct. I am just somewhat knowledgeable about the low-level bits, and like to drop knowledge bombs, so newbies can get a bit of context surrounding the answers to their questions. Vector is probably what he wants to use, but he may not know why its better than the alternatives... which I didn't exactly explain either...
ah ok, i am glad. the worst case scenario was that i had been unclear (or wrong) in my post, i did not mean to come off as accusing you of flaming.
in any case could you elaborate on what benefits calling malloc directly has? i am a newb in general, but specifically at the lower level bits. and also if you are aware of a good example (by good i mean as simple as possible) of a gnu util processing a file in ROM? sounds like an interesting peep. if so i will detonate the bomb while eating breakfast tomorrow in between... bites... :<
|
For those C/Linux programmers out there? what are your go to resources for intermediate to advance level education?
|
How important is it to learn assembly for a career in CS?
I read through most of Abductedonut's old posts and he seemed to stress it quite a bit and he seemed to be quite a sharp guy (although he definitely doesn't seem like average guy).
|
On July 19 2013 14:27 Release wrote:
How important is it to learn assembly for a career in CS?
I read through most of Abductedonut's old posts and he seemed to stress it quite a bit and he seemed to be quite a sharp guy (although he definitely doesn't seem like average guy).
Very unimportant
|
What about the rest of his posts, especially the first page one? It's one of the only specific paths I've seen mentioned in this thread.
|
If you want to learn about assembly and assembly-level things, then do it, don't look for an excuse or permission to do so. But how useful is it professionally? Not very. There's certainly people in this thread that believe you have to start from the bottom to know how things work, but that's patently untrue. I work with a ton of talented people who have very little experience or working knowledge of assembly, yet they're some of the best people I've worked with.
I personally started out programming around age 12, and I must have tried, and failed, to learn C++ to any reasonable degree on 3 separate occasions. Then I found Delphi and was actually able to make some programs that did some interesting things, and I've never looked back since. Telling someone that they should learn assembly first is like telling a weak man he should skip everything and just try to lift 300lbs immediately. The people that do so are far more likely to get confused, frustrated, and walk away than to actually learn anything useful.
My advice? Pick some project topics that interest you, work on them in whatever language makes sense. That language will very rarely ever be C, and almost never be assembly. If you master some other languages and then decide you'd like to know more about how they work under the hood, then sure, learn C, learn assembly. By then you'll have enough varied experience that it won't be all that hard.
All of this is coming from someone who has spent a ton of time reverse engineering other software and reading assembly to do so. Do I enjoy it? Sure. Has it ever been a useful skill in my professional life? Nope.
|
On July 19 2013 14:27 Release wrote:
How important is it to learn assembly for a career in CS?
I read through most of Abductedonut's old posts and he seemed to stress it quite a bit and he seemed to be quite a sharp guy (although he definitely doesn't seem like average guy).
It all depends on what you are most interested in really, CS is a very large field, and the careers that you can follow after your degree will vary a lot. Some will never use Assembly, and never consider its existence, and others will use it all the time, even nowadays. As an example, about 50% of my time at work is spent writing Assembly code.
If you love low-level programming, if everytime you use a library you wonder how things work underneath, you'll probably get a kick out of learning Assembly and getting to know your CPU better. If you don't think you'll want to work with low-level stuff, and it feels like a pain, then I don't think you need to inflinct this on yourself.
|
On July 19 2013 14:27 Release wrote:
How important is it to learn assembly for a career in CS?
I read through most of Abductedonut's old posts and he seemed to stress it quite a bit and he seemed to be quite a sharp guy (although he definitely doesn't seem like average guy).
How important is it to learn assembly for a career in CS? It isn't important to learn because you will be programming at the machine code level on a regular basis (you won't). It is crucial to understand because a good computer scientist should be aware of, and be able to articulate, what is happening at all levels of the computer system when a program operates.
|
On July 19 2013 14:27 Release wrote:
How important is it to learn assembly for a career in CS?
I read through most of Abductedonut's old posts and he seemed to stress it quite a bit and he seemed to be quite a sharp guy (although he definitely doesn't seem like average guy).
It's not important at all. However, it's extremely interesting, and I would expect most CS students to have the kind of interest in computers which assembly satisfies. Unlike all other programming languages, assembly pushes the computer architecture right in your face and really shows you how a computer works on a completely different level, even C is crazy abstraction compared to pure assembly.
|
Thanks. I think I get it lol. Not necessary.
|
On July 19 2013 14:27 Release wrote:
How important is it to learn assembly for a career in CS?
I read through most of Abductedonut's old posts and he seemed to stress it quite a bit and he seemed to be quite a sharp guy (although he definitely doesn't seem like average guy).
For a career in computer science? I don't know, for Software Engineering it can be quite useful though. What are CS careers anyway? I suppose cryptography?
You never need to learn assembly but it can be useful to be able to know how to step through it to ensure your symbols are lining up properly and to figure out exactly whats going on in some highly obfuscated code etc
It's usually a last resort though and stepping through something isn't that hard if you have a reference book.
Basically I'd say it may be worth reading a bit about it in your spare time but unless you're facing a situation where its required I wouldn't worry about it, unless you plan on writing compilers etc its probably more a hindrance than a help to dedicate serious time to understanding it. That being said if you do I'd go for x86-64, seems pointless learning x86-32 nowadays.
|
if you want to analyze viruses/malware, assembly (x86) is a must.
|
Hyrule19203 Posts
Assembly is nice to learn after you've been programming for a while. It's tied to hardware and will give you a better idea of how programming actually works. There are very few cases where it's actually required.
|
So I'm having a wierd issue with a Perl script, but it might not be a Perl problem per say....
Essentially I have some testing automated for certain apps... before my perl script runs said app, it creates/alters some registry keys.
However if the keys already exist as is in the registry... Creating them is causing some of the values to become "Invalid" in the registry... :S
relevant code:
+ Show Spoiler +
use Win32::Registry;
... other code ...
my $p="SOFTWARE";
$main::HKEY_CURRENT_USER->Open($p, $CurrVer);
$CurrVer->Create("APPCOMPANY", $F1);
$F1->Create("APPNAME", $F2);
$F2->Create("Preferences", $F3);
$F2->Create("Browser", $keyme3);
$F2->Create("LastSelection", $keyme2);
$F3->Create("General", $keyme1);
$F3->Create("OpenCL", $keyme4);
$keyme1->SetValueEx("DoCheckForUpdatesOnStartup", 0, REG_SZ, "False");
$keyme2->SetValueEx("active", 0, REG_SZ, "FileSystem");
$keyme3->SetValueEx("dir", 0, REG_SZ, "path\path\path");
$keyme3->SetValueEx("lastselectedpath", 0, REG_SZ, "path/path/path");
$keyme4->SetValueEx("Enabled", 0, REG_SZ, "true");
$keyme4->SetValueEx("CLUtilization", 0, REG_DWORD, "3");
It's just the active key that messes up and goes invalid every other time its run.... I can't figure it out... Can any perl experts figure it out?... or maybe there is a way to check if the key is already there before creating it?..Not sure how to do that.
|
On July 19 2013 09:39 nunez wrote:Show nested quote +On July 19 2013 09:14 RoyGBiv_13 wrote:On July 19 2013 08:44 nunez wrote:On July 19 2013 08:08 RoyGBiv_13 wrote:On July 19 2013 07:40 nunez wrote:On July 18 2013 18:09 Tobberoth wrote:On July 18 2013 10:40 Pawsom wrote:On July 18 2013 10:21 holdthephone wrote:
Alright, C++:
Have a text input file, want to read it into char array, but size of file is variable (could be 8 chars, 64, 512, etc...). How can I accommodate for the right amount of characters, besides simply creating an ultra huge char array?
Vectors if its C++ This would be my advice as well. You can use new (or malloc though if it's C++ I don't see why you would), but in modern C++, using vectors would probably be considered best practice. use vector! don't use new unless you can't not heap it. if you are also looking to parse the files contents check out boost spirit qi! excellent parser generator library for cpp. example parsing file into vector of chars... look how cute. #include <fstream>
#include <vector>
#include <boost/spirit/include/qi.hpp>
namespace spirit = boost::spirit;
namespace qi = boost::spirit::qi;
std::vector<char> data;
qi::parse(spirit::istream_iterator(std::ifstream("input.txt") >> std::noskipws), spirit::istream_iterator(), *qi::char_, data)
A more generic question would be: "how do I keep a variable amount of memory reserved for X purpose". The more generic answer is: "on the heap, on the stack, or within ROM (a file on the file system, typically) [and secret option D, manually defined memory]" You typically don't want to use the stack for unbounded amounts of memory, as it can cause a stack overflow, which could be a security hole. This is typically why you don't have unbounded recursion either. In this case, you are trying to buffer a variable amount of memory in RAM for processing data typically stored in ROM. This would mean you will dynamically request memory from the heap. Boost's Array, std's Vector, and C's malloc library all use heap. Typical OS behaviour states that your heap can continue to grow as long as you have pages left for the kernel to assign, so it is bounded by the amount of RAM on your system. Because the malloc library uses operating system hooks, it does not have (major) security issues like the stack does. Vector and Array are pretty good at heap management, trying to keep your data in a contiguous virtual block if possible, but calling malloc directly also has it's benefits. The keyword "new" is a wrapper around malloc that also calls the constructor for that class. The third option would be to directly process the file in ROM without buffering the entire thing into RAM. This is a strategy used by many of the GNU utilities, as streaming data does not need a variable size buffer. Probably the fastest way, but definitely overkill in most applications. [secret option D is just assigning a pointer to some place in memory, clearing it and using it, but why do this whenever such smart people have already build a malloc library?] i didn't mean to imply vector does not use heap if you extrapolated that from my post (the vector itself is ofc on the stack), it usually does (does not have to). maybe i should have been more explicit instead of going for a bad pun, he he. rather to use vector instead of new for a dynamically sized array of chars, felt it was a safe bet considering the perceived context. Wasn't meaning to correct or otherwise flame. Everything in your post was correct. I am just somewhat knowledgeable about the low-level bits, and like to drop knowledge bombs, so newbies can get a bit of context surrounding the answers to their questions. Vector is probably what he wants to use, but he may not know why its better than the alternatives... which I didn't exactly explain either... ah ok, i am glad. the worst case scenario was that i had been unclear (or wrong) in my post, i did not mean to come off as accusing you of flaming. in any case could you elaborate on what benefits calling malloc directly has? i am a newb in general, but specifically at the lower level bits. and also if you are aware of a good example (by good i mean as simple as possible) of a gnu util processing a file in ROM? sounds like an interesting peep. if so i will detonate the bomb while eating breakfast tomorrow in between... bites... :<
Here is the git source tree for "sed", the GNU stream editor. Scanning through the code, you'll want to look for process_files function under the execute.c, this is where the magic happens. In the early stage of processing the files, it buffers only one line at a time, malloc'ing 50 bytes for processing as per "INITIAL_BUFFER_SIZE". Later when writing back to the file, it has a buffer of 8kB, defined as FREAD_BUFFER_SIZE in order to quickly scan through a file to find where it is supposed to append each change in the file it is supposed to make. Note that this is not strictly for file streams, and is meant for any generic stream (pipe, socket, or file pointer).
You can use malloc directly for a lot of very clever memory management techniques. For example, In game design, you know that the maximum buffer size you will need, and are worried most about the worst case, so malloc'ing the entire size at the beginning of the program could save you time during a critical loop later.
My personal favorite clever use of malloc I saw a customer of mine use when doing some network optimizations. They were building a crypto stream cipher, and needed a large amount of unbounded variable memory to work on (>40MB), but couldn't pay the CPU tax when the time was needed to run the cipher. Sometimes, the network requested faster than the cipher, but sometimes slower. They malloc'd a large space near the beginning of the board initialization for the initial heap, and as the cipher got to a threshold limit in the heap, it would add another page onto the heap during a brief moment the CPU was not running the cipher because it was accessing the network peripheral on the chip. They found that where they were calling malloc() from, even within the same loop, had a large performance impact, because there is only one task allowed "inside" the kernel at a time, and adding a page to the heap requires asking the kernel for the page. When the cipher was running, it was inside the kernel, as it had to access physical registers directly.
|
On July 18 2013 11:46 Rotodyne wrote:Show nested quote +On July 17 2013 06:30 HardlyNever wrote:Anyone have experience with this JQuery plugin ? http://jqueryvalidation.org/I'm having trouble getting it to work on my form. Or anyone recommend another jquery plugin to validate my forms (they don't have to be too robust). I have used that one before and it seemed to work well. If you post your code or PM me I could take a look.
Thanks. I'm trying to get it so that the user has to select a drop down option in the "serviceArea" drop down (so the value can't be "Select..."). I'm also trying to get it to stay on the page (not go to my form action php page) after submission. I know I can use php header for this, but I'm sure there is a way to do it with javascript, I just don't know how.
Relevant html/js + Show Spoiler + <form id="myform" action="php/suggestionFunc.php" method="post" title="suggestion"> <fieldset> <legend>Service Area</span></legend> <div class="option"> <select name="serviceArea"> <option value="select" selected />Select...</option> <option value="Website" />Website</option> <option value="Reference" />Reference</option> <option value="Circulation" />Circulation</option> <option value="Collection" />Collection</option> <option value="Instruction" />Instruction</option> </select> </div> </fieldset> <fieldset> <legend>Comment</legend> <div> <div class="fm-req"> <label for="comments">Comments: </label> <textarea rows="5" cols="50" name="comments" id="comments" placeholder="enter comments" required ></textarea> </div> </div> </fieldset> <fieldset> <legend>Contact Information:</legend> <p>(Optional, If you would like a response)</p> <br> <div class="fm-opt"> <label for=name>Name:</label> <input type="text" size="50" name="name" id="name" placeholder="Optional" /> </div> <div class="fm-opt"> <label for=email>E-Mail:</label> <input type="email" size="50" name="email" id="email" placeholder="Optional" /> </div> <div class="fm-opt"> <label for=phone>Phone:</label> <input type="text" size="50" name="phone" id="phone" placeholder="Optional" /> </div> <div class="radio"> <ul> <li><input class="radio" type="radio" name="status" value="Faculty" checked /> <label>Faculty</label></li> <li><input class="radio" type="radio" name="status" value="Staff" /> <label>Staff</label></li> <li><input class="radio" type="radio" name="status" value="Student" /> <label>Student</label></li> <li><input class="radio" type="radio" name="status" value="Other" /> <label>Other</label></li> </ul> </div> </fieldset> <div id="fm-submit"> <input id="submit" type="submit" name="Submit" value="Submit" /> <input id="reset" type="reset" name="Reset" value="Reset" /> </div> </form> <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script> <script src="https://ajax.googleapis.com/ajax/libs/jqueryui/1.8.23/jquery-ui.min.js"></script> <script src="js/jquery.validate.js"></script> <script> $("#myform").validate(); </script>
Thanks for the help.
|
@Hardlynever: your code works perfectly fine for me
You should check maybe the JS console if it gives you any error
|
The form should work fine. It's the validator jquery plugin that I don't really know how to configure.
|
|
|
|
|
|
|
|
EPT
