Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror

Comment: Re:Gov't contractors are not paid by the hour (Score 1) 253

by ShakaUVM (#48879437) Attached to: IRS Warns of Downtime Risk As Congress Makes Cuts

>Forcing long hours on contractors and saying "well, we pay your company hourly" is an immoral load of bullshit. This is nothing less than government-sanctioned overtime fraud.

The federal government is the worst offender against labor laws in the country.

It's nice being part of the same organization that investigates and prosecutes offenses, isn't it?

Comment: Re:Problems in C++ (Score 1) 382

by ShakaUVM (#48871631) Attached to: Is D an Underrated Programming Language?

>1) No, that's not the case. The difference between .at and operator[] is that .at() has a const overload and operator[] is not.

Are you sure about that?

http://www.cplusplus.com/refer...

>2) Most high performance apps (eg. games) turn off bounds checking in any case for performance reasons.

Which is fine.

Personally, I'd have preferred it if I could simply enable or disable bounds checking on [], so I could test my code to make sure I'm not going to fry memory, and then disable bounds checking on performance critical code for release.

>Uh, stringstreams? http://stackoverflow.com/quest...

I'm not saying that you can't write your own functions, just that the STL string class is not a drop-in replacement in functionality in string.h

Comment: Re:Problems in C++ (Score 1) 382

by ShakaUVM (#48861185) Attached to: Is D an Underrated Programming Language?

>>1. Dude ... if you want to query the size of an array, use a vector. No, it doesn't make your code less readable. And, no, you don't have to use .at() everywhere: C++ has this thing called operator overloading. Maybe you've heard of it. You can use array syntax with vectors. Use vectors.

Dude, don't use square brackets with STL arrays and vectors, just to make your code more readable. The [] operator skips bounds checking, which is the main reason for using these classes in the first place. At() is the proper methodology to use in pretty much every case, unless you are so confident in your bounds that its worth the trivial speed increase in access time.

>>2. I'd like to know what functionality you think you need string.h for when using C++ strings. I've found the standard library string type quite feature-complete.

The biggest gaps were filled in C++11 with replacements for atoi() and so forth, but there's still no replacement for strtok or some of the other functions in the core language.

>>3. C++ isn't an interpreted language; of course it won't have much reflection.

Sure. Makes life more difficult though by pushing those tests out to the linker instead of being able to code them directly from the language itself.

>>4. Forward declarations are not for saving the compiler time. They are for declaring a linkage interface with external code. If you ever even thought seriously about writing a C++ compiler you would know the language is not designed to make doing so easy.

Not my point. Quite obviously you need declarations for extern names not found in the file scope. But for functions within the same file scope, you still need to do forward declarations, which is only done to avoid having to do an extra pass over the code. Might have made sense in the 80s, but not today. Maybe it's not a huge deal since it's just a single copy and paste and edit every time you change a function definition when you're working on it, but it still otherwise serves no benefit.

Also, there shouldn't be much need for #ifdef guards any more. It's 2015. We should be able to include the same function definition twice without the universe breaking.

Comment: Kdenlive (Score 5, Informative) 223

by taniwha (#48861015) Attached to: The Current State of Linux Video Editing

I've found kdenlive is great - I've had to make a couple of small videos recently,it was a breeze with a couple of minor hiccups

1. As mentioned figuring out how to do transitions was hard - they're there, just hard to figure out

2. Ubuntu .... grrr .... their last distro has broken libraries (libav+melt - broken for lots of video editors, not just kdenlive) you can happily edit away but when you try and make the final stream, no audio -apparently all they need to do is to rebuild their binaries

Comment: Problems in C++ (Score 1) 382

by ShakaUVM (#48860279) Attached to: Is D an Underrated Programming Language?

>What kind of complexities has modern C++?

1. C++ still doesn't let you query a C-style array to determine its size, even though that functionality is tracked in dynamic arrays anyway, and can be calculated from staticly defined arrays within their own scope.

So every function using C-style arrays must also pass in a size_t holding the array size. This hurts readibility by wasting room on the parameter list, and exposes you to buffer overflow errors.

Legal:
int arr[10];
for (int i : arr) cout i;

Illegal:
void write_array(int arr[]) { for (int i : arr) cout i; }

STL arrays and vectors are obviously better, at the cost of decreased code readibility. Square bracket accesses are easier to read than .at()s everywhere.

2. Strings. Even with the string type, it is still shitty to use, still has terrible support, and you still have to use the c library string.h for some functionality since they've been too lazy to rewrite all of them into the C++ standard library. This means that people wanting to use the C++ string class still need to know the C way of doing things, and are still vulnerable to the same off by one errors that have been around for decades.

3. Almost no reflection capabilities.

4. The language still enforces rather idiotic rules about class and function definitions that modern languages have done away with, and for the better. It's not like putting #ifdef guards on your code is difficult, but in these modern times it should not be necessary. And forward declarations are a way of saving compiler time at the expense of programmer time. This is the opposite of what should be happening. Compilers are there to make programmers' work easier, not the other way around.

5. C++11 and later has made great strides in simplifying the life of programmers, but its cruft accumulation shows.

Comment: Re:It's a first... (Score 2) 108

Makes me wonder if any other astronomers or other scientists to discover celestial objects will have their ashes sent in homage...

It's a romantic notion, but strikes me as not really in the spirit of science. If I knew someone was going to explore this awesome thing I discovered, I would much rather have them use every bit of available weight to further that discovery.

Comment: Re:utf-32/ucs-4 (Score 4, Informative) 165

by PhrostyMcByte (#48787983) Attached to: NetHack Development Team Polls Community For Advice On Unicode

Extracting a character - trivial. Length of string - trivial.

I don't think it's quite as simple as you think. UTF-8 is a variable-length encoding, but UTF-32 is too when you consider grapheme clusters.

When you extract characters and and determine length, are you only talking about code points (not very useful) or are you taking into consideration combining characters to account for actual visible glyphs that most people would consider to be a character?

The overwhelming majority of apps are only doing trivial operations -- string concatenation and shuffling bits to some API to display text. For these apps, choice of encoding really does not matter. NetHack is very likely in this category.

Anything more and you'll have to deal with variable-length data for both UTF-8 and UTF-32. So it doesn't really matter. Choose whichever uses less storage space.

Comment: Re:Use utf if you must, for character names, only. (Score 1) 165

by PhrostyMcByte (#48787911) Attached to: NetHack Development Team Polls Community For Advice On Unicode

For which implimentation of UTF to use, I'd go with utf8 as it seems to have the widest adoption, or 32 because that will probably allow you the longest time before having to think about this again. I would avoid the middle ground.

UTF-8, while originally only defined to 31 bits and now defined to 21 bits, actually has room to trivially extend up to 43 bits. One could say it's more future-proof than UTF-32. Not that it really matters -- we're only using 17 bits right now so I doubt we'll ever get past 21. Maybe when we encounter intelligent alien life.

Comment: Re:Stop trying to win this politically (Score 1) 786

by ShakaUVM (#48785651) Attached to: Michael Mann: Swiftboating Comes To Science

>If you want to talk about science, then show me a tested climate model that has been subjected to an empirical test of its validity. It isn't that hard guys. We have a lot of very accurate historical data. Feed in past climate data and see if your climate model can predict the past or the present accurately. The first model that can do that which isn't just a collection of plug variables is something worth taking seriously.

What? No.

You have it completely backwards. All serious models are trained on and tested using historical data. If they can't even predict the past, what use are they?

But - here's the key point - predicting the past is *worthless* other than as a sanity check. As Garrison Cottrell told me, predicting the past is easy (even trivial). It's predicting the future that is hard.

The only way to really know for sure if a model works is to test it moving forward. And the IPCC doesn't have a great track record at that.

Comment: Re:C++ (Score 1) 242

by ShakaUVM (#48750159) Attached to: Little-Known Programming Languages That Actually Pay

>STL sucks, I still have to do single character input and output from files, so much for getline BS

Gah, I/O in C++ is so horrible. In just the last month I've come across the following:

1) No platform independent way to do non-blocking I/O.

2) No iostream-compatible way of doing dup() or dup2(). You can change the buffers on iostreams, but this is not the same thing.

3) Just how shitty iostreams are at processing input files in a fault tolerant manner. On any major project, I always seem to just drop down to reading files one character at a time.

Comment: Micro-management kills this idea every time (Score 3, Insightful) 294

No matter what your industry is, some PHB is going to get into a position where they feel out of control and unproductive if they can't get instant gratification popping in on their people to micro-manage them. In-person meetings are a must for these people.

Comment: Re:No locks (Score 1) 449

by ShakaUVM (#48720325) Attached to: How We'll Program 1000 Cores - and Get Linus Ranting, Again

>Also, some problems can't be done in parallel, but we won't know how many can until we start trying....and then try for a few decades.

Right, but there's also a grey area between completely serializable and embarassingly parallel, in which methods like this will allow scaling algorithms up from "a few" computation nodes to "many", with the optimal numbers depending on the specific algorithms.

The biggest problems are still the same ones that existed when I got my Master's over a decade ago. Language support for parallelism isn't very good (I personally used MPI, which was awkwardly bolted on top of C++), it requires a certain amount of specialized knowledge to write parallel code that doesn't break or deadlock your machine (and writing optimized code is a bit more advanced than that), and library calls aren't all threadsafe. On the plus side, a lot of frameworks and libraries are now multithreaded by default, which nicely isolates the problems of parallel computing away from people who haven't been trained in it, and gives the benefits of parallel computing with only the downside of having to use a framework. =)

Comment: Not 100%... but hipsters (Score 3, Interesting) 278

by PhrostyMcByte (#48719393) Attached to: Vinyl's Revival Is Now a Phenomenon On Both Sides of the Atlantic

There are a few types I see doing this.

You'll always have those insane people who think Vinyl has better quality than CDs or FLAC... but I imagine they are a pretty small group.

You've got people who're after the experience -- maybe a more personal feel to having a big physical system that needs more interaction. Again I imagine this is larger than the first group, but still relatively small.

And finally you've got hipsters, who'll do anything just because nobody else is doing it. Very suspicious that vinyl's popularity starts to grow with a strong correlation to this group's size.

The trouble with being punctual is that nobody's there to appreciate it. -- Franklin P. Jones

Working...