140. Stepping in C++ doo-doo, by not reading the C++ specs...
141. ...then reading the C++ specs and still not understanding what the heck it's saying 8'O
@kfmefe04
By the C++ specs, do you mean the ISO standard specification, or the standard library (or both?).
IMO the standard library documentation still leaves some to be desired...some parts still seem rather ambiguous to me. ( Example: http://cplusplus.com/forum/general/43306/ )
142. Claiming platform independence while your make-file won't work on Windows (without major modifications).
143. Not documenting the EXACT VERSIONS of any and all library dependencies. (Ever get these mysterious linker errors that you can't find support on when trying out a snazzy new API?)
If some error happens during the operation, the stream's badbit flag is set, and if the appropriate flag has been set with ios::exceptions, an exception is thrown.
too vague - when is badbit set and when is exceptions set? do they ever overlap?
If a friend declaration appears in a local class (9.8) and the name specified is an unqualified name, a prior declaration is looked up without considering scopes that are outside the innermost enclosing non-class scope. For a friend function declaration, if there is no prior declaration, the program is ill-formed. For a friend class declaration, if there is no prior declaration, the class that is specified belongs to the innermost enclosing non-class scope, but if it is subsequently referenced, its name is not found by name lookup until a matching declaration is provided in the innermost enclosing nonclass scope.
too convoluted (feels just like a clever perl script that I wrote a year ago and now, I have no idea what it means...)
144. Changing template code in too many places (often >1) at a time before compiling (risks getting buried by an avalanche of very hard to read template error messages)
145. Intermixing template code and polymorphism in a brittle manner (making code extremely hard to refactor)
146. Relying on the debugger to warn programmers on the required interface for a template class, without the benefit of useful comments
147. Returning a non-const handle to a class member needlessly
hamsterman is right, as usual - I stand corrected - it's amazing how enthusiastic beginners are at something they know so little about (not unlike getting married?)
consistently guilty of 148 - leads to unnecessarily complex code
I think it's a C++ disease - we see it all over the place, from STL to boost
149. do not confuse logical with the physical (memory vs files)
I recently generated a 4.3GB binary file for fast random access (csv is 2GB but much slower) - thinking that files are contiguous like memory (only half right), I naturally used fseek( ..., SEEK_SET ) to offset from the beginning of the file
well, everything worked fine until I tried to access the end of the file - surprisingly, it took forever, so I surrendered and looked up the man pages on fseek and found the SEEK_END option so now, before I do any fseek(), I do a quick calculation to see if I am closer to the beginning or the end of file - took a bit of playing around to calculate the offsets correctly, as I was reading records in by chunks and the chunks may not necessarily line up coming from the front or the back
which brings up the lesson of the day: files are logically contiguous but could be physically fragmented (no duh, when you think about it), which explains why there are two options for fseek() (actually, there is a third I didn't mention, SEEK_CUR), both of which are useful for big files. OTOH, memory appears to be logically and physically contiguous - you can check by dynamically allocating 4 GB on the heap: you may be denied, but allocating 1 GB four times may actually work
but I wonder, is it the nature of blocks on disks that cause the fragmentation? for example, are SSDs more like memory (logically and physically contiguous) or more like a drive (logically contiguous, but physically fragmented)? I'm guessing it's the former...
That's weird. Seeking should take constant time regardless of the whence parameter unless you're using a very crappy file system or an odd device. In particular, FAT, NTFS, ext*, and ReiserFS should not take longer to seek to the end from SEEK_SET than from SEEK_END. Their files are not linked lists of blocks.
but I wonder, is it the nature of blocks on disks that cause the fragmentation? for example, are SSDs more like memory (logically and physically contiguous) or more like a drive (logically contiguous, but physically fragmented)?
Disk and RAM are equivalent. You can format RAM with a fragmentable file system and you can allocate disk space like how you allocate RAM. The difference is that file systems are designed, among other things, to allow arbitrary resizing without reallocation and copy.
So, no. A formatted SSD is fragmentable.
before I played with the large file, I thought a binary file and RAM would be exactly the same in this sense: in RAM, it doesn't matter if I offset a pointer forward 1 byte or 1GB - it is equally fast
I was surprised to see that it isn't the case with the binary file - I assume there is an underlying reason, otherwise, there is no reason to have both SEEK_SET and SEEK_END for fseek() - one can logically convert one to the other - btw, I am using ext3 so nothing out of the ordinary - I was guessing that it was the physical fragmentation that causes the difference between forward and backwards, but I really don't know - but there is a big difference when I tried it
150. choose the right Mysql engine
151. delete all indexes before LOAD DATA INFILE
152. don't do long-lived command-lines in ssh without adjustments to timeouts or nohup (like a LOAD DATA INFILE) - instead, do it via nxmachines
for #('"s and giggles, I thought I'd load a billion row CSV (equivalent to the aforementioned binary file) into Mysql - a very bad mistake is an attempted load with an index already in place - another mistake is using the wrong engine - MyISAM takes about 11min to load on my machine (faster than I expected) while InnoDB took much longer - had to abort since it was taking too long
Of course I don't have a Linux VM when I need it.
I'll try this out with some huge GiB files and see what happens. Files are supposed to be random access regardless of how fragmented they are. Fragmentation only matters when reading them from beginning to end, not when seeking.
Yup, Ram is just insanely faster. There's actually an application called RamDisk which actually lets you create a storage partition in your ram for uber fast access. It works pretty well, and it only adds a small amount of time to your startup/shutdown times so that the contents of the disk can be read to/written from disk so you don't lose data..
in RAM, it doesn't matter if I offset a pointer forward 1 byte or 1GB - it is equally fast
No, it is not true. Actually if you forward a pointer 1 byte, you can be almost 100% sure, the byte pointed by it resides in L1 cache (because of memory prefetching done by MMU). And L1 cache is insanely fast - typically 2 or 3 CPU cycles. On the other hand, when you request a random piece of memory, it can take several hundreds or even thousands of CPU cycles. And it can take ages if it was swapped out....
So the differences between disk and RAM are not really that huge, except the fact that RAM is simply orders of magnitude faster, both in terms of transfer rate and access time.
Yup, Ram is just insanely faster. There's actually an application called RamDisk which actually lets you create a storage partition in your ram for uber fast access. It works pretty well, and it only adds a small amount of time to your startup/shutdown times so that the contents of the disk can be read to/written from disk so you don't lose data..
RAM disks were faster in times of DOS. Now there is no point in using them. All moder OSes buffer disk accesses, free memory is used to store the most frequently accessed blocks. So if you have plenty of free memory, this is equivalent of having RAM disk.
126. Accidentally Blending languages (I actually did #import a few times...)
Lol...
1 2 3 4 5 6 7 8
//You mean like
inculde java.util.*; //I did this a few times
publicclass MainClass {
publicstaticvoid main(String[] args) {
}
}
Also when I was using C# for a while I started to forget to make my Java classes public. You think that type of problem would be easy to spot, but I didn't until I tried to load the class using reflection! http://www.facebook.com/topic.php?uid=2204806663&topic=17821