- Conditional compilation - struct contains member - 8 Updates
- enum class or enum? - 1 Update
- Users needed - 1 Update
| Barry Schwarz <schwarzb@delq.com>: Jul 18 06:05PM -0700 On Sat, 18 Jul 2020 19:16:42 -0400, James Kuyper >I've seen installation scripts that will install different versions of >the same file depending upon the target architecture, so that's one >plausible way for that to be the case. In any individual compilation, there can be only one struct Monkey type. Something has to change between one compilation and the next to define a different struct Monkey type. Given the OP's statement that here is a header file for each architecture, he needs to tell us how he specifies which one to use. If there is only one header file, he needs to tell us how he forces only the desired type to be defined. -- Remove del for email |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Jul 18 09:49PM -0400 On 7/18/20 9:05 PM, Barry Schwarz wrote: > On Sat, 18 Jul 2020 19:16:42 -0400, James Kuyper > <jameskuyper@alumni.caltech.edu> wrote: ... > define a different struct Monkey type. > Given the OP's statement that here is a header file for each > architecture, he needs to tell us how he specifies which one to use. He's not seen fit to clarify the issue, so we can only guess. However, I've seen multiple libraries whose installation scripts will install one, and only one, header file of a given name, with the contents of that file being different depending upon the architecture that the library was installed on. If the library he's talking about shares that feature, it's the installation script, not the OP, that specifies which one to use - and he's looking for way to determine programmatically which choice that was. > If there is only one header file, he needs to tell us how he forces > only the desired type to be defined. If the library he's using is similar, in this regard, to the ones I'm thinking of, the header file contains a declaration for only one architecture-specific type. That is the desired type, and it was determined when the library was installed. However, for those libraries, doing what the OP wanted to do would have been trivial. Their installation scripts used various methods to determine which version of the library to install, and all of those methods would be equally available to the OP. He would only need to read the installation script and the installed code to find out how it made that determination, and then do the same in his own code. If I remember correctly (it's been a while), there were even macros #defined by the headers that could be queried to determine which choice the installation script had made, which would make the task even more trivial. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Jul 19 07:38AM On Sat, 2020-07-18, Öö Tiib wrote: >> > > struct Monkey { >> > > int a, b; >> > > }; ... >> > practically impossible to implement in a clean way (or at all), so you >> > ask about Y. >> > Ask about X instead. ... > header file). Alf suggested to stop feeding us monkeys and tell > what really is different in interfaces of those implementations. > Your example of library I simply would not #include ever. Put differently, it seems very odd to have a library where the public interface changes in any relevant way depending on the CPU architecture. Unless the library is from the 1980s, or something. Libraries are supposed to /hide/ irrelevant differences, not /amplify/ them. We'd need to understand what's happening here, so we can avoid giving bad advice. Rereading the OP's text above, perhaps "library" and CPU architecture were red herrings. Perhaps there are simply three forks of a project which have begun to deviate, and the OP tries to squeeze in "one source code file that will be common to [all] three projects". But now I'm just speculating. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| gazelle@shell.xmission.com (Kenny McCormack): Jul 19 08:00AM In article <rev5lp$1up$1@dont-email.me>, Alf P. Steinbach <alf.p.steinbach+usenet@gmail.com> wrote: ... >practically impossible to implement in a clean way (or at all), so you >ask about Y. >Ask about X instead. If you don't like this, then just mark it read and move on. No need to post as you did. -- "Unattended children will be given an espresso and a free kitten." |
| gazelle@shell.xmission.com (Kenny McCormack): Jul 19 08:03AM In article <69beaaae-fe19-42ff-8a26-69e6e6b7f0b5o@googlegroups.com>, ร รถ Tiib <ootiib@hot.ee> wrote: ... >header file). Alf suggested to stop feeding us monkeys and tell >what really is different in interfaces of those implementations. >Your example of library I simply would not #include ever. If you don't like it, just mark it read and move on. -- "They say if you play a Microsoft CD backwards, you hear satanic messages. Thats nothing, cause if you play it forwards, it installs Windows." |
| "Öö Tiib" <ootiib@hot.ee>: Jul 19 02:52AM -0700 On Sunday, 19 July 2020 11:03:18 UTC+3, Kenny McCormack wrote: > >what really is different in interfaces of those implementations. > >Your example of library I simply would not #include ever. > If you don't like it, just mark it read and move on. On the contrary, I did like it. Apparently you did like my response as otherwise why did not you mark it read and move on? |
| "Öö Tiib" <ootiib@hot.ee>: Jul 19 03:04AM -0700 On Sunday, 19 July 2020 10:38:16 UTC+3, Jorgen Grahn wrote: > We'd need to understand what's happening here, so we can avoid giving > bad advice. Yes, it is often case that people ask how to hack executable to change data in it when the issue was about providing data from command line. > of a project which have begun to deviate, and the OP tries to > squeeze in "one source code file that will be common to [all] three > projects". But now I'm just speculating. The two common solutions to that are 1) to have side-by-side wrappers for those different versions and 2) one heavily sliced by preprocessor wrapper. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Jul 19 09:04AM -0400 On 7/19/20 3:38 AM, Jorgen Grahn wrote: ... > Put differently, it seems very odd to have a library where the public > interface changes in any relevant way depending on the CPU > architecture. Unless the library is from the 1980s, or something. I think it's likely that the fields that are represented by "b" and "c" in his simplified example are not intended to be part of the public interface. |
| already5chosen@yahoo.com: Jul 19 03:21AM -0700 On Friday, July 17, 2020 at 11:02:57 PM UTC+3, Keith Thompson wrote: > of any integral type. You'd have to create your own array-like > class rather than using raw arrays or std::vector. Like many things, > it's a tradeoff between convenience and safety. Looks more like a tradeoff between convenience and inconvenience :-) There are people that like to suffer, but even these people don't like to suffer too much, so for them it could be called a tradeoff. |
| woodbrian77@gmail.com: Jul 18 07:58PM -0700 On Friday, July 17, 2020 at 11:54:24 AM UTC-5, Mr Flibble wrote: > > good job. Now Netflix stumbles. I'm shocked. Haha, > > not really. > Do you have a fixed list of things you talk about on Usenet? It seems every third post almost as regular as clockwork you spam about Duckduckgo, almost like a bot. Your other posts all seem to be on a rota too; you change them slightly each time changing the order of words and such but the content is identical. To the extent that there is some truth to the above, I'll point out it's not easy to be a conservative, entrepreneur in these times. Ben Shapiro over at dailywire.com says that for his birthday a lot of people will text him a note wishing him well, but they don't go on a social media platform and publicly do it. He also faces death threats. He's more of a mensch than I am, but I'm also assailed by some. Brian Ebenezer Enterprises |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment