Jump to content

C++ proposition


Jief_Machak
 Share

823 posts in this topic

Recommended Posts

I've switched to new printf format for DebugLog.

So now utf8 and utf16 works.  :

  %s for CHAR8* instead of %a

  %ls for CHAR16* (wchar_t*). Before, %s was only working if char code were < 128 (useless :-). It may not works in console because of console charset

  %x output hex letter as lower case. It wasn't the case before.

  %X works as usual.

  %lld for 64 bits.

 

If you use GCC or Xcode, there is warnings in case of mismatch.

  • Thanks 1
Link to comment
Share on other sites

1 hour ago, Download-Fritz said:

@apianti Look, I'm sorry for you being obviously very hurt over that, but your version of reality is unfortunately one nobody manages to share. You provided a specific theory, you were told why that specific theory was garbage, and your specific theory was garbage indeed. "Look, it was something in a completely different department, but similar!" Uh, yes, my congratulations. vit's blind guess was a bit worse than your blind guess (cause unfortunately weighs significantly more than symptom), I hope that gives you the satisfaction you've been seeking the past few days with your heroic self-illustrations. Maybe someone will see your true genius when you actually manage to solve a problem or write code over just being a keyboard warrior. But don't waste your time here, CSEE is waiting. :)

 

Right back to the moving goal posts and whataboutism. I'm not hurt by any of this, I have literally no emotional connection to this at all, I do however believe in the truth and facts. I didn't make a blind guess, I backtraced the kernel panic on my z390. And discovered that a memory region was missing, the reason I assumed it was the shim being removed is because the memory region that is missing is not actually missing, it is present. It is just that the driver makes a different decision about where to grab that memory region from in ACPI for 300 series chipsets. This however is happening before that panic ever was going to happen, if it was happening during I would have immediately noticed what memory region it was. I also didn't really need to figure out which one if I point a whole team of people who are developing it in the right direction. Which IT PRETTY CLEARLY SEEMS I DID IF YOU WOULD HAVE ACTUALLY LISTENED TO EVIDENCE. Now please go back to being a bigoted a s s clown and leave me be, you court jester.

  • Like 1
Link to comment
Share on other sites

44 minutes ago, apianti said:

I also didn't really need to figure out which one if I point a whole team of people who are developing it in the right direction.

Of course you didn't, as one person, you pointed a whole team (of, well, two persons for this case, none of which even has the hardware, but "whole team" sounds more impressive I suppose) towards evidence for an issue they announced they will not actively work on. Thank you for your service, next time maybe fix the issue, you seem to have more than enough time. :)

Link to comment
Share on other sites

3 hours ago, Download-Fritz said:

Of course you didn't, as one person, you pointed a whole team (of, well, two persons for this case, none of which even has the hardware, but "whole team" sounds more impressive I suppose) towards evidence for an issue they announced they will not actively work on. Thank you for your service, next time maybe fix the issue, you seem to have more than enough time. :)

 

God. You. Are. Dumb.

 

EDIT: Forgot I had to say the obvious, I was including myself in that. Except I was trying to discuss what might be the solution.... F u c k.

Edited by apianti
  • Like 2
Link to comment
Share on other sites

13 hours ago, Jief_Machak said:

@Slice Thanks for the thanks :-) It's encouraging. Next step is to convert all the PoolPrint, the AsciiPrint and UnicodePrint.

There is only 349 PoolPrint in Clover... :)

If you see something like

#if USE_XTHEME

  ...

#else

  ... = PoolPrint(...

#endif

 

then you may not correct this PoolPrint. It will be deleted later when XTHEME will be completed.

Link to comment
Share on other sites

I've started a bit of cleaning in XString method names.

For example, I think we should rename "StrCpy" in XString.

Would you prefer :

  - 'strcpy', so for example XString str; str.strcpy("other string");

  - 'strCpy'

  - 'cpy', so for example XString str; str.cpy("other string");

 

Then, I'll follow the same scheme to rename StrnCat, StrCat, StrnCpy.

 

I was never able to decide. Names are not my best skill :). What would you think everyone ?

  

Link to comment
Share on other sites

1 hour ago, Jief_Machak said:

I've started a bit of cleaning in XString method names.

For example, I think we should rename "StrCpy" in XString.

Would you prefer :

  - 'strcpy', so for example XString str; str.strcpy("other string");

  - 'strCpy'

  - 'cpy', so for example XString str; str.cpy("other string");

 

Then, I'll follow the same scheme to rename StrnCat, StrCat, StrnCpy.

 

I was never able to decide. Names are not my best skill :). What would you think everyone ?

  

For me strcpy is more famous but is usually used in other contents as separate function.

So str.cpy("other string"); will be more correct.

 

Is there a misprint?

  float Height = IconImage->height * Scale;
   float Width = IconImage->width * Scale;
-   //  DBG("icon %s width=%ls height=%ls\n", IconName, PoolPrintFloat(Width), PoolPrintFloat(Height));
+   //  DBG("icon %s width=%ls height=%ls\n", IconName, Width, Height);

Should it be %f format?

Link to comment
Share on other sites

1 hour ago, Slice said:

 

Is there a misprint?


  float Height = IconImage->height * Scale;
   float Width = IconImage->width * Scale;
-   //  DBG("icon %s width=%ls height=%ls\n", IconName, PoolPrintFloat(Width), PoolPrintFloat(Height));
+   //  DBG("icon %s width=%ls height=%ls\n", IconName, Width, Height);

Should it be %f format?

Yes it should be %f.

Maybe I missed it because it's commented out. I thought I'd replaced them. Well, if you remove the comment, you must get a warning.

So probably, now all the commented DBG that contains a float are wrong...

Link to comment
Share on other sites

13 minutes ago, Slice said:

VS compilation is broken again

VScompile.jpg

Remember VS doesn't not encode Unicode properly.

I think it's not broken. Just these tests cannot be done with VS.

CHAR16* str = L"foobar" works in VS only because all the char codes are < 255.

So we have to put a #ifndef _MSC_VER around these tests.

I can do it, but only in 2 hours.

Edited by Jief_Machak
Link to comment
Share on other sites

I have a problem with call a function required XString (or XStringW) as parameter but with constant value.

It was func("some string");

now it should be ...

func(XString("some string"))? - no compile

func(XString().takeValueFrom("some string"))? - no compile

or else?

Link to comment
Share on other sites

12 minutes ago, Jief_Machak said:

"func(XString().takeValueFrom("some string"))" that should compile... :(

 

Commit and I have a look ?

 

 

Set USE_XTHEME = 1 and see compilation

Link to comment
Share on other sites

Problem was the XImage parameter, not the XString.

 

Please, do NOT use parameter like XString& or XImage& (or {anything}&. Always use const {anything}&.

 

If this is an out parameter, use {anything}* param. In that later case, I usually (not for short method) declare {anything}& paramRef = *param, so I don't have to use the -> operator. 

 

 

Link to comment
Share on other sites

 Share

×
×
  • Create New...