|
Thanks, but it still does not do what I want, as you expected it may. .
Would it be OK to actually discuss and analyze this ?
I am asking I am NOT telling the group shoud do that.
QRegularExpression re("(hci\w+([a-fA-F0-9][a-fA-F0-9] +[a-fA-F0-9][a-fA-F0-9])");
There are , imho , important parts (to reg exp ) and they are ok when used alone.
1. If I opt to use QRegularExpressionMatchIterator i = re.globalMatch(pattern);
There should be at lest three "code groups " delimited by "(,,,code group... )"
2. there are TWO base "reg expressions " one working OK as is
"hci[0-9]" - function as "match hcix where x = [0-9] - some doc call [0-9] range
or
hci\w should perform SAME task
3. the analysis of "xx:" using [a-fA-F0-9] is simply "too cute " and [0-F] with "how many times do the previous - {2} works as well.
I have no need to check for lower case "hexadecimal " since that actually does not exist anyway...
So - I will , perhaps stubbornly, try to continue usage of at least ONE of the QT classes and maybe will
find correct modification of the above.
If i end up with plain "reg_exp" so be it...
Thanks
|
|
|
|
|
When you post code use code blocks.
Salvatore Terress wrote: If I opt to use QRegularExpressionMatchIterator i = re.globalMatch(pattern);
Not sure how to emphasize what I have already said several times.
That question is NOT about regular expressions.
It is about how to use that specific library.
I suggest you start with a less difficult example to figure out how iteration works. And google for examples as I documented in the other reply.
Salvatore Terress wrote: There should be at lest three "code groups " delimited by "(,,,code group... )"
You mean the parens. Parens are used for 'capturing' and for 'grouping'.
For the case I gave the inner ones was to group the outer for capturing.
And yes that is a problem when you iterate. The library you are using might have a way to specify that the parens are not 'capturing'.
In Perl it looks like the following. There would be only one capturing group which would match either 'abcxyz' or 'defxyz'.
((?:abc|def)xyz)
I will note that I use that feature so rarely that I had to look it up.
Salvatore Terress wrote: the analysis of "xx:"
As I mentioned there are variations to what I suggested. Myself I don't care for using '{2}' in a case like this. Just a preference.
(Had to edit the above because I messed up the code block)
modified 16-Nov-23 10:40am.
|
|
|
|
|
SOLVED and CLOSED
as initially asked for , by using named subgroup option.
QRegularExpression re("(((?<one>hci[0-9])(.*))?(?<two>(([0-F]{2}[:]){5}[0-F]{2}))(.*))");
Thanks very much for all support given.
|
|
|
|
|
int AnInt=6;
void EditInt(int * IntPnt)
{
*IntPnt=7;
}
EditInt(&AnInt);
Is this how you should proceed?
|
|
|
|
|
That's passing as a pointer, not as a reference. As a reference (C++ only, though maybe C now has them too), it's
void EditInt(int& IntRef)
{
IntRef=7;
}
int AnInt=6;
EditInt(AnInt);
|
|
|
|
|
Greg Utas wrote: That's passing as a pointer, not as a reference. Which is just the same, apart from semantics.
|
|
|
|
|
Very true. A reference can even be to nullptr , and you need to check for this if writing bulletproof code:
void function(type& arg)
{
if(&arg == nullptr)
throw std::invalid_argument("function received null argument");
}
type* nasty = nullptr;
function(*nasty); Without the check, function crashes when it gets around to using arg .
|
|
|
|
|
And the same with a pointer, since there is no material difference between the two.
|
|
|
|
|
I would assert() something like that rather than throw .
It strikes me as an error in the code itself, rather than something that should have filtered its way into runtime code, so I think assert is more appropriate.
As I understand it, best practices indicate that a reference should never be deliberately null. Could be wrong here?
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
What to do depends on the environment you're running in. I've never used assert , so I had to look up the documentation, which says that it calls abort . Most application code won't catch an invalid_argument exception, so the effect will be similar.
In my open-source software, I neither throw nor assert in this situation. Instead, I generate a debug log with a traceback and return whatever signifies failure if the function has a result. That's appropriate if avoiding crashes is paramount, which is what my software aims for.
You're right that a reference shouldn't be null. For many functions, a pointer argument shouldn't be null either. But applications misbehave, so you have to decide whether your function will check for bad arguments or just crash.
|
|
|
|
|
|
I'm looking at old code.
I don't think it's something I ever done.
It seems weird that the compiler accept to not fully initialize the struct.
They (old retired programmers) seem to expect the values to be zero-initialized.
I find it not really safe.
I caught that with the clang/tidy checker.
<h1>define sz_Potato "Patate"</h1>
struct MyStruct
{
int a;
int b;
const char* text;
short c;
};
MyStruct myStructArray[3] =
{
{1, 2},
{1, 2, sz_Potato},
{1, 2, sz_Potato, 4}
};
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
If your code should be compiled as C++ code (not plain C), do yourself a favour and paste a line like:
struct MyStruct
{
MyStruct () {memset (this, 0, sizeof(MyStruct));} int a;
int b;
const char* text;
short c;
}; Otherwise C initialization rules are vague enough to let you wonder what is going to happen. For instance, in your example, if myStructArray is static, it will get initialized with zeroes. If it's stack allocated, it will be uninitialized.
And to answer your question, yes your code is valid C and C++ code. Not nice but valid.
Mircea
|
|
|
|
|
yeah, I know and will add default contstructors.
Thanks.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
Maximilien wrote: It seems weird that the compiler accept to not fully initialize the struct.
They (old retired programmers) seem to expect the values to be zero-initialized.
According to cppreference.com:[^] Quote: All members that are not initialized explicitly are empty-initialized.
The old programmers are correct.
|
|
|
|
|
Thanks.
let's hope 0 or empty strings are not valid values!!
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
Well, 0 is the best bet.
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
Maximilien wrote: I'm looking at old code.
You would need to make that more specific.
And provide more context.
Since C didn't initialize them and C++ was initially based on that if it was, for example, code from the 80s then perhaps. But I don't think back then they had array structure initializers.
Maximilien wrote: seem to expect the values to be zero-initialized.
From "The C++ Programing Language Special Edition" book by Stroustrup with a 2nd Printing of March 2000. I believe that book was based on the first ANSI C++ standard.
Section "4.9.5 Initialization"
"If no initializer is specified ...is initialized to 0 of appropriate type"
"Members of arrays and structures are default initialized or not depending on whether the array or structure is static"
Myself looking at that code, with no other context provided, yes it should be initialized to zero ('text' and 'c')
|
|
|
|
|
I typically use {0} to initialize a struct with a number of fields.
It works. I imagine it can be extended to do the above as you provided, but probably because it fills in remainders with zeroes.
I don't know how unsafe it is. I can tell you it works with GCC, Clang, and MSVC (at least as of 2022) in my experience.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
For C code, using {0} is safe, as far as I know, and initializes all bytes of the struct to zero. For C++, I don't know. It looks like maybe all bytes are initialized to zero, as per C, but then constructors are called with an empty argument list. If the first struct member has a constructor, then the compiler will look for a constructor that takes a single int. If no such constructor exists, compilation fails.
Both g++ and clang++ warn about struct members with missing initial values when -Wextra is used.
For C, though, it can be useful, since you can also use named initializers e.g.
struct S {
int i;
double d;
char str[10];
};
struct S s { .d = 123.4; }; will assign 123.4 to s.d, and all other members will be set to zero. You can use named initializers in C++ too, but you still get warnings about struct members with missing initializers.
Keep Calm and Carry On
|
|
|
|
|
Wonder why I don't get any warnings doing that under zephyr, which is pretty darn strict in terms of how it configures GCC. I usually use it to test warnings. I think it's set to -Wall
It's possible I'm not using the {0} technique in any of my major libs, but I could swear I am.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
You do need to use -Wextra to get those warnings:
[k5054@localhost]$ cat example.cpp
struct S
{
int i;
float f;
double d;
};
int main()
{
S s{0};
std::cout << s.f << '\n';
}
[k5054@localhost]$ g++ example.cpp
[k5054@localhost]$ g++ example.cpp -Wall
[k5054@localhost]$ g++ example.cpp -Wextra
example.cpp: In function ‘int main()’:
example.cpp:12:11: warning: missing initializer for member ‘S::f’ [-Wmissing-field-initializers]
12 | S s{0};
| ^
example.cpp:12:11: warning: missing initializer for member ‘S::d’ [-Wmissing-field-initializers]
[k5054@localhost]$
Keep Calm and Carry On
|
|
|
|
|
Thank you. I think I'll add that to my build environment.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
Take a look at the GCC (or clang) documentation for what -Wextra adds: Warning Options (Using the GNU Compiler Collection (GCC)) . In most cases, you probably do want to be aware of all the additional warnings that -Wextra brings. But maybe in the embedded world you're going to be doing something that's going to trigger one of the warnings excessively. In which case you might just want -Wmissing-field-initializers . Or perhaps you might want e.g. -Wextra -Wno-unintialized , which gives you all of -Wextra's goodness, but silences the -Wuninitailzed warnings.
If you've got a section of code that you know is going to generate warnings, and you just want to shut the compiler up you can always investigate the GCC diagnostic pragmas : Diagnostic Pragmas (Using the GNU Compiler Collection (GCC))
Keep Calm and Carry On
|
|
|
|
|
I love C++ because I can do things like this:
template<size_t BitDepth>
using bgrx_pixel = gfx::pixel<
gfx::channel_traits<gfx::channel_name::B,(BitDepth/4)>,
gfx::channel_traits<gfx::channel_name::G,((BitDepth/4)+(BitDepth%4))>,
gfx::channel_traits<gfx::channel_name::R,(BitDepth/4)>,
gfx::channel_traits<gfx::channel_name::nop,(BitDepth/4),0,(1<<(BitDepth/4))-1,(1<<(BitDepth/4))-1>
>;
using screen_t = uix::screen<gfx::bgrx_pixel<32>>;
Now, I've made pixels definable in terms of their memory footprint and what channels they expose, like R, G and B, or C, Y, and Mk or whatever. Above I'm defining a BGRx8888 pixel which DirectX uses for its surfaces. That's 3 8-bit channels with a fourth unused, blue first.
The above code is facilitated by this: gfx/include/gfx_pixel.hpp at master · codewitch-honey-crisis/gfx · GitHub[^]
That defines things like channel traits, and does all the necessary compile time computations to make it work.
The problem is this: It's write-only code, and there's no easy way to remedy it because meta-programming in C++17 and prior is very hackish. C++20 and beyond improve the situation a little, but the heavy reliance on The STL rather than language improvements to facilitate this leaves me wanting on little embedded platforms where the STL might not be complete or even available.
It's cool that with C++ you can even make facilities to enable code like the above, and it's the only language I know of that allows for it, but I really wish there was a cleaner way to do this stuff.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|