using(PennyArcade.Forum){Threads.push(ProgrammingThread())}

Senjutsu

Doc wrote: »

I'll start posting stuff when I get back to my work machine

we have one file that goes something like

if a:
  x()
elif b:
  x()
elif c:
  x()
elif d:
  x()
  y()
else:
  x()

but for hundreds of lines.

we have a case statement that runs 1600 lines and is mostly the same in terms of duplication of behavior

Starfuck

stuff like that is the reason you have this
http://www.antiifcampaign.com/

Daedalus

I had a piece of GUI code in Java that I had to modify at my job a while back (on a different assignment than my current one, so I can't look at the exact code anymore) that would read the text label for a button and use that to determine what the button should do. The text labels were all hard-coded in multiple places throughout the code and would sometimes change at runtime.

An ye stare into the abyss etc., etc.

Doc

Starfuck wrote: »

stuff like that is the reason you have this
http://www.antiifcampaign.com/

I generally gripe about people using python's isinstance standard lib function, which is really what these guys are complaining about.

I have been known to use it, as well as try/except blocks where my except is just "pass," but I'll put in like three solid lines of comments explaining exactly how I realize how I know it's generally considered poor form, but why it's the right thing to do here.

Tamin

So, on one of the K&R exercises, they wanted me to remove c-style comments. I resisted the obvious approach (if we see a /, check the next character for a * ) for a long time, because I dislike having 2-3 levels of nested ifs. I couldn't make a nicer one, so I did break down and do it this way; it seems to be working.

I had my brother write up a version and he did it the same way.

My question, I suppose, is - is there an easier way? Should I get over my dislike of ifs?

this dislike comes mostly from a co-operative shell script my class wrote in which a classmate decided it would be a grand idea to have something like 25 nested ifs.

3 lines worth of 'fi's

End

Tamin wrote: »

So, on one of the K&R exercises, they wanted me to remove c-style comments. I resisted the obvious approach (if we see a /, check the next character for a * ) for a long time, because I dislike having 2-3 levels of nested ifs. I couldn't make a nicer one, so I did break down and do it this way; it seems to be working.

I had my brother write up a version and he did it the same way.

My question, I suppose, is - is there an easier way? Should I get over my dislike of ifs?

this dislike comes mostly from a co-operative shell script my class wrote in which a classmate decided it would be a grand idea to have something like 25 nested ifs.

3 lines worth of 'fi's

You could use switch/case/default, if you wanted, but that's not that much different. I can see an implementation where you could almost completely avoid using ifs or switch statements, but I'm not sure what the point would be. (Basically, replace your ifs with lookup tables.)

Tamin

End wrote: »

Tamin wrote: »

So, on one of the K&R exercises, they wanted me to remove c-style comments. I resisted the obvious approach (if we see a /, check the next character for a * ) for a long time, because I dislike having 2-3 levels of nested ifs. I couldn't make a nicer one, so I did break down and do it this way; it seems to be working.

I had my brother write up a version and he did it the same way.

My question, I suppose, is - is there an easier way? Should I get over my dislike of ifs?

this dislike comes mostly from a co-operative shell script my class wrote in which a classmate decided it would be a grand idea to have something like 25 nested ifs.

3 lines worth of 'fi's

You could use switch/case/default, if you wanted, but that's not that much different. I can see an implementation where you could almost completely avoid using ifs or switch statements, but I'm not sure what the point would be. (Basically, replace your ifs with lookup tables.)

I think I see. Thanks.

Senjutsu

Tamin wrote: »

So, on one of the K&R exercises, they wanted me to remove c-style comments. I resisted the obvious approach (if we see a /, check the next character for a * ) for a long time, because I dislike having 2-3 levels of nested ifs. I couldn't make a nicer one, so I did break down and do it this way; it seems to be working.

I had my brother write up a version and he did it the same way.

My question, I suppose, is - is there an easier way? Should I get over my dislike of ifs?

this dislike comes mostly from a co-operative shell script my class wrote in which a classmate decided it would be a grand idea to have something like 25 nested ifs.

3 lines worth of 'fi's

You could avoid the nesting by taking the approach lexers do (build an FSM - read one character at a time and transform state based on some tables), since basically you're being asked to build a specialized lexer for one token. But it's overkill.

giltanis

Senjutsu wrote: »

Tamin wrote: »

So, on one of the K&R exercises, they wanted me to remove c-style comments. I resisted the obvious approach (if we see a /, check the next character for a * ) for a long time, because I dislike having 2-3 levels of nested ifs. I couldn't make a nicer one, so I did break down and do it this way; it seems to be working.

I had my brother write up a version and he did it the same way.

My question, I suppose, is - is there an easier way? Should I get over my dislike of ifs?

this dislike comes mostly from a co-operative shell script my class wrote in which a classmate decided it would be a grand idea to have something like 25 nested ifs.

3 lines worth of 'fi's

You could avoid the nesting by taking the approach lexers do (build an FSM - read one character at a time and transform state based on some tables), since basically you're being asked to build a specialized lexer for one token. But it's overkill.

You could also read two characters at a time but only advance the pointer/iterator one character at a time. That way you just do a singe comparison per iteration. Not sure its worth the effort though.

Or use a Regex library and be done with it

CangoFett

So C++ is all "Man im all C++ whatchu gon'do 'bout it cango?" and im all "C++ I WILL LEARN YOUR FACE OFF"

So I started to, but now the book is like, I dont even know. Maybe behind me? I cant be bothered to spin. And then its gonna be all, "AHAH Wheres your enumerating constants and sizeof operators now?!" and I'll be "C++ book I dont even know what that is why dont you tell me" and it may be like "okay" but man.


Learning is hard.

bowen

Reading about C++ is incredibly dry and tends to teach you a lot of useless fluff for "practical" programming.

I swear to god, the people who write the books for C++ need to be shot, usually. But what exactly are you having issues with?

Apothe0sis

Man, Microsoft is just.

I don't know.

Powershell does a lot of things right. But somehow, they manage to violate the principle of least surprise no matter what they do. There's always some baffling exception to the behaviour of anything they do.

This time it's arrays of arrays.

Clearly, the Microsoft Principle of Least Surprise is that they always have to violate the principle, somewhere, lest we be surprised.

CangoFett

Its the boring building blocks of "practical" stuff that will be useful later but right now is liek

Oh wow

Sizeof ints

how titilatting.

This crap gets useful and relevant later, right?


Also my wife keeps moving my book from my cluttered desk to my non cluttered book shelf

what a jerk

Apothe0sis

CangoFett wrote: »

Its the boring building blocks of "practical" stuff that will be useful later but right now is liek

Oh wow

Sizeof ints

how titilatting.

This crap gets useful and relevant later, right?


Also my wife keeps moving my book from my cluttered desk to my non cluttered book shelf

what a jerk

Women.

Can't live with em, can't even pee standing up.

bowen

CangoFett wrote: »

Its the boring building blocks of "practical" stuff that will be useful later but right now is liek

Oh wow

Sizeof ints

how titilatting.

This crap gets useful and relevant later, right?


Also my wife keeps moving my book from my cluttered desk to my non cluttered book shelf

what a jerk

Sizeof was big in C with malloc and dealloc. Though, it's useful for arrays.

But, short of that, it's practical uses are pretty much non-existent. Binary output/transfer is another big reason for it, but unless you're moving between different compilers or systems, it's pretty much not a worry. But different systems can include Windows32 and Windows64, so keep that in mind as well.

Now everyone knows why I like C# for practical uses, so I don't have to worry about that shit as much.

CangoFett

I need a new monitor. I just typed up a whole post about my book being a jerk and a butt and then realized that - and = looked the same on my screen. it wasnt until I posted it here that I saw my stupid typo.

Fodder

So writing this malloc implementation in C after not using it for 4 or 5 years was going at a frustrating pace, but the --no-warnings gcc flag is making it slightly more bearable. No really, I do want to increment that struct pointer and then cast it to another type to edit flags, thank you.

bowen

Why would you get warnings about that? That seems odd.

Fodder

Initialization/assignment from incompatible pointer type

bowen

Mind sharing the code? I'd like to see that.

Fodder

((f_block_lp)((b_headerp)(b)+1))->next is one of the macros I have that it's not overly fond of.

f_block_lp and b_headerp are pointers to two different types of structs, and next is of type b_headerp as well. The block header for the chunk of memory is always the first thing, and if the block is free the next bit of memory will have pointers to the previous and next free blocks in a list, and those point to the header of the block. It's not very pretty, but hiding it all away in a macro has alleviated a bit of that for me.

bowen

Personally, I'd try to mimic inheritance/polymorphism in C as best as I could to eliminate issues like that.

GnomeTank

Yah, but he's writing a malloc implementation, where he probably want's pure speed. In that case, relying on the memory ordering is okay, especially since you're doing the malloc, and controlling what sits in each bit bucket.

bowen

Everytime someone says "I use C for pure speed" I sigh, because 9 times out of 10 it's someone on a windows box using GCC wishing they could use linux but are staying in windows for games. (I've had a dev argue with me for hours that C is better than C++ and we should use it for a library that deals with OOP almost exclusively -- that is rewrite it for C, to implement OOP in C as well).

Is this an embedded device where speed/size are limiting factors? If not, I'd bite the bullet and take the liberty to implement polymorphism in C.

I'm still raging at the dev who argued with me about C though.

GnomeTank

What? It's not using C that's allowing him pure speed, it's what he's doing (which you could do with a C++ compiler, though it would bitch even more than the C compiler would, especially with pointer arithmetic).

And if you honestly thought it would be okay to slow down your malloc implementation with polymorphism, embedded device or not...I'm not sure what to tell you. Malloc is the heart of everything a C-based stack does, and if it's even a millisecond too slow, every program that touches it (aka almost all of them) will feel it.

bowen

GnomeTank wrote: »

What? It's not using C that's allowing him pure speed, it's what he's doing (which you could do with a C++ compiler, though it would bitch even more than the C compiler would, especially with pointer arithmetic).

And if you honestly thought it would be okay to slow down your malloc implementation with polymorphism, embedded device or not...I'm not sure what to tell you. Malloc is the heart of everything a C-based stack does, and if it's even a millisecond too slow, every program that touches it (aka almost all of them) will feel it.

Like I said. The real world applications and ramifications are pretty non-existant.

Otherwise everyone would write everything in C. And as you can see, that's really not the case.

These kinds of statements really boil it down to "Fuck you C++ is better" or "Fuck you _X_ is better." Because they're relatively baseless except for certain extreme conditions.

Like space or speed considerations that are important, and not baseless because you'd like to save a microsecond, if that.

GnomeTank

I...don't even understand what you are trying to say at this point. I think you're saying it's okay to make a really slow, but pretty and polymorphic, malloc implementation, because there are no real world use cases for a fast malloc? I think?

Honestly, I'm lost.

And for 90% of things, C++ is superior to C, especially for "real applications"...but a malloc implementation is one of those cases where the raw minimalistic nature of C really shines.

Infidel

He's saying it doesn't matter at all to him and it really doesn't.

If he's going to try to extend that on everyone else he'll really have a hard time explaining that though.

bowen

Basically.

I was stating that getting compiler warnings probably isn't the best practice. I was then saying that he may have better luck with a polymorphized data type to eliminate them.

As for his implementation of malloc, we don't know what he's doing. He could be flossing his ass with a gstring while coding a dynamic data. Or he could be doing something where speed is of the essence. Which is why I also asked, if speed was of the essence.

Then, someone came in and went, "HURGLGEBURGLE SPEED IS GONE NOW" so I switched into asshole mode.

But you're right, I'll just not offer some simple advice to help someone that said they were getting errors with casting. That's a horrible idea, I should ignore giving advice on everything until I know the exact details of his system, his code, and whoever else happens to be reading because they'll have a different idea and/or not like that my idea disagrees with theirs on a fundamental level.

Right? Okay.

So yes, I would polymorphize the shit out of that code.

GnomeTank

I guess what I was saying is that your assumption that making malloc slow is okay just to get rid of compiler warnings, and make the code polymorphic, is somewhat flawed. Making malloc slow, for any reason, is very bad. You are talking about a function that is called millions of times in very small time segments on most computers. Being even a microsecond too slow cascades out of control very quickly.

You are right on one thing though: We have no idea what he's trying to do with his malloc. He could be writing a tracing malloc for debugging where speed is mostly irrelevant.

Fodder

It's for a school project, so C was enforced and it isn't really a bad choice for the whole thing. I'm not planning on doing anything with it after I get it going well enough to successfully work on some test cases, so keeping it maintainable isn't my number one priority.

Phyphor

It's not even that C++ is any slower really unless you use the features that explicitly make it slower. And even with that stuff, could you create C code to do the same thing more efficiently?

Any time I want to write C-like code for some reason I find it much easier and cleaner to do in C++ with member functions, overloaded operators, data hiding and inheritance than in pure C.

As far as pointer arithmetic differences, the only thing I can think of is not allowing void* to autocast to any other pointer.

GnomeTank

Actually 'virtual' (aka polymorphism) does cause speed slow down, as the vptr has to be munged to find the correct overload to call. That's why I pointed out that making a malloc implementation polymorphic, with operator overloads and inheritance is probably a bad idea. Yah, it may only take a couple of micro seconds to munge a vptr and find the correct overload (I can even show you code for how to do it manually, outside of the compiler generated code), but take those micro seconds and multiply it times a billion. Now you're not cookin with the same fire you thought you were.

Note: Yes, I am aware that modern compilers (g++ 3+ and VC8+) output incredibly optimized polymorphic code, but it's still not free.

GnomeTank

Also, I thought I might add, I love me some C++...so before anyone thinks I am being a hater, or just dogging on C++. Not so much. I am just a big proponent of "right tool, right job". Same reason I write sysadmin scripts in Ruby, not C++. I could do it in C++, but Ruby is a far easier tool to work with for that purpose.

Phyphor

Oh I know virtual functions have a hit and how they work, it's just a simple list of function pointers. But, for simple type hierarchies you can almost always get away with a single cast at the API boundary to a known type and then let the compiler do most of the pointer manipulation for you as needed. And that has no overhead. You can do the same in C of course, it just involves more casting and you have to explicitly pass this.

Yeah, full polymorphism would be overkill in this case, though there are legitimate uses for that in this scenario as well (override free or operator delete for objects allocated from different heaps for example)

GnomeTank

I agree, but why would you be overloading new and delete when implementing malloc? Your overloaded new probably relies on malloc (or an alternative heap malloc-esque call, maybe nedmalloc or something) to allocate the raw memory it uses.

In fact, OGRE does this very thing to call nedmalloc instead of sysmalloc.

Phyphor

Well, not for the operations on a specific heap, no, but if you had a special heap you allocated some stuff from (shared or mapped memory most likely) or with a different allocation strategy (buddy heaps, large/long term allocations) and still wanted to be able to use the same calls for everything you would need the whole malloc/free or new/delete implementation to do a vptr call into the specific heap code.

Jasconius

I'm building an iPad prototype for work. With a deadline of next week. They told me... today at 3PM.

So

Red Bull!

GnomeTank

Hmm, the shared memory idea is interesting...though probably impractical on Windows which bases it's shared memory on memory mapped files. Not sure how Linux does it, but could be an interesting feature though...being able to allocate from shared memory rather than copy to it. Could save some processor instructions in speed critical apps that use a lot of shared memory.

Phyphor

Yeah, I played around with a prototype a while ago, any app with appropriate permissions could open up the shared region and allocate objects in the shared region using a placement new arena allocator. Another app could come along and use or delete it and cleanup happens properly. The only caveat is that everything in that region needs to allocate from shared memory to avoid stray pointers, so you have to give all the stl stuff custom allocators and such.

It required some trickery to find a suitable free region to achieve pointer-compatability across all the apps though, definitely not guaranteed to always work, especially with address space randomization. Handle sharing was also painful. Haven't found any real use for it beyond just playing around.

Shared memory in windows is file based, but if you don't give it an actual file it's pagefile backed, like any other memory. I think in linux you ask for a block of shared memory and that becomes a file other programs can open to get access.