Originally posted by: Markbnj
Holy crap, your professor is an anal retentive jerk.
maybe, but the situation does resemble the corporate world.
maybe, but the situation does resemble the corporate world.
Exactly. Ever see someone who learned how to program in C by reading the definitive K&R book and nothing else? You'd almost think it was a different language. There are accepted conventions for writing maintainable C programs, and using arrows like that is, or should be, one of them.
Oh, and all those annoying comments he's making you write? That's a habit you should try to keep, lame as it seems now.
Comments are a completely different matter. I've worked with maybe two other people in my career who sufficiently comment their code. I guess if I were going to rank style components in order of importance to maintainability it would go something like: 1) comments; 2) source formatting; 3) syntax conventions. If the first two are applied then the differences in personal approaches to syntax are of minor concern. Having one file use a->b where another uses (*a).b isn't going to slow me down, as long as the use in each module is consistent.
If the OP's prof. set clear rules, then OP should have abided by them. But if the rules weren't set out at the beginning, then I stand by my original assessment that the prof. is a dick.
And unfortunately that _is_ reminiscent of the corporate world.
If the OP's prof. set clear rules, then OP should have abided by them. But if the rules weren't set out at the beginning, then I stand by my original assessment that the prof. is a dick.
And unfortunately that _is_ reminiscent of the corporate world.
The corporate world is usually the one paying the bills. I don't tell my boss that I wrote something a particular way because I felt like it, I always come up with a reason citing performance or maintainability concerns.
IHateMyJob2004
Lifer
- Sep 29, 2004
- 18,656
- 68
- 91
degibson
Golden Member
- Mar 21, 2008
- 1,389
- 0
- 0
I would agree if what OP was doing was actually wrong. Its not. Not all coding style guides will say to use ->. Some will insist that -> be macro'd... some will insist on using only references, etc.
Just to stir up more of a hornet's nest, I don't think that operator-> or operator* should be used more than once for most pointers. I prefer to make it a reference instead, e.g.:
void Foo( Obj * p_obj ) {
.. Obj &obj = *p_obj;
.. ... // two or more uses of obj
}
Depending on the compiler, the above will probably make the same code as ->, (*)., etc., though has the same readability as if p_obj wasn't Obj* at all.
(again, the above is subject to external style guides, depending on your employer)
You're arguing that some guides and companies want you to use even more syntactic sugar than ->
Fair enough, but that implies (*foo) or foo[ 0 ] access to class/struct member variables is even more wrong from a clarity or style point of view, if the much more widely used -> isn't "good enough."
Fair enough, but that implies (*foo) or foo[ 0 ] access to class/struct member variables is even more wrong from a clarity or style point of view, if the much more widely used -> isn't "good enough."
^ except that when >99% of people hold the opinion that -> is the normal way of expressing access from a pointer, it becomes (more) correct even if (*foo).var1 compiles properly.
I haven't been trying to claim that (*foo).var1 won't compile or works less well, just that you shouldn't make your code harder to read by using using legal syntax that almost no one else would write. There is already enough to keep track of in code without having to do mental fixups for code that doesn't match the style of the rest of an application.
I'll agree that other style elements like indenting and naming schemes are going to vary from company to company, and won't always be rational . Event there, if a professor sets specific style rules then they do become the 'correct' rules for the length of the course, just as if the professor was your employer.
I haven't been trying to claim that (*foo).var1 won't compile or works less well, just that you shouldn't make your code harder to read by using using legal syntax that almost no one else would write. There is already enough to keep track of in code without having to do mental fixups for code that doesn't match the style of the rest of an application.
I'll agree that other style elements like indenting and naming schemes are going to vary from company to company, and won't always be rational
. Event there, if a professor sets specific style rules then they do become the 'correct' rules for the length of the course, just as if the professor was your employer.
degibson
Golden Member
- Mar 21, 2008
- 1,389
- 0
- 0
I'm not sure why you're claiming such a huge majority. After all, there are fewer than ten people posting on this thread, and at least one (myself) feels that -> is just as normal as (*x).y.
Moreover, majority opinions do not define fact. If they did, the Earth would be flat and we would all still be writing COBOL for a living.
I can't believe you're putting this much effort into this. You must feel like a salmon. Most (whether it's 80 or 99.999%) will use p->ele. If fact, I would guess a large proportion don't know that (*p).ele is equivalent to p->ele.
Remember, there's such a thing as being dead right.
Have you ever seen a magazine article or book using (*foo).var1 instead of -> ? I haven't, and I've been reading them since the DOS days.
That's probably why I'm a cranky geezer about this -- stay off my (*lawn) !
That's probably why I'm a cranky geezer about this -- stay off my (*lawn) !
But they do define the right way to do things in a company setting where code will be maintained by multiple employees and/or over years, usually both.
Cogman
Lifer
- Sep 19, 2000
- 10,286
- 145
- 106
I'll be honest, I've never seen ANY magazine that has c++ code in it, but that's just me I'm sure.
For a single element access, it really is pretty straight forward to do a (*p).data, and I would question someones programming abilities if it seemed impossible for them to maintain code with it. However, I could see an argument against multi-level data access. IE (*p).(*q).(*r) = 7. In that case I would say that p->q->r = 7 is easier to read.
degibson
Golden Member
- Mar 21, 2008
- 1,389
- 0
- 0
Of course there is, but I dearly enjoy the upstream battle.
Nope. The style guide defines that, which may or may not be the majority opinion. Its often the old story monkeys and the firehose. Probably not for -> v. (*x).y, however.
Edit: Trouble with nested quotes.
In which case the OP should get points for understanding something about the language that the bulk of his peers don't. I guess the bottom line for me is that the syntax isn't wrong. It's more voluble, overly clever, yes, but it's valid syntax and unless the prof. has made it clear in the past that he or she won't tolerate it, then the sentence didn't fit the crime.
So if it compiles it should be okay to just throw it around willy-nilly and throw up a middle finger to the person who has to slosh through that garbage in eight months?
http://en.wikipedia.org/wiki/Straw_man
Nobody has suggested doing so, or ignoring any established style guide in a corporate setting. I don't think it's reasonable to ignore the academic setting of the OP's question. He's supposed to be learning the language. I wouldn't want someone to come out of that class who _didn't_ know the equivalence of the two expressions we're debating.
When would it be proper, in your view, to dereference a pointer to struct before accessing it's fields? What if I had to access several of them in a row. Would it be ok then? Or am I bound to use pointer notation anytime I am handed a pointer?
Exactly. School is a place where you're supposed to takes chances and learn - not get shot down.
TRENDING THREADS
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 25K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes + WCL Discussion Threads
- Started by Tigerick
- Replies: 22K
-
Discussion Intel current and future Lakes & Rapids thread- Started by TheF34RChannel
- Replies: 23K
-
News NVIDIA and Intel to Develop AI Infrastructure and Personal Computing Products- Started by poke01
- Replies: 404
-
Facebook
Twitter