|
The intellisense for C++ in VS Code - at least when it works, is nothing short of incredible.
template<size_t BitDepth>
using bgrx_pixel = pixel<
channel_traits<channel_name::B,(BitDepth/4)>,
channel_traits<channel_name::G,((BitDepth/4)+(BitDepth%4))>,
channel_traits<channel_name::R,(BitDepth/4)>,
channel_traits<channel_name::nop,(BitDepth/4)>
>;
using rgb18_pixel = pixel<
channel_traits<channel_name::R,6>,
channel_traits<channel_name::nop,2>,
channel_traits<channel_name::G,6>,
channel_traits<channel_name::nop,2>,
channel_traits<channel_name::B,6>,
channel_traits<channel_name::nop,2>
>;
What you're looking at is two arbitrarily defined pixels. One is N-bit pixel where 3/4 of the bits are used, and the second example is a 24-bit pixel where 18-bits are used.
That's not really important, but the channel names are, because consider this:
rgb18_pixel::is_color_model<
channel_name::R,
channel_name::G,
channel_name::B>::value
If you know C++ you can tell there's metaprogramming magic here. What I'm doing is querying a "list" of channel traits at compile time looking for ones with particular names.
The thing is, if you hover over value, the extension will resolve it to true in the tooltip that pops up - no easy feat.
More impressive even is this:
using color18_t = color<rgb18_pixel>;
auto px = color18_t::gray;
It will determine the actual numeric value for that color and display it when you hover over "gray"
(2155905024)
You think that's easy? No.
constexpr static const PixelType gray = convert<source_type,PixelType>(color<PixelType>::source_type(true,
0.501960784313725,
0.501960784313725,
0.501960784313725));
Notice it's running a constexpr function convert() to get the destination pixel format. This is a non-trivial function.
So one of two things is happening here.
Either the C++ extension for VS Code has a compliant C++ compiler front and middle built in (I suspect it does) or it is managing to link itself to existing compilers like GCC tightly enough to determine this output (which doesn't seem possible to me)
Either way, go Microsoft.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
Totally agree.
And the Copilot has helped me greatly with boilerplate code.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
I haven't messed with Copilot. I'm "AI" averse, and will probably remain so until they get better. I like Visual Studio's AI integration because it's explicit - you have to smash tab at each step and it shows you what it will do next. It's important because it's so often wrong.
I'm not sure if Copilot works like that or something else, but honestly, I can pretty much think in C++ at this point, so it's almost more effort to have to prod an LLM to give me the code I want. By the time I do I could have figured it out with going from C++ to English to English to C++.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
Yes, that's the same way that Copilot works.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Interesting, thanks. I might tinker with it, if it's free.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
I started playing with Copilot a couple days ago. I found the experience a bit freaky at first, kind of like the thing being inside your head, anticipating what you want to do. It was really good at first, but as the application I was working on evolved, getting into the more detailed items, it started writing code with mistakes in it.
I wanted to see what it could do, and started with letting it write the code as much as possible (you know, like the typical QA question at CodeProject.  ). I started with a simple FileSystemWatcher app and described that I wanted a WPF app that monitored a directory and its subdirectories and logged all the changes it saw. It generated a simple app with a FileSystemWatcher, but more like a Console app with no XAML UI. It wrote everything with no problems, working as expected. Impressive, but I wanted to see how far it could go.
Next, I told it to change the app to a XAML UI, using MVVM and a TreeView, and keep that updated with changes as they happened in the file system. It explained everything, walking me through all the code changes and what I needed to add/remove. It came up with the hierarchy model and the correct XAML bindings and everything! That was mind-blowing! I didn't expect it to figure out how to rewrite the code for an entirely new UI. Talk about freaky!
I was just evolving the app, one step at a time, describing what I wanted the app to do, and it was coming up with the right suggestions, and that's when the mistakes started. The first mistake was a minor issue with a XAML binding that it didn't wire up correctly, one-way instead of two-way. I pointed that out and it actually said I was correct and came up with the correct, simple fix. Wait, this thing can figure out its own mistakes?!
OK. Let's give it something more difficult to understand. At this point, the window was split into the TreeView on the left and a log of FileSystemWatcher events on the right. I got it to coloring the event messages, based on event types, like Changed, Created, Deleted. It put together a ListBox with a TextBlock for each item in the list, with the correct DataTriggers for each message type and the correct Foreground and Background property setters. I told it to change the ListBox to a ListView, and it correctly rewrote the XAML and kept all the formatting. I told it "that didn't look right to me and to back out that change," and it did exactly that, going back to the ListBox code. Mind blown!
Very impressive so far. Let's dig into a little more detail. The background of the TextBlock items in the ListBox only went so far as the length of the text, but I want it to fill the width of the available space in the ListBox. I described this, and it actually understood that, coming up with wrapping each TextBlock in a Border object and moving the DataTriggers for the Foreground and Background property setters to the Border tag for formatting! Whaaaaa?! Cool.
But here's the bigger mistake. The Border tag in XAML doesn't support a Foreground property, only a Background. It didn't immediately understand the context the Border was being used for and went for just moving the TextBlock.Style section to the Border.Style section without checking the property setters in their new context like we would.
That was interesting and gave a bit of insight into the limits of the context it's keeping track of. It won't generate its own "sub context(?)," like checking its work as it makes changes, in this case, checking the property setters for correctness in their new home. It can recover, however, if you know about and point out the mistake. I told it the Border element doesn't support a Foreground property and asked it "what it could do about that," in those exact terms. To my amazement, it told me I was right about Foreground property, and it fixed the problem by moving the Foreground Setters back to DataTriggers the TextBlock.Style section!
 I was floored.
My second experience with Copilot was a bit harsher. Keeping with the "typical CodeProject question poster" theme, I intentionally simplified my questions, leaving out all context as to what I wanted to do and in all my questions. Copilot did not like that AT ALL. It was constantly telling me to provide more context in my questions and commands, but it was coming up with possible intents asking me questions about what I was talking about and rephrasing my questions into terms and contexts it could understand, just like we do while answering questions here. It gives you links you can click on for your questions but rephrased in the context it thinks you're talking about, and it'll answer them and make suggestions.
I found that very interesting. It seems to get just as frustrated as we do with people here. It makes me wonder if it was trained not only on GitHub code, but on all of SO and CP.
Is it going to replace developers? No, not a chance. You still have to learn how to break your problems and questions down into smaller, organized chunks. You have to think about your problems and not only how to break them down into smaller chunks but do so in a manner you can accurately describe while providing proper context.
Like in my sig, asking questions is a skill, even when asking them of an AI, and this is something the noobs and non-coders struggle to learn.
|
|
|
|
|
float mpu6886::inv_sqrt(float x) {
float halfx = 0.5f * x;
float y = x;
#pragma GCC diagnostic ignored "-Wuninitialized"
#pragma GCC diagnostic ignored "-Wstrict-aliasing"
long i = *(long *)&y;
i = 0x5f3759df - (i >> 1);
y = *(float *)&i;
#pragma GCC diagnostic warning "-Wuninitialized"
#pragma GCC diagnostic warning "-Wstrict-aliasing"
y = y * (1.5f - (halfx * y * y));
return y;
}
Tell me how y is uninitialized? This isn't the first time I've encountered this. 
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
Ah, the fast inverse square root. Mind boggling code, I have not spent the time trying to work out how it works.
Without the code they commented then y would very likely have a terrible guesstimate and the function would be inaccurate, so y has not been 'initialised' with a good first guess. Weak definition of initialised, but some grain of logic there.
|
|
|
|
|
but i explicitly assign y to x. 
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
Ah, sorry, I completely misread your original post.
I would guess the error/warning is because you can not guarantee the sizes of long and float will be the same between C++ implementations. Just a stab in the dark though, and it seems like a strange error for that.
|
|
|
|
|
I would guess std::bit_cast in the line long i= ... should help.
|
|
|
|
|
no std available here
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
If you split assignment via a long i; and float y, halfx; does it still happen?
|
|
|
|
|
That is weird. But better than what clang does at any optimization level above -O0, as per Compiler Explorer for X86-64:
inv_sqrt: # @inv_sqrt
ret
Um, what?
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
|
|
|
|
|
Visual C++ does not complain about anything with that code. I think this qualifies as a bug.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
It very well could be. I've encountered this error in error before, I think?
I'm just really hesitant to file a bug against a compiler because I feel like they know a hell of a lot more about C and C++ than I do.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
What machine are you targeting, and what are the sizes of float and long*?: If you compile this as 32 bit with gcc, you do not get any warnings.
Theory: you're compiling in 64 bit mode sizeof(float) = 4 and sizeof(long*) = 8. So what the compiler is trying to tell you is that long i = *(long*)&y the conversion of the float to a pointer, half the bytes are uninitialized. My theory anyway.
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
|
|
|
|
|
it's 32-bit GCC
My processor can handle 64-bit numbers, but not as a native word.
Edit: I'm not sure long isn't 64 bit on this platform, but I've always used long long for that.
My CPU will not handle 128-bit words under any circumstances.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
The issue would arise if the size of a float is less than the size of a pointer. Maybe just ask the compiler to what sizeof(float) and sizeof(void*) return?
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
|
|
|
|
|
Thanks. I'll look into it as time and motivation allows.
Edit: Turns out i had a project open so it was easy enough to check
sizeof(float): 4
sizeof(long*): 4
I checked sizeof long* just to be certain
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
Well, not that then  Seemed like a good answer at the time. Maybe it's just the type punning that's baffling the compiler?
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
|
|
|
|
|
That's my theory, but I'm uncomfortable with it if nothing else because
a) I hate assuming compiler bugs. So often it's some effing intricacy of the C or C++ language that is at play, rather than the compiler in error.
b) You'd think it would have been found and fixed. Like I said, this isn't the first time I've run into it. The last time was a lot more innocuous - no type aliasing or fudging like that. it was an enum struct type declared as a local variable and initialized at declaration time. 
I'd dig up the old example if i could, but I ended up working around it in order to get the warnings out of my code without using compiler specific pragmas.
Edit: Duh. I am not using the latest GCC. I didn't think about that. Could easily be a bug.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
modified 5 days ago.
|
|
|
|
|
I get the same warning with gcc-14.1.0, and with x86-64 gcc-trunk over at the compiler explorer, so it's not been fixed so far.
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
|
|
|
|
|
I didn't think of trying godbolt. I'm really distracted rn on the phone w/ an old friend.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
As far as I am concerned, the fact that you have this line :
float y = x;
which is clearly initializing the variable qualifies it as a bug. I can not conceive a situation where that is not a bug.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
