|
constexpr static const int life_the_universe_and_everything = 42;
To err is human. Fortune favors the monsters.
|
|
|
|
|
Didn't expect less: west coast, shall be west const 
Mircea
|
|
|
|
|
Single Step Debugger wrote: Type* p;
As I recall it there was a column from I believe the 'C++ Users Journal' which pointed out that the following...
int i;
Is the same as
<type> <variable>
So thus a pointer should be laid out as specified in the same way. That is if one needs a rationalization for it.
|
|
|
|
|
Yeah, but in
int x, *y;
is the * part of the type declaration or the variable declaration? If it is part of the type declaration, then type of y is declared in two parts, with an interspersed (and rather irrelevant) variable declaration.
Is that very rational? It is valid C!
|
|
|
|
|
The discussion is subjective as was the opinion of the columnist to which I referred. But as an authoritative opinion (as a columnist) the argument did provide a specific rationalization.
trønderen wrote: int x, *y;
I don't code using that form. And I very, very seldom see it used or even a case where it might be used. So as a rationalization for doing it all the time it does not seem to be very valid.
|
|
|
|
|
I've always preferred "Type *p" over "Type* p". To my mind the "pointer-ness" is a property of the variable and not the type.
Of course, I've also hated this: typedef Type* TypePtr. If values are declared as TypePtr and you are using pointer-dereferencing with those values, the typedef obfuscates the original type.
And before anyone pops up with "but what about...", I think typedef BaseType* OpaqueType is perfectly fine, when you're not using values of OpaqueType as pointers.
Software Zen: delete this;
|
|
|
|
|
A problem with
typedef Type* TypePtr; is that if you declare
const TypePtr p; it is p (the pointer itself) that is const, not Type. This can be confusing, so I avoid it.
|
|
|
|
|
Good point. To my thinking const-ness, like pointer-ness, are properties of the variable and not the type.
Part of my dislike for that sort of thing is people use some kind of naming convention (xxxPtr, xxxCPtr,...) that indicates the variant of the type. It pollutes the name space with additional identifiers you need to recognize. This replaces fundamental language syntax which is consistent by definition with arbitrary naming that may or may not be consistent. I've also noticed that the typedef overusers also tend to cast those types, often using language syntax, to other typedef's they've forgotten.
Software Zen: delete this;
|
|
|
|
|
I often define a typedef for a template instantiation, to keep the type succinct:
typedef std::unique_ptr<Class> ClassPtr;
typedef std::vector<ClassPtr> ClassPtrVector; And then there are things like
typedef int main_t; typedef int signal_t; typedef uint16_t ipport_t; which do a much better job than simple int types when documenting, or searching for, data and functions that deal with these things.
|
|
|
|
|
Thanx for this introduction to computer language pointer constructs specifically related to C. True C++, C# are involved. The string of discussion was quite interesting.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
I never met any convention that specifies pointer declarations so I use
Type* p; I learnt with Type *p; but I always found it more complex to understand: after all that identifier holds a pointer to p, so it's type is pointer. Same for Type** p.
Only sometimes I mix them around if there are readability reasons, for example Type** *p; can be in my opinion more readable if p holds a pointer to a matrix (i.e. if you need to return a matrix allocated by the callee, switch the matrix to send to the callee based on something, etc).
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
So which type of convention do you use when naming variables with multiple words?
* camelCase
* PascalCase
* snake_case // Rust requires this for variable, function and struct member names and the compiler will warn (gripe at you) if you use other. I really like Rust, but this drives me crazy because it is YAC (Yet Another Convention)
Back in C++ & C# I always used PascalCase
Then in recent years JavaScript has effected my mind and I use a lot of camelCase these days.
Kotlin (Android dev) & Swift (iOS dev) seem to use camelCase too. So it becoming kind of a standard.
How about you?
See more here[^].
modified 12-Dec-22 11:36am.
|
|
|
|
|
camelCase for static / private / local members, PascalCase for public members. Globals, where needed, are g_CamelCase.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
Depends.
Mostly camelCase for local and parameter variables, PascalCase for properties and methods, with a little Hungarian thrown in for contols: butOK, tbUsername, ...
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OriginalGriff wrote: with a little Hungarian thrown in
tut tut...
I'll have to give you 5 demerits for that.* 
*Had to say it, because I was a huge Hungarian-follower for so many years (remember all them Windows API calls?) and then they rugged us telling us to stop it. I was damaged from that. 
|
|
|
|
|
OriginalGriff wrote: with a little Hungarian thrown in for contols: butOK, tbUsername
Hush, it's ok, VisualBasic will hurt you no more...
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
Programs should be read as books. What would you prefer, aBookThatIsTypesetInLongWordsAlmostLikeGerman, or a_more_relaxed_one_that_leaves_spaces_between_words?
PS: Is it St. Sterile de Bates Day today?
Mircea
|
|
|
|
|
Writing snake_case variables is annoying, freaking underscore needs a double keypress after every word. I'd love it if it wasn't so cumbersome.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
Hmm, on my keyboard Caps also need a double keypress
Mircea
|
|
|
|
|
True that, but one hand remains on the letter portion of the keyboard. I find it easier, also more compact. Though snake_case helps understanding.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
I know I'm not going to win this argument but on my keyboard, underscore is right above the P. I promise I'm not going to continue this argument
Mircea
|
|
|
|
|
Another reason that made me dislike underscores (the the first one is hardcopy readability): Although you are right about upper case also being a double stroke, both the shift and the letter have identical positions on all keyboards, and you can keep your hands in the same position (as long as you have learned to use your left pinky for the shift key).
If you switch between different keyboards - especially keyboards adapted to different languages - punctuation and special characters such as underscore jumps all over the place. It took a few years to define a Norwegian standard placement for all those new characters that came with PCs, unknown on traditional typewriters, so if I dig up my oldest keyboards, even on Norwegian keyboards, they jump around. Using a Norwegian keyboard at home, a US English one at the office, and sometimes some machinery with its own keyboard layout, can be very frustrating.
Nowadays, on a Norwegian keyboard, underscore is shift-hyphen, the rightmost key in the bottom row, next to right shift. You have to move your right hand three-quarters off the keyboard to hit it. (That also goes for hyphen, even if it is un-shifted.)
|
|
|
|
|
trønderen wrote: to define a Norwegian standard placement for all those new characters
You, guys have too many characters in your language! Just get rid of those! (says he, whose mother tongue has 5 extra characters... or 10 if you count the caps form).
Mircea
|
|
|
|
|
You didn't keep your promise ...
|
|
|
|
|
That's actually a very good point.
It's probably just
1. the jarring nature of it (diff from past)
2. all those extra characters (_)
You've really made a great point here though & you've got me thinking. 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
