C vs C++

[cytg111]

reversing c++ you keep track of class pointers .. these pointers have to be carried around, that costs a little, but relative to overall performance i dont know what numbers we're talking about .. 0.001% ? in essence C speed == C++ speed, in practice. On the other hand its easier to write more bloated inefficient code in c++ I guess.. A standard does not substitute a good head/design.

 

[irishScott]

reversing c++ you keep track of class pointers .. these pointers have to be carried around, that costs a little, but relative to overall performance i dont know what numbers we're talking about .. 0.001% ? in essence C speed == C++ speed, in practice. On the other hand its easier to write more bloated inefficient code in c++ I guess.. A standard does not substitute a good head/design.

That and if you're working in a super-embedded environment it helps to not drag the STL libraries along, but given the density of modern memory that's becoming more and more irrelevant.

 

[Tweak155]

That and if you're working in a super-embedded environment it helps to not drag the STL libraries along, but given the density of modern memory that's becoming more and more irrelevant.

Yeah not gonna lie... sometimes I'll recognize I'm doing something inefficiently but I'll consider the end users machines and the current task at hand and just not care. Sometimes it is because I know the re-write could take me hours and sometimes its just because I *know* there is a better method and I'm not sure what it is, but I don't care to seek it out

EDIT:

I always strive to have a very efficient method identified before even starting, but I can't be the only developer that gets part-way or far into the task and realize "Oh snap, this other way would have been much better"...

If you're a developer that *NEVER* runs into that scenario, you need to demand top dollar.

 

[Train]

Yeah not gonna lie... sometimes I'll recognize I'm doing something inefficiently but I'll consider the end users machines and the current task at hand and just not care. Sometimes it is because I know the re-write could take me hours and sometimes its just because I *know* there is a better method and I'm not sure what it is, but I don't care to seek it out

EDIT:

I always strive to have a very efficient method identified before even starting, but I can't be the only developer that gets part-way or far into the task and realize "Oh snap, this other way would have been much better"...

If you're a developer that *NEVER* runs into that scenario, you need to demand top dollar.

Premature optimization....

 

[Tweak155]

Premature optimization....

And how do you expect to optimize when to optimize?

Outside of being the owner of the entire project, you get twists and turns during the entire lifecycle.

 

[Cogman]

And how do you expect to optimize when to optimize?

Outside of being the owner of the entire project, you get twists and turns during the entire lifecycle.

Get something working,
if performance is a problem profile,
re-write slow code.

Rinse, repeat.

Notice, you don't profile until performance is a problem. Pushing it off guarantees you aren't wasting man hours worrying and rewriting something that only occupies 0.01% of the performance of an application. You'll find that 90% of your application time is spent on 1% of the code.

Certainly, if fast code is natural code, write it. Just don't spend the brain power trying to make things fast which provide little to no speed/usability benefits.

 

[Tweak155]

Get something working,
if performance is a problem profile,
re-write slow code.

Rinse, repeat.

Notice, you don't profile until performance is a problem. Pushing it off guarantees you aren't wasting man hours worrying and rewriting something that only occupies 0.01% of the performance of an application. You'll find that 90% of your application time is spent on 1% of the code.

Certainly, if fast code is natural code, write it. Just don't spend the brain power trying to make things fast which provide little to no speed/usability benefits.

This philosophy certainly would not fly where I work. Actually it does, but I look like a rock star when my code comes out zippity quick for all the stuff I work on. I think at least around here it gets noticed. A lot of the functionality I end up working on is for an already slow application, so when something new gets added and it runs sub 1 second, the end users think they saw Jesus.

EDIT:

The other problem with this philosophy is sometimes I'll take that approach - knowing I can re-write it to make it better but just want to get a demo going... then they take away my time to re-write it and it gets pushed to production. Sure it still works but it bugs the hell out of me.

 

[Train]

Writing something efficiently the first time doesn't qualify as premature optimization.

If I already KNOW I will need to concatenate 10,000 strings in this loop, I will START with a string builder or suitable equivalent, instead of waiting to see that string += blah in a loop too many times causes obscene memory usage.

But of course such knowledge comes from experience.

That is a very simple example. When things are more complex, like indexing and partitioning a giant database, you just have to wait and see. The actual usage is never quite what you expected, maybe there are way more writes vs reads than you expected, or the clients are pulling more/fewer records per page. Before spending too much time tweaking or rearchitecting, it's good to get see how an app performs under real stress.

 

[Tweak155]

Writing something efficiently the first time doesn't qualify as premature optimization.

If I already KNOW I will need to concatenate 10,000 strings in this loop, I will START with a string builder or suitable equivalent, instead of waiting to see that string += blah in a loop too many times causes obscene memory usage.

But of course such knowledge comes from experience.

Yeah... I'm probably just too anal. Most the time if I even see code that I can improve I get all antsy.

And to be clear, I'm not some senior developer worth his weight in gold. I'm an average to above average developer (depending what environment you sit me in) that does take an interest in what is actually being done behind the scenes. That alone usually puts me in the above average, but I still consider myself inadequate. There are just so many things you can work on / implement out there, I'll never see them all.

 

[Cogman]

This philosophy certainly would not fly where I work. Actually it does, but I look like a rock star when my code comes out zippity quick for all the stuff I work on. I think at least around here it gets noticed. A lot of the functionality I end up working on is for an already slow application, so when something new gets added and it runs sub 1 second, the end users think they saw Jesus.

EDIT:

The other problem with this philosophy is sometimes I'll take that approach - knowing I can re-write it to make it better but just want to get a demo going... then they take away my time to re-write it and it gets pushed to production. Sure it still works but it bugs the hell out of me.

I favor readability over optimization. Quite frequently, the two go hand in hand. However, not always. The problem with optimizations is that when you start to get deep into them, code starts to become mangled. This is why the philosophy of "optimize when it counts" pays off big.

I'm certainly not advocating that someone writes slow code to begin with, I'm advocating that they write maintainable code (Which, IMO, leads to code that is easier to optimize anyways).

The other problem with this philosophy is sometimes I'll take that approach - knowing I can re-write it to make it better but just want to get a demo going... then they take away my time to re-write it and it gets pushed to production. Sure it still works but it bugs the hell out of me.

How is your software distributed? Is it really impossible to refactor later? I mean, I guess if you are delivering software on disk or something, it might be a little challenging, however if it is a typical SAS situation this shouldn't be too big of an issue. (submit a case into the backlog and fix it when there is a lul)

 

[Train]

I favor readability over optimization. Quite frequently, the two go hand in hand. However, not always. The problem with optimizations is that when you start to get deep into them, code starts to become mangled. This is why the philosophy of "optimize when it counts" pays off big.

I'm certainly not advocating that someone writes slow code to begin with, I'm advocating that they write maintainable code (Which, IMO, leads to code that is easier to optimize anyways).

Very much this. Readability and maintainability (one usually flows from the other) should be top priority.

 

[Tweak155]

I favor readability over optimization. Quite frequently, the two go hand in hand. However, not always. The problem with optimizations is that when you start to get deep into them, code starts to become mangled. This is why the philosophy of "optimize when it counts" pays off big.

I'm certainly not advocating that someone writes slow code to begin with, I'm advocating that they write maintainable code (Which, IMO, leads to code that is easier to optimize anyways).



How is your software distributed? Is it really impossible to refactor later? I mean, I guess if you are delivering software on disk or something, it might be a little challenging, however if it is a typical SAS situation this shouldn't be too big of an issue. (submit a case into the backlog and fix it when there is a lul)

We do agile development so you're releasing code every 3 weeks (usually 1.5wks development, 1wk QC & UAT, .5wk document & release) and being assigned code for the next release. If you work on something not designated for the next release you get questioned. If it works, there is no sense in going back to work on it unless you get complaints. Also an entry in the backlog from a developer is a defect or else it comes from business.

And yes, I've yet run into a situation where the optimization did not go hand in hand with readability. I don't even want to get into my workplace problems, though.

 

[Train]

We do agile development

usually 1.5wks development, 1wk QC & UAT, .5wk document & release

The above two statements contradict each other. Dev, QA, and Documentation should be done together, with each specific card/ticket/task/whatever your team calls them traveling independently through the phases. But then a good regression test at the end is OK.

If you work on something not designated for the next release you get questioned.

No problem with that.

If it works, there is no sense in going back to work on it unless you get complaints.

Can only users make complaints? I watch error logs, and if I see a lot of slow load times on a particular component, I might ask some regular users "hey is the XXX page loading slow for you?" and I might get a response like "ya that page pretty much ruins my day, been slow like that for a while now" !!! users don't always report problems. But it still falls on us to provide them value. Sometimes we have to go looking for trouble and not wait for users to report it. Because if you wait, it could be FAR worse by the time users bother to report it. Or they may just assume your whole system sucks and switch to a competitor.

Also an entry in the backlog from a developer is a defect or else it comes from business.

You have to handle tech debt somehow. Make a tech-debt ticket type/tracker/whatever it called in your system, let coders throw a tech-debt ticket into the backlog whenever they see something, thn get back to whatever they were doing for the current sprint. Then commit to pulling at least one tech debt ticket out of the backlog at every sprint kick off.

 

[Tweak155]

The above two statements contradict each other. Dev, QA, and Documentation should be done together, with each specific card/ticket/task/whatever your team calls them traveling independently through the phases. But then a good regression test at the end is OK.

Possibly within your ignorance these statements contradict. Where did I specify they aren't done at the same time or in what order, or any information as to what your statements could possibly apply to? I simply provided a generalization to the time assigned per iteration for these tasks. If you take the times as exact as well, that's another faulty assumption.

No problem with that.

Thanks?

Can only users make complaints? I watch error logs, and if I see a lot of slow load times on a particular component, I might ask some regular users "hey is the XXX page loading slow for you?" and I might get a response like "ya that page pretty much ruins my day, been slow like that for a while now" !!! users don't always report problems. But it still falls on us to provide them value. Sometimes we have to go looking for trouble and not wait for users to report it. Because if you wait, it could be FAR worse by the time users bother to report it. Or they may just assume your whole system sucks and switch to a competitor.

We don't interact with users. Possibly another faulty assumption? Also when I say business, that is anyone on the business side. Management all the way down to users. Also, being an internally constructed IT software solution, we have no competition.

You have to handle tech debt somehow. Make a tech-debt ticket type/tracker/whatever it called in your system, let coders throw a tech-debt ticket into the backlog whenever they see something, thn get back to whatever they were doing for the current sprint. Then commit to pulling at least one tech debt ticket out of the backlog at every sprint kick off.

It's not tech debt if the business is unable to identify it as such.

Possibly you guys get to work in a more ideal environment (yes, that can also pertain to proper environments), but picking apart my work environment is both ignorant and arrogant (unless you are a developer here and I'm unaware). Perhaps it's my mistake of divulging any of that information to begin with, but I do like to discuss coding habits which is how this started. Unfortunately, neither of these pertain to the topic so we should probably just drop it anyway. Again, it was my mistake.

 

[Train]

Just trying to help. I don't think my assumptions were too far off based on the way you wrote them.

And I don't think my constructive criticism was arrogant either. More likely that you are overly defensive.

"We don't interact with users." ??? Sorry but that's just crazy talk. Especially from someone who said they are in an agile shop.

 

[Train]

It's not tech debt if the business is unable to identify it as such.

I disagree, and I say that with the least amount of perceived arrogance possible.

Tech debt is tech debt, even if no one has any idea it's there.

 

[Tweak155]

Just trying to help. I don't think my assumptions were too far off based on the way you wrote them.

And I don't think my constructive criticism was arrogant either. More likely that you are overly defensive.

"We don't interact with users." ??? Sorry but that's just crazy talk. Especially from someone who said they are in an agile shop.

Your assumptions ARE pretty far off. First off you state something is contradictory, indicating the two cannot happen at the same time. I tell you something takes place at my work, therefor it happens. This is where your arrogance defeats you. Rather, you should ask for clarification because I have stated it as fact that it is what takes place where I work.

And no, we don't interact with users. Again, a combination of ignorance and arrogance. But go ahead assuming I don't know my workplace.

Your criticism is not constructive. You fail to take what I say as fact, assume how my work place operates, then offer criticism based on your assumptions.

I disagree, and I say that with the least amount of perceived arrogance possible.

Tech debt is tech debt, even if no one has any idea it's there.

It was akin to saying "no cop no crime".

 

[Train]

Your assumptions ARE pretty far off.

oh man, chill the eff out, count to 10 and read carefully.

First off you state something is contradictory, indicating the two cannot happen at the same time. I tell you something takes place at my work, therefor it happens. This is where your arrogance defeats you. Rather, you should ask for clarification because I have stated it as fact that it is what takes place where I work.

I didn't deny you, I only stated that the original way you worded made my assumption fairly benign. Thank you for clarifying. Don't call me names because my original interpretation was off.

And no, we don't interact with users. Again, a combination of ignorance and arrogance. But go ahead assuming I don't know my workplace.

Again, I'm not arguing with you!, and I never did. I'm not saying "yes you DO interact with users!" I'm saying you SHOULD be interacting with users, especially if your shop claims to do agile. After all, the very first value in the agile manifesto is: "Individuals and interactions over processes and tools" If there is a disconnect between dev and the end users, this needs to be remedied. That feedback loop is paramount.

 

[Tweak155]

oh man, chill the eff out, count to 10 and read carefully.

Who says I'm not "chilled"?

I didn't deny you, I only stated that the original way you worded made my assumption fairly benign. Thank you for clarifying. Don't call me names because my original interpretation was off.

Please highlight where I called you a name. Perhaps you should take your own advice?

Again, I'm not arguing with you!, and I never did. I'm not saying "yes you DO interact with users!" I'm saying you SHOULD be interacting with users, especially if your shop claims to do agile. After all, the very first value in the agile manifesto is: "Individuals and interactions over processes and tools" If there is a disconnect between dev and the end users, this needs to be remedied. That feedback loop is paramount.

If you cannot see how this is worded in an argument fashion, I'm not sure I should even be replying. On what basis can you even qualify your statements? Where do I work, and why do I need to be interacting with end users? How is my work place structured to deal with end user complaints? This is what you should be asking before offering advice and well before assuming your advice is even superior. I'd argue our structure is more ideal than your suggestion, but then again we're not arguing

 

[Train]

Never mind. People with poor communication skills should probably not talk to users, not even internal ones.

 

[Tweak155]

Never mind. People with poor communication skills should probably not talk to users, not even internal ones.

Typical of someone who is unable to continue a conversation, but I agree with your statement. If you ever care to actually increase your knowledge, you can always ask why we don't need to communicate with end users directly. But don't hurt your pride in doing so.

 

[Train]

I can converse with people just fine. If you'd care to drop the idiocy and just respond like a normal person would.

 

[Tweak155]

I can converse with people just fine. If you'd care to drop the idiocy and just respond like a normal person would.

If you can pinpoint my "idiocy" for me, I will do my best.

 

[Train]

If you can pinpoint my "idiocy" for me, I will do my best.

Pretty much this whole post: http://forums.anandtech.com/showpost.php?p=35279132&postcount=39

Instead of repeating the ignorance and arrogance accusations over and over, clarify where your original post did not. Do that, and we'd be having a normal conversation.

Hint: "You don't know where I work" is not a clarification.

 

[Tweak155]

Pretty much this whole post: http://forums.anandtech.com/showpost.php?p=35279132&postcount=39

Instead of repeating the ignorance and arrogance accusations over and over, clarify where your original post did not. Do that, and we'd be having a normal conversation.

Hint: "You don't know where I work" is not a clarification.

That is rather broad, quite the opposite of pinpoint. Reading the post I feel it is very accurate, but possibly with harsh wording.

Where is my lack of clarification? Or better yet - what have I not answered / left open ended? Or even possibly, what don't you understand from the post?