2025/10/28

Newest at the top

2025-10-28 11:34:05 +0100Frostillicus(~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net)
2025-10-28 11:32:29 +0100 <srazkvt> yea i usually make it a macro too
2025-10-28 11:32:01 +0100 <haskellbridge> <Morj> srazkvt: Yeah you're right, I was misremembering. In any case, for the last how many years of C++ for me it was Q_UNUSED(thevar)
2025-10-28 11:31:47 +0100 <tomsmeding> I guess (void)&my_struct;
2025-10-28 11:31:24 +0100 <tomsmeding> you can just &my_struct; if you want
2025-10-28 11:31:14 +0100 <srazkvt> icc is still a thing, but i don't know of anyone who uses it
2025-10-28 11:31:08 +0100 <tomsmeding> lol ok yeah
2025-10-28 11:30:48 +0100 <kuribas> (int *(int*)(&my_struct)) or something...
2025-10-28 11:30:47 +0100 <mauke> tomsmeding: maybe intel cc (is that still a thing?) might support it
2025-10-28 11:30:15 +0100 <tomsmeding> mauke: ah I see -- a viewpoint that I agree with, by the way, though that's beside the point here
2025-10-28 11:30:11 +0100 <kuribas> tomsmeding: what if you cast the pointer, then back?
2025-10-28 11:29:48 +0100 <tomsmeding> yes but you cannot convert a struct to an int
2025-10-28 11:29:40 +0100 <tomsmeding> kuribas: `error: cannot convert to a pointer type`
2025-10-28 11:29:39 +0100 <kuribas> tomsmeding: you can convert pointer to int, no?
2025-10-28 11:29:20 +0100 <mauke> because they didn't like #pragma because you can't generate it from a macro
2025-10-28 11:29:05 +0100 <tomsmeding> pointers are just scalars, but structs are not scalars
2025-10-28 11:28:54 +0100 <tomsmeding> kuribas: C distinguishes very much between values and pointers
2025-10-28 11:28:50 +0100 <mauke> AFAIK __attribute__ is a GNU invention
2025-10-28 11:28:40 +0100 <tomsmeding> because if this is just warning management, I wouldn't care so much about proper cross-compiler compatibility
2025-10-28 11:28:39 +0100 <kuribas> tomsmeding: does C distinguis between scalar and compound? I thought it's just all addresses for C.
2025-10-28 11:28:27 +0100 <tomsmeding> mauke: is __attribute__ in general syntax that is parsed by other compilers, even if not this particular 'unused' attribute?
2025-10-28 11:27:47 +0100 <tomsmeding> mauke: ah
2025-10-28 11:27:45 +0100 <tomsmeding> kuribas: yes which makes no sense and may well be rejected by the compiler if the thing is not a scalar in the first place, such as a struct
2025-10-28 11:27:34 +0100 <mauke> s/gcc/gcc and imitators/
2025-10-28 11:27:24 +0100 <tomsmeding> s/w//
2025-10-28 11:27:23 +0100 <kuribas> (void*) is unsafecast
2025-10-28 11:27:20 +0100 <tomsmeding> clang does that finew
2025-10-28 11:27:16 +0100 <mauke> s/modern/gcc/
2025-10-28 11:27:10 +0100 <tomsmeding> which IMO is neater than (void)'ing it somewhere
2025-10-28 11:27:03 +0100 <tomsmeding> though with modern (?) compilers you can __attribute__((unused))
2025-10-28 11:26:29 +0100 <tomsmeding> definitely (void)
2025-10-28 11:26:19 +0100 <srazkvt> Morj: void* ? you sure not just void ? at least in c we just do void
2025-10-28 11:26:14 +0100 <tomsmeding> thank you mauke kuribas
2025-10-28 11:26:09 +0100 <tomsmeding> that works!
2025-10-28 11:26:07 +0100 <tomsmeding> oooh
2025-10-28 11:26:07 +0100 <kuribas> _foo
2025-10-28 11:25:52 +0100 <kuribas> tomsmeding: use underscore?
2025-10-28 11:25:31 +0100 <mauke> s/d\b//
2025-10-28 11:25:19 +0100 <mauke> named it with an underscore?
2025-10-28 11:22:59 +0100 <haskellbridge> <Morj> Back in C++ we would "(void*)the_var" that shit
2025-10-28 11:22:24 +0100 <srazkvt> that's kind of ugly though
2025-10-28 11:21:58 +0100 <haskellbridge> <Morj> For unused variables, can't you just use it vacuously? Like in a "const" somewhere ekse
2025-10-28 11:21:33 +0100 <sshine> no #[allow(...)] equivalent
2025-10-28 11:21:24 +0100 <haskellbridge> <Morj> Ah yes, rust pragmas have also spoilt me
2025-10-28 11:21:08 +0100 <sshine> tomsmeding, it seems there's only CLI params
2025-10-28 11:20:05 +0100 <tomsmeding> perhaps some "unused" pragma?
2025-10-28 11:19:56 +0100 <tomsmeding> is there a way to tell ghc to don't raise an unused binding warning for one specific function?
2025-10-28 11:10:44 +0100Googulator34(~Googulato@2a01-036d-0106-03fa-d161-d36f-e0e5-1b0a.pool6.digikabel.hu) (Quit: Client closed)
2025-10-28 11:10:44 +0100Googulator20(~Googulato@2a01-036d-0106-03fa-d161-d36f-e0e5-1b0a.pool6.digikabel.hu)
2025-10-28 11:07:28 +0100trickard_trickard