Nemesis2k2

Members
  • Content count

    3356
  • Joined

  • Last visited

Community Reputation

1045 Excellent

About Nemesis2k2

  • Rank
    Contributor
  1. I tend to believe in elements of truth in most things. If they said you had "communication issues", or trouble relating with the rest of the team, there's probably some truth to it, and it is worth thinking about, but not worth dwelling on for too long. It's also damning that nobody spoke to you about this before they let you go. That tells me that hands down, you had a poor manager, or they never intended to hire you in the first place. Some managers suck. Some work environments are bad. Some places rotate through staff on "3 month trials" with no intention of hiring at the end, and spend the time building an excuse to drop you when the time is up. Sounds like you probably ran into one or more of these to some degree. I've seen a few bad working environments. You don't want to get stuck there, no matter how much of a "dream job" it looks like on the job application. At any rate, I'll give you my advice on a new job. Different situations call for different approaches, but here's my general advice: When you're new, be selective in what you say. Don't try too hard to make a strong impression, some people don't like that. Don't try anything particularly strong, eg, possibly offensive, in your conversation. Remember that you're around people you don't know, and you don't necessarily know what they will take offense to. That said, make sure you don't isolate yourself. If your collegues don't get to know you to some degree in the first month or two, chances are, they never will, and you'll probably find it hard to have a conversation with them. You need to find a way to strike up a balance, and you'll have to figure out how to go about that. In terms of your work, just do what they ask you to do, how they ask you to do it. Learn their way first. Bring your own approach where you're given the freedom to do so, but when you're told to do something a particular way, make sure you do it how you're told. This is my general philosophy. It's not a sure fire way to fit into a new job, but I think it's the best way to give yourself the best opportunity to do so. It's not all on you though. In a good working environment, your collegues will do their part to try and make you feel welcome.
  2. watch out for long delays on Dell orders

    Quote:Original post by Programmer One When it comes to business systems, Dell is pretty good in my opinion. I've done a lot of business with them - ordered nearly 40 units from this just this year so far. From my experience, they ship pretty fast. But then again, this is their business-line of machines we're talking about here. Maybe consumer-level stuff is a bit different. This. We have over 1200 machines in our organization, all from Dell, and we buy around 250 units from them each year (400 this year) as old machines move out of rotation. They're simply the best for business, in particular, because of their support. If we have a machine with a hardware fault (Eg, dead HDD, faulty MB, etc), we've got a Dell technician on-site the next day fixing it. We also use Dell laptops (which are very good; we evaluated models from a dozen different manufacturers and the Dell unit came out on top), and Dell offer an insurance plan which includes cover for accidential damage. If a staff member breaks the screen or drops it in the pool, Dell will repair/replace it with no questions asked. I can't recall ever having a hassle about a warranty claim from Dell. We also use Dell servers, and their service policy and turnaround times for them are just nuts. And they still manage to consistently beat out other vendors in terms of price. Remember though, this is business, and we're buying in bulk. Dell are great for organizations. As for myself, I'd never buy from them for a home computer. Laptops, yes, desktops no. They simply don't offer the range, or competitive enough pricing, when it comes to individual machines, IMO at least. Their support isn't going to be anything like their corporate support either, although still probably better than you'd get most other places, and undoubtedly better than HP. Seriously, you don't want to deal with HP support, even when you're a corporation. Personally, I highly recommend Dell for business, or personal laptops. For home desktop computers, I recommend Newegg for the tech-savvy, or a local computer store for the average home user. Quote:From experience, I would avoid dell. Where I work I manage about 40 dell desktops. We have had about a 70% failure rate over two years. It is either the hd or the psu. At least they are good about honoring their warranty though. We had bad HDD problems from one dud model, leading to around a 50% HDD failure rate over 2 years, but this came back to the Maxtor drives (which I don't believe Dell use anymore; all our machines have been Seagate or Western Digital since). Apart from that, all of our models have been reliable, and we have relatively few failures. Out of 1200 machines, we have maybe two or three repair jobs a week, including damage inflicted by users. I compare that to our batch of 150 Acer desktops, where we would constantly have 6 or more machines down due to some kind of fault, and have to wait several weeks for repair.
  3. std::stringstream not thread safe?

    This is looking more like a buffer overflow or rouge write. I got another crash yesterday while exiting the program which was clearly caused by heap corruption. I also got another crash in the stringstream destructor where the entire DebugInfo struct had been overwritten. Now I've just got the fun task of identifying which section of code is responsible, with a dozen actively running threads and over 60,000 lines of code to check. I guess I'm just (un)lucky that this one temporary object seems to be the only thing that's being regularly affected. Quote:Ok, if your problem was really the creation and destruction of independent std::stringstream objects, then this program should die in the same way: Yeah, I've tried similar tests and I haven't been able to reproduce this crash. Mind you, tests like this don't rule out an interaction of other standard library components which share common globals in the back-end, but I'm becoming more confident that the standard library isn't the cause of this problem. Quote:Wasn't there a bug in the Visual Studio 2005 pre SP1 version of std::basic_stringstream? Are you using VS2005? Have you installed SP1? Yeah, it was a memory leak, and it caused me big problems when I migrated to VS2005. I installed SP1 the day it came out.
  4. std::stringstream not thread safe?

    Quote:The only manner in which different objects of this sort ever affect each other is memory allocation. Unless you're doing special pooled allocator stuff (and you'll know if you are) you're fine. (Assuming a thread-safe allocator. You're using a threadsafe runtime, right?) No, I'm not doing my own allocators, and yes, I am using the multi-threaded runtime. Quote:If it's a completely thread local object that isn't being used from anywhere else, your crash is probably not threading related. So let me ask -- what exactly is the crash? What is it doing at the point of failure? Is it an assertion or an exception? When I did some debugging on the last crash, it looked like it might be a double-free problem with a critical section object which is owned by the stringstream, IE, the object was deleted twice. The crash occurs within ntdll.dll, in a function to destroy a critical section. Specifically, it's an access violation reading from address 0, while trying to parse a structure within the object. I can't be more precise right now, as I unfortunately didn't save any more info on the crash, and since it's a random kind of problem, I'll just have to wait for it to happen again. Actually, I've just had a look at the CRITICAL_SECTION object to refresh my memory, and the crash occurs in the DeleteCriticalSection function, in code which handles the DebugInfo struct within the object, while parsing the "ProcessLocksList" member. The members of the ProcessLocksList were zero, and the code assumed they pointed to valid memory addresses. Unfortunately, there's no way I can determine the real cause of the crash without finding out where and how these members were set to 0. The other members of the DebugInfo struct did appear to be valid at the time of the crash. On the surface, it looks like the kind of thing you'd blame on a buffer overflow. I think the nature of this crash means it's one I'm going to have to debug myself. The extremely short-lived and localized nature of this object however, the fact I haven't got crashes anywhere else, the fact no other corruption appeared in the affected structure, and, quite arrogently, the fact that IMO I've basically eliminated the potential for buffer overflows in my coding style over the last few years led me to do some research first. Before I spend the next week chasing a phantom buffer overflow, I wanted to check if a stringstream was even thread safe to begin with. That discussion in the boost mailing list implies that this isn't necessarily the case. Specifically, there's this comment: Quote:"Perhaps there is more to std::stringstream in this regard, as I remember you talked about some global variables in it, but it appeared the issue stopped at replacing it with the customized stringstream (in addition to replacing std::string)." and this comment: Quote:"> It looks like the "thread-dangerosity" you're > speaking about is like the same we would have by used two different > stringstream objects in two different threads... " This is what I'm doing. I'm using two (or more) different stringstream objects in two (or more) different threads concurrently. If this is the cause of my bug, I can deal with it, but I was alarmed to hear that this might not be safe. I wanted to check here to see if anyone else had some more info about this.
  5. std::stringstream not thread safe?

    Quote:The rules are clearly spelled out by implementations. At this point, pretty much all of them have the same rule: Containers allow unlimited concurrent reading, but writing requires exclusive access to that container. Sorry, I think you mistook what I meant by thread safety. I've clarified what I meant in the above post.
  6. std::stringstream not thread safe?

    Oh, and for the record, I am talking about thread safety in the context of two completely separate, independent objects being created and used at the same time in separate threads, NOT two separate threads accessing the same object at the same time. This should be thread safe, as long as the objects don't rely on a common global or static variable. Sorry, I just realised I never qualified this.
  7. std::stringstream not thread safe?

    Quote:Original post by SiCrane Consult the documentation for your standard library implementation. For example, for MSVC, there's a document titled "Thread Safety in the Standard C++ Library" in MSDN that details what threading guarantees the MSVC standard library implementation provides. Thanks, I'll look that up. I am using VC++2005 BTW.
  8. std::stringstream not thread safe?

    Quote:If your stringstream is created, used, and destroyed as an automatic variable by a single thread, it should be entirely threadsafe, unless your std::allocator is not threadsafe. Are you absolutely sure about that? In the absence of anything to the contrary, I would assume the same thing. I did assume the same thing. Right now though, all I can say is I'm getting random crashes in the destructor for stringstream objects. It's either a buffer overflow in some random part of my code (and I've virtually ruled out that possibility already), or it's not in my code at all.
  9. std::stringstream not thread safe?

    Quote:Keep in mind that C++ is not thread-aware and so the standard library makes no attempt to ever be thread safe about anything. You will generally have to handle locking yourself. That's a fair point, but there has to be a limit to that line of thinking. I haven't read every line of code for every standard library, nor do I plan to. I mean, I use std::string and std::vector everywhere. I've never looked at the code for them. I've got no plans to wrap global locks around every access to a vector or string object just in case it's not thread safe. If I can't have any confidence in the C++ standard library in a multithreaded program, that's a BIG problem for me. I use the STL to make programming easier, and to reduce errors. Most of my apps nowadays are multithreaded, and I've got no intention of re-writing the STL. The simple fact is, C++ is moving into a more "thread aware" state. C++0x should introduce native threading support. With that, I would expect the standard library itself to become thread safe, or at least, for the rules to be clearly spelt out. I just want to work around this minefield until it's cleared. My concern right now is the stringstream class. My exposure to the STL in general is limited, and I can control access to any affected areas, I just need to know what exactly needs to be controlled. I've been coding in C++ for 10 years now, and this is the first I've heard of a stringstream potentially not being thread safe. Where does this end? Does it affect the iostream library itself? Does anyone have a list of known safe or known danger areas?
  10. After repeated crashes at random times in my heavily threaded program, always in the destructor for a specific std::wstringstream object that only exists for literally 3 lines of code, I did some research, and I'm hearing whispers here and there that stringstream objects may not be entirely thread safe. This thread from the boost mailing list seems to be the strongest thing I've come across: http://lists.boost.org/Archives/boost/2006/09/109907.php Does anyone have some more info on this? Also, if stringstreams aren't thread safe, does anyone have any suggestions on what to use instead?
  11. How intelligent are kangaroos?

    Yeah, judging my my driving experiences, I'm going to say Kangaroos are not very smart. I haven't hit any, but I've come close a number of times. One time I was flying along a rural road at 100KPH at night, and I round a corner and find a group of about a dozen of them just standing in the middle of the road. I had to do some pretty quick braking to avoid hitting them. What really got me was the fact that the buggers just stood there. I came hurling towards this mob in a big 4WD at high speed, and managed to pull up just a few metres in front of them. Half of the roos didn't even look up, and the ones that did just looked down again and didn't react. It took about 20 seconds before some of them got the message they should probably move, and they started slowly hopping off the road a few at a time. And yeah, I took the next corner at 70 instead.
  12. Is this ...unethical?

    Thanks for the feedback. In the end, I've decided to use the control basically as it is. Hex Workshop does allow the font, colours, sizes, etc to be redefined by the user, so the only real hang-up here is the defaults, and in fact, with the exception of the colours, all of that is different in my control anyway. If I'd started from scratch, and finished with something that ended up looking like Hex Workshop, I wouldn't have any problem with it. As Anon said however, I did set out to replicate Hex Workshop, and that's where I kind of ended up feeling a bit guilty in the end. I probably should have just built my own control, and ignored the specifics of what Hex Workshop did. Is that even possible though? If you've been using a particular tool for years, and in your opinion it's got the best interface, and you've got no ideas about how it could be done any better, how can you sit down and design something else? Ehh, same as a lot of other things I suppose. The "code of ethics" about interfaces seem a bit vague to me. If I write my own app which does exactly what another app does, there's nothing wrong with that (let's just ignore patents shall we). The concept may not be new, but it's my implementation. As long as I wrote the code, there's no problem. With an interface though, is the look and general design itself something that can be claimed, or are the actual interface templates as far as that ownership goes? It looks like most people here would say the actual templates are all that's off limits, although I wonder if I'd get the same answer if I asked a designer. I'm really glad I wasn't around for the early days of GUI design. I'd be the guy who stresses for a week about whether he should copy the idea of a button.
  13. Is this ...unethical?

    I'm a little divided about this, so I thought I'd ask the question here. More than a few of you here are probably familiar with Hex Workshop. It's a feature-rich hex editor for Windows, and one of my favourite tools. I've been using it for over 10 years now. Here's what the interface looks like with the default settings: Now, to the point. I'm working on a fairly large non-commercial project right now. It's just something I'm doing by myself, but it will be released publicly. This project is a program which allows physical systems to be modelled, run, and debugged, entirely in software (a hardware emulator). As part of this project, I needed to create a custom control to allow memory buffers to be viewed and edited on the fly, within my debugger as the system is running. Essentially, I needed a mini hex editor embedded in my app. Naturally, when I thought of a hex editor, the first thing I thought of was Hex Workshop. I also know most of the people who will be using this app in the immediate future also use Hex Workshop. I wanted to make my editor consistent with the look and feel I was used to, and my users are used to, so I set about creating my own control with a similar look and similar behaviour. Here's what I ended up with: There really isn't a lot to this. It's a dozen or so pages of win32 code all up to build the control. Hex Workshop has a lot more to it than just its data editor window, but it is of course a significant part, and it does a lot to define the look of the program. I didn't have too many problems with this before I made my control, but now that I've actually done it and I can see just how similar it is, I'm having second thoughts. I did use a different font, font size, and column spacing, which were more appropriate within my program, but the colours for the columns in particular have been directly taken from Hex Workshop. So, to the question then, do you think is this unethical? Should I avoid making my editor look like another one?
  14. Profiling tools?

    I've used the DevPartner Profiler quite successfully for C++ code. It's great for really fine-grained performance analysis. If you want to be able to see execution times line by line, this is the kind of tool you're looking for. One of the problems with profiling is that the very act of measuring and recording execution times increases execution times, and changes timing patterns. The DevPartner Profiler seems to be pretty good at balancing the footprint to prevent the profiler skewing the results, but there is a significant overhead added by the instrumentation, meaning your program will run much slower when you're profiling. For most purposes this isn't much of an issue, but I've found the results are mixed whenever you have multiple threads involved. Still, if you just need to do a thorough analysis of a single-threaded app, or an individual function or module, it should get the job done nicely.
  15. compiler errors on different compilers

    That's a new one to me. I don't have a copy of the standard on hand. Regarding the fact VC++ compiles this and some other compilers don't, is that a non-standard extension in VC++, or is the compiler allowed to detect and handle these cases, but some others just aren't smart enough?