|
k5054 wrote: if the target CPU ...
True, but hardly relevant to the point I was trying to make.
And yes, I should have incremented the integer pointer - writing (poor) code in a hurry. 
|
|
|
|
|
Richard MacCutchan wrote: If you have something like the following:
For background I have 10 years of C and 15 of C++ after that so I do understand a bit of how it works. Not to mention wild forays into assembler, interpreters, compilers, compiler theory and spelunking through compiler libraries. I have written my own heaps (memory management), my own virtual memory driver, device drivers and hardware interfaces. So I do understand quite a bit about how computer languages work and how the language is processed.
I have used char arrays as ints. I have used char arrays as functions. I have used void* to hide underlying data types. I have used void* in C to simulate C++ functionality.
Richard MacCutchan wrote: When you use a cast the compiler does what can be done at machine level, but the object itself is still a char*, and any attempt to use it in any other way will raise a compiler error.
That specifically is not true.
Once a char* is cast to an int (or int*) then the compiler specifically and exclusively treats it as that new type.
The question is not how it is used but rather how it is defined to the compiler.
Richard MacCutchan wrote: And the result of calling that function may, or may not, make sense.
All of those worked because the compiler did what it was told. The cast changed the type. The compiler respected the type and it did not and does not maintain information about previous types.
A human understands that the underlying data originated from a character array.
However the compiler does what it is told. And once it is cast to a different type it is in fact a different type to the compiler. By definition. You, the human, can use it incorrectly but you (again the human) can use the original type incorrectly as well. That has nothing to do with the cast but rather how the human uses it.
The easiest way, perhaps only way, for a language to preserve type is to not allow the type to be changed at all. Java and C# do that.
Going back to what was originally said by you.
"pretend it points to an int"
The compiler is not doing that. To the compiler once the cast occurs the data is now the new type. Whether that is a problem or not is a human problem, not a compiler problem.
For the compiler to be involved in this at all the underlying data would need to keep track of the type. And it does not do that.
|
|
|
|
|
Well I disagree entirely, but I have no intention of arguing further.
|
|
|
|
|
What you have is a set of bits, commonly called a byte/octet, a halfword, a word, ...
You declare an interpretation of the bit pattern as a character.
You declare an alternative interpretation of the same bit pattern as a small integer.
You might declare a third interpretation of it as, say, an enumeration variable. You can declare as many alternate interpretations of the bit pattern as you like. The various interpretations are independent and coexistent. It is the same bit pattern all the time, nothing changes.
Unless, of course, you call for a function that interprets the bit pattern in one specific way, and the creates another bit pattern that can be interpreted as something resembling the first interpretation made by the function. Say, the function interprets the bit pattern as an integer, and forms a bit pattern that, if interpreted as a floating point value, has an integer part equal to the integer interpretation value of the first bit pattern. Yet, even the constructed bit pattern is nothing more than a bit pattern, that can be given arbitrary other interpretations.
When you declare a typed variable / pointer / parameter, you are just telling the compiler: When I use this symbol to refer to the bit pattern, it should be interpreted so-and-so. The compiler will see to that, without making any modifications to the bit pattern, and - at least in some languages - making no restrictions on other interpretations.
A problem with some languages is that in some cases, a cast will just declare another interpretation of the bit pattern, while in other cases (other interpretations), it will create a new bit pattern. If you want full control, always interpret the same bit pattern, never create a new one, a union is a good alternative to casting.
Besides, by declaring a union, you signal to all readers of the code: Beware - this bit pattern is interpreted in multiple ways! Casting can be done behind your back, risking e.g. that a variable with limited range (e.g. an enumeration) is given an illegal value. With a union, you will be aware of this risk.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
trønderen wrote: while in other cases (other interpretations), it will create a new bit pattern
Keeping in mind of course that at least here the discussion is about C/C++ (the forum.)
C++ can do that since it supports operator overloading. But not as far as I know for native types.
Even with operator overloading though once the cast operation happens the compiler does consider that a new type is in play.
|
|
|
|
|
I didn't consider syntactic sugar, such as operator overloading.
Alternate interpretations of a given bit pattern can be done with old style simple operators, overloaded operators, methods argument preparation, explicit casting, ... The essential point is not the wordiness of the syntax, but that the bit pattern is not changed. We have just added another interpretation, regardless of which coding syntax we use for making that interpretation. (It isn't limited to C/C++ - rather, C/C++ is limited in alternate interpretations.)
I really hate it when people 'explaining' computers tell that 'Inside the computer, everything is numbers. Say, the letter 'A' is 65 inside the computer'. Noooo!!! Inside the computer is a bit pattern that has no predefined, "natural" interpretation as a number! Sure, you can interpret it numerically, and divide it by two to show that half an 'A' is space - but that is plain BS. It is like uppercasing the value 123456789!
Sometimes, it is useful to make alternate interpretations. E.g. a 24-bit value intended to be interpreted as a color, human eyes cannot determine whether two colors are identical (maybe the screen isn't capable of resolving 16 million colors, either). In an alternate interpretation, as a three-part RGB value 0-255, we can very easily see if the colors are identical or not. But that doesn't mean the color 'really' is numbers - no more from the screen than from the rose in the vase next to it. Both the reds are red - not 255,0,0! RGB values are 'false' interpretations (i.e. deviating from interpretation assumed by the photo editor) to help us humans with limited color-interpreting abilities.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
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.
|
|
|
|
|
As already mentioned in several answers, auto keyword doesn't make C++ code less strong-typed or type-safe. So, using auto is individual preference. In some cases (such as templates, lambda) there is no other choice.
When auto is optional, I always use it for complicated types, like container iterators. I also like auto in container enumeration code:
for(const auto& x: my_container)
{
}
As for local variables, it depends. Sometimes we want the variable to have another type. If the variable must have the same type, as expression, auto can help, when the code is changed:
std::vector<short> v;
short n = v[0];
Consider the situation, when we change the container type to int:
std::vector<int> v;
short n1 = v[0]; auto n2 = v[0]; decltype(v)::value_type n3 = v[0];
I find myself using auto more and more. Sometimes, when I want to see exactly, what I am doing, I prefer to use an explicit type.
|
|
|
|
|
I clearly have a limited understanding of C++. I admittedly come from a C background, and I have embraced the general concepts of C++ (most of the 4 pillars). But I'm going to be honest here 
It seems to me that auto is fixing or making easier to use some of the more spurious features of C++. Just a general thought, but it gets back to my original post/question. For example, your comment: "decltype(v)::value_type n3 = v[0];" means absolutely nothing to me. I'm at the level of wtf?
So, I went out to the internet and read: "Inspects the declared type of an entity or the type and value category of an expression." for decltype. I still don't know what that means. Are we off in the top 0.01% land of coding? It's okay, I found my niche long ago, but seriously, it feels like so many special features have been added that only apply to the religious fanatics of code land.
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.
|
|
|
|
|
I also prefer C over C++, and decltype example was kind of joke. Bad joke, I guess. In any case:
decltype(v) means: type of v variable, vector of int in this case. vector type has value_type typedef, defined as T, see here: std::vector - cppreference.com[^]
So, this ridiculous (for anyone, except C++ snobs) line is translated by compiler to int, i.e. vector template parameter.
|
|
|
|
|
(for anyone, except C++ snobs)
Now I need to clean my screen - just spit all over it laughing. honestly, I did make the comment that there are people out there that code at a level I cannot even comprehend. I've come to call them "code witches" <--- I'm waiting to see if anyone follows the reference  I read your description of what decltype does and I think, "hmm, I need to pass gas."
It's almost like some of the new "features" and auto is not new - 2010 ish raise areas of C++ to a meta programming language on it's own. Macros on steroids or something.
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.
|
|
|
|
|
There is a time and a place for it, and it's sometimes useful when doing some heavy Generic Programming.
Like, in theory if you had to design your own tuple type (I know std already has one, but ignoring that), the function to access a tuple's value might be an auto because it's difficult to even type out the template instantiation necessary for the return type, much less come up with it.
Another place I use it: In my graphics library you can define pixels with an arbitrary memory footprint. Different amounts of bits for different channels, like RGB565 or YUV888 etc. Because of the arbitrary nature of it the integer values for each channel may be a different type. For example, while a channel probably won't be more than a uint8_t can hold (8-bits) it might be (12 bits? uint16_t would be necessary)
Because of that, when I go to assign values from arbitrary pixel formats I don't actually *know* what type it is, other than some kind of integer of 64 bits or less (based on static_assert constraints). So I could always promote it to a uint64_t but that creates other problems when you have to cast down again.
So auto is what's for dinner.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
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
