- [OT] Why do gcc or clang don't have codes for compilation errors/warnings? - 6 Updates
- Drag and drop - 1 Update
- Question on padding and alignment of `struct` and its members (olcott) - 2 Updates
- Why should a "c" programmer learn c++ ? (V2) - 1 Update
- Are there any asm-instructions to support OOP - 1 Update
| Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Oct 03 02:13AM -0400 David Brown wrote: > impossible to guess what "C5038" might mean. (For some warning flags, > it is not always clear from the name - but it's usually quite close to > obvious.) I don't think the design choices of providing simple short errors codes and providing readable option names or pragmas are mutually exclusive. > No compiler I have ever used is ideal (IMHO) with regard to either flags > or messages, but on this one point, for my taste, gcc wins hands down > against MSVC. -Pavel |
| Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Oct 03 02:22AM -0400 Stuart Redmann wrote: > Hello newsgroup, > Sorry for being off-topic. I just wondered why open source tools like gcc > or clang don't use error codes like for example MS Visual C does. I think this is because it is easier for a commercial software manufacturer to provide an efficient centralized error code allocation system and enforce its use than for a community of gcc or clang contributors. If I want > variables, which might give Mr. SearchEngine sensitive information about > what I'm doing. And no, I don't want to use DuckDuckGo, Brian). Does anyone > else think that MS's error codes are a good thing? I do. I also tend to think IBM's or Oracle's error codes are equally good things :-) . > Regards, > Stuart -Pavel |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Oct 03 07:38AM On Thu, 2020-10-01, Stuart Redmann wrote: > Hello newsgroup, > Sorry for being off-topic. I just wondered why open source tools like gcc > or clang don't use error codes like for example MS Visual C does. Tradition and culture. Unix was never big on cryptic error codes (e.g. good software never prints raw errno numbers and rarely signal numbers). MS-DOS had them and so did the Amiga; I always assumed they originated in CP/M or something. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| David Brown <david.brown@hesbynett.no>: Oct 03 02:24PM +0200 On 03/10/2020 08:13, Pavel wrote: >> obvious.) > I don't think the design choices of providing simple short errors codes > and providing readable option names or pragmas are mutually exclusive. True. But I am not convinced that short error codes add that much when you have named warning options, and I am not convinced it would be helpful to have both. |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Oct 03 01:14PM -0700 > But I am not convinced that short error codes add that much when you > have named warning options, and I am not convinced it would be helpful > to have both. For one thing, there isn't a one-to-one correspondence between messages and options. For another, MS-style error codes are language-independent. If a user asks about an error message in French, it's difficult to search for it; an unambiguous error code makes that easier. I wouldn't mind if gcc added similar codes (using a distinct form that can't be confused with Microsoft's error messages), perhaps with an option to enable or disable them. Ideally they'd be coordinated with clang and any other compilers that aim for gcc compatibility. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */ |
| David Brown <david.brown@hesbynett.no>: Oct 04 12:40AM +0200 On 03/10/2020 22:14, Keith Thompson wrote: >> to have both. > For one thing, there isn't a one-to-one correspondence between > messages and options. I believe that there is a solid correspondence for messages that have a related warning flag (rather than checks that are always active). But quite possibly that correspondence could be improved. > For another, MS-style error codes are language-independent. If a > user asks about an error message in French, it's difficult to search > for it; an unambiguous error code makes that easier. The flags are language independent - they are not translated. While it's reasonable to say it's a bit unfair to use have identifiers that are terms in English, I don't think it helps to have identifiers that have no meaning in /any/ language. > can't be confused with Microsoft's error messages), perhaps with an > option to enable or disable them. Ideally they'd be coordinated with > clang and any other compilers that aim for gcc compatibility. gcc (I don't know about clang) has various options for their error messages, including colour, position highlighting, and now JSON for easier software parsing. It would not be unreasonable to have some kind of numeric identifier in that kind of output (there may be one already). I think coordination with clang here is a bit optimistic - they have quite a few differences in their warnings and error messages. It might be possible to get agreement on some of the messages, but there'd be plenty of differences. I understand that people have different opinions on this - I can only give mine, based on personal preference and personal experience of using compilers (not MSVC) with numeric codes for warning flags and messages. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 03 10:28PM +0100 Drag and drop abstracted: https://github.com/i42output/neoGFX/blob/master/include/neogfx/app/i_drag_drop.hpp That is all. /Flibble -- ¬ |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Oct 03 05:11AM -0700 >>> rearrange, then a lot of code was built with that assumption, >>> and it became effectively impossible to safely rearrange so it >>> was defined that it couldn't. I believe it was more deliberate than that. See below. > can cast between &foo and &foo.first_element). > One could easily imagine each ABI defining struct layout, with > rearrangements, in such a way that waste is minimized. I think you're overlooking an important property, and one that pertains to having code be portable. The rule in C (and later also in C++) is not just that struct members are positioned in the same order as they are declared, but also that their offsets depend only on (the types of) the previously declared members. This rule must be followed in order to (reasonably) support the semantics related to /common initial sequences/, a term defined in both the C and C++ standards. The notion that struct layouts could be rearranged as suggested above is therefore not feasible. |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Oct 03 12:49PM -0700 Tim Rentsch <tr.17687@z991.linuxsc.com> writes: [...] > semantics related to /common initial sequences/, a term defined > in both the C and C++ standards. The notion that struct layouts > could be rearranged as suggested above is therefore not feasible. To be clear, this rule isn't (quite) stated explicitly, but it follows from the common initial sequence rule in N1570 6.5.2.3. In principle I suppose a compiler could violate the rule in cases where it knows that there's no union containing a given structure as a member, but I can't think of any good reason to do so. (I'm wondering at what point I should start citing a newer draft.) -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */ |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Oct 03 05:40AM -0700 >> better choice than just 'inline'. > If you use 'static inline' you may get unwanted duplications of > the function implementation. [...] There is no reason the same thing couldn't happen with non-static inline functions, when compiled under C rules. >> inline' to 'inline' /can/ lead to linker errors - or worse, >> since using such functions can be undefined behavior. > Care to give some examples? Can you first explain why I should want to spend my time and effort to help educate someone who can't be bothered to try to discover some answers for himself? |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Oct 03 05:25AM -0700 > (In other words, the actual data inside the object, and the way it's > implemented, is hidden behind a more abstract public interface that > tells the object *what* to do, not *how* it's being done.) You're still thinking of classes and objects as abstract data types. The point of Alan's comment is that such way of thinking doesn't match what he considers an object-oriented perspective. |
| 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