|
I'm trying to straighten out some pointer "arithmetic" in some existing code. The expressions themselves are overly ambiguous to say the least. In part of my readings, I've come across the "auto" keyword where the compiler deduces what type I need. At least that's what I got from all of the verbiage.
This seems a) dangerous and b) adds another level of mental indirection to what you are trying to accomplish. To me, software needs to be very clear and explicit in what data you are working with and what you intend to do with it. A lot of the "here is how auto will help you" descriptions justify it by saving typing when trying to make use of other classes, templates and the like. It feels like the C++ committee came up with a feature A then added feature B to make using A easier. I'm now doing battle with lambda expressions - another story.
So, in your code - do you make extensive use of auto, and how does it help you?
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
charlieg wrote: do you make extensive use of auto,
Not "extensive" but I use it frequently. In some cases there is no way to go around it (when you have a lambda closure for instance), in other cases it is just convenient (like long container iterator types), and in a few cases it is surprisingly useful. One such case is in combination with IntelliSense when I have doubts about the final type of an expression. I do something like:
auto var = and, when I hoover over var, IntelliSense will obligingly tell me what the compiler thinks the variable type is. I know it's a bit silly (and maybe lazy) but hey, it helps me.
How I learned to stop worrying and start loving the auto 
Mircea
modified 2 days ago.
|
|
|
|
|
Mircea Neacsu wrote: IntelliSense will obligingly tell me that the compiler thinks it the variable type.
I think this is the best use for auto in C++ or var in C#.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
I haven't touched C/C++ in a long time, but C# has the similar var. I used to use it until I recognized how unreadable it made code. It forces you to know more than you really need to know and is, frankly, a lazy way to write code.
I do still use it but only in the lazy way of using Intellisense to figure out what the actual type is supposed to be and give me the option of replacing var with the actual type. It has recently come in handy last week when using an API client library generated by Swagger code gen and the holy-sh*t-those-are-long-class-names it generated. The longest is 86 characters long, and average about 40-45. I'm not typing those. I have to get the code working this week, not next year.
|
|
|
|
|
I use it.
Suppose you have
unordered_map<string, int> um{ {"foo", 1}, {"goo", 2}, {"boo",42}};
I find
for (const auto & p : um)
{
cout << p.first << ", " << p.second << "\n";
}
'somewhat simpler' when compared to
for (const pair<string, int> & p : um)
{
cout << p.first << ", " << p.second << "\n";
}
Maybe I am used to it.
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
The only time I don't use auto is to override the type that the compiler would deduce. That's very rare, usually with the size of a numeric. auto is almost always a type returned by a function, or maybe the type of a class member, so there's nothing "dangerous" about it in those situations. Someone reading the code needs to be familiar with the functions and classes being used, or they're fooling themselves as to their level of understanding.
|
|
|
|
|
I use auto as much as I can.
I will still use types for POD.
I also use variable names that makes sense so that I know what type the variable should be (obviously not hungarian reverse or not notation)
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
POD?
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
Plain Old Data.
usually simple types like int, char, float...
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
It appears to me that you may be doing much programming that doesn't really fit into a strong, static typing world. Maybe a dynamically typed language, with any variable having the type of its value (at any time) would suit your problems better.
I love the strictness of strong static typing. It makes it possible for the compiler to give me far more detailed and to-the-point error messages and warnings. When reading the code, it provides more information, making it simpler to comprehend the code.
There are situations where auto/var is required, e.g. in database operations; I am not objecting to using in in such cases. In most cases, you can extract the values to strongly typed variables. I do not leave them in untyped variables for long.
Corollary, I try to avoid deep subclass nesting. Choosing between having to inspect 4-6 superclass definitions to find the definition of a field (hopefully with a comment explaining its use) or extending a superclass with a field that for some instances are left unused, I definitely prefer the latter. (I have many times seen subclasses created for adding a single field - even with several sibling classes adding the same single field!)
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
I think you're confusing things up.
C++ is still strongly typed even when you use auto.
when I declare a variable with auto, it will be typed accordingly and I cannot change the type.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
In my world - close to hardware - it's important to know and understand the type. Sure, if I'm using a modern IDE with Intellisense (only one comes to mind) auto might help. But, because of the proximity to hardware, we really don't use complex C++ types. Shoot, the last time I tried to use a C++ map, it was 10x slower than a simple linear search loop. I did not believe it at first...
But getting back to using auto with it's intellisense interaction, intellisense does it's thing for plain and complex types as well. I'm not sure what the point it (other than reduced typing).
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
Maybe someone can point me to a reference or provide direct experience. I'm trying to lift a VC6++ application to VS2022. Originally targeted at Xp, this will need to run under Win10 and 11. So, I thought it would also be a good idea to get it into a modern development environment.
Well, the # of warnings I am suppressing is getting concerning, but I understand what the warnings are about. Then I ran into this line of code:
"ON_NOTIFY_REFLECT(NM_CUSTOMDRAW, OnCustomDraw)"
pure mfc macro which generates "....cpp(66): warning C26454: Arithmetic overflow: '-' operation produces a negative unsigned result at compile time (io.5)."
Mousing over the macro, it expands to some hideous expression: "{ 0x004E + 0xBC00, (WORD)(int)((0U - 0U) - 12), 0, 0, AfxSigNotify_v, (AFX_PMSG)(static_cast<void (ccmdtarget::*)(nmhdr*,="" lresult*)=""> (OnCustomDraw)) },"
It's clear why the compiler is alarmed: "(WORD)(int)((0U - 0U) - 12)"
Am I just wasting my time here? I'm going to thunder on, but I'm starting to wonder if I'm going to run into so much nonsense like this that it calls into question if I'll have anything working at the end....
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
charlieg wrote: Then I ran into this line of code:
"ON_NOTIFY_REFLECT(NM_CUSTOMDRAW, OnCustomDraw)"
pure mfc macro which generates "....cpp(66): warning C26454: Arithmetic overflow: '-' operation produces a negative unsigned result at compile time (io.5)."
Mousing over the macro, it expands to some hideous expression: "{ 0x004E + 0xBC00, (WORD)(int)((0U - 0U) - 12), 0, 0, AfxSigNotify_v, (AFX_PMSG)(static_cast<void (ccmdtarget::)(nmhdr,="" lresult*)=""> (OnCustomDraw)) },"
It's clear why the compiler is alarmed: "(WORD)(int)((0U - 0U) - 12)"
Am I just wasting my time here? I'm going to thunder on, but I'm starting to wonder if I'm going to run into so much nonsense like this that it calls into question if I'll have anything working at the end....
1. It's not a compiler but IntelliSense alarm.
2. Yes, you are just wasting your time here. Just don't worry if the real compiling doe not show it as an error.
|
|
|
|
|
thank you.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
"Waste of time"?
If you're having fun doing this I'd say it's never a waste of time (doing this). That said, I'm reading WORD and thinking "If I ever get back into developing that QBASIC code (of mine) in that project in C++ where I've already got executable stubbs of function tests (vastly complex mathematical calculations made in lengthy formulas (astronomical in the sense of astronomy itself)) pasted into the VS interface, line numbers included (before QBASIC includes!), I'll probably have to go through MFC VC6++ in the stackoverload and codeguru websites to do the conversions and encounter this very issue".
Do you mean DWORD? I think I get "0U" ... 
I'll fire up VS now, sir ... (firing up vs now) ... "C26454" ... uhm ... hangon ...
|
|
|
|
|
I think something was mangled in the translation. I took: "Yes, you are just wasting your time here. Just don't worry if the real compiling does not show it as an error." which I took to mean not fret about the warning.
I really need to lift this code, and working with VS2022 is "interesting." I've never seen a compiler generate so many arcane errors due to a typo. At the moment, I am trying to figure out why VS2022 is upset with '_messageEntries': const object must be initialized. It really has nothing to do with _messageEntries (this is an MFC thing) but more to with an error a few lines up.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
Ok, sorry about that. I just stoked up VS2022 and looking in the help found the WORD initializer. Who knew? Although I guess I was on a "Joan of Arcadia" type of bender in my sarcastic musing, I've since settled on refraining from CP commenting for my own good and am turning over this new leaf by announcing it here in the C/C++/MFC forum where there's probably less of an iota of confusion not of my own making.
Tyll should be good. Again, sorry.
|
|
|
|
|
it's been a loooonnnggg time since I converted/upgraded a MFC application.
If I remember correctly, signature changed for a lot of MFC messages and callback functions.
you need to check the documentation for each of those messages.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
tracked down the one thing that was plaguing me.
Documentation? f***, all I can find are useless Microsoft help articles that are just informational to the point of flying you into the mountain. Return me to the days of DEC, where one bookcase help the complete knowledge.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
well, you can just read the header files.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
lol, true. But going into the mfc afx, etc header files where "those people" took macros to an art form (I'm being generous) is tedious.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
Hi there,
i have a question regarding C++ "language updates", to phrase properly what i want to know:
We currently have an external employee that codes C++ Libraries for us, which are used for "drivers" to ensure communication via Ethernet, USB and Bluetooth.
Those libraries are currently only available as 32 Bit dll's and therefore created a discussion after we found out that in some cases we would as well need them as 64 Bit.
To get to the point, said collegue also mentioned, that those libraries are ensuring a downwards compatibility to run on systems below windows 10 (which is our current limit of support), namingly they run even on Windows XP and probably further down, written with VS 2005 iirc.
Since i am .NET developer i can not really grab the necessity for doing so, nor estimate the potential "risks, flaws or performance" related topics comming up with that compatibility.
So i want to ask you if my concerns are correct or totally wrong, when it comes to using "very old" C++ instead of modernizing it and only ensuring runtime compatibility to "current" OS'es.
I personally feel that, since C++ get's updated every now and then, there must be a reason for doing so, as well as ofc improving the final produce that get's spit out by the compiler if your using newer (not newest) C++ Versions.
As a bonus, if someone could take the time to answer this as well, would you suggest, think about or deny switching code parts into C# and .NET which probably could be switched due to framework functionalities where we can rely on the stuff microsoft already has built in there?
As a note: We leave aside the fact that nobody else from the team would have hardware to continue coding or even compile this old stuff.
In any case, thanks alot for reading and / or answering.
Rules for the FOSW ![ ^]
MessageBox.Show(!string.IsNullOrWhiteSpace(_signature)
? $"This is my signature:{Environment.NewLine}{_signature}": "404-Signature not found");
|
|
|
|
|
This is really a broad topic.
I am only able to just write down few observations.
C++ language updates are not bug-fixes: they improve the language. If you are going to start from scratch a new project then using modern C++ is a real advantage. On the other hand, migrating an old big (working) project could be painful.
If you need a 64bit DLL, you colleague could probably build it without using newest C++ features. Maybe he can, at the same time, keep the existing 32bit DLL, two builds of the same code.
If Microsoft provides me the same functionality my mates code do, by no means I would continue using the latter.
Does the compatibility argument applies also to your .NET code? I mean, DLL compatibility with old OSs is useless if you cannot run the application on such systems.
My two cents.
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
Thanks for the answers, that lit up some dark corners for me.
His proposal is to do simply convert the necessery stuff for 64 bit aswell so he'll provide both for us, not changing or modernizing anything.
That's what i would have guessed, an example given, we have code for BLE communication in such a library, i know that Microsoft API or respectivly .NET has a lot of Code and Features provided for BLE communication. SO my idea was, since he knows both worlds, to take the effort and convert to .NET, at least the things that are possible, he wasn't happy...
No, i hope i mentioned it but our application is bound to another external application that standardises things. Therefore we are only supporting Win 10 and 11 because said "Frame Application" is only running on those two.
Thanks again for your answer 
Rules for the FOSW ![ ^]
MessageBox.Show(!string.IsNullOrWhiteSpace(_signature)
? $"This is my signature:{Environment.NewLine}{_signature}": "404-Signature not found");
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
