- How to print instances of my classes - 3 Updates
- Using #define in the construction of an array - 4 Updates
- How to print instances of my classes - 3 Updates
- sizeof(bitfield struct) - 3 Updates
- What does operating on raw bytes mean in a C++ context? - 2 Updates
- spurious warning? - 1 Update
- neoGFX C++ ECS - 5 Updates
- Double reference - 1 Update
- About Single Responsibility Principle - 3 Updates
| ram@zedat.fu-berlin.de (Stefan Ram): Nov 06 10:23PM >What is the best and most standard way to print objects of your >classes? These actually are two questions: - What is the best /interface/ your class should support to print its object? and - What is the best /implementation/ of this interface? With regard to the interface, it was, IIRC, Herb Sutter wh who suggested something like: class example { ~~~ public: ::std::ostream & print( ::std::ostream & stream )const { ~~~ } ~~~ } inline ::std::ostream& operator << ( ::std::ostream & stream, example const & object ) { return object.print( stream ); } . For the rationales read, IIRC, "class mechanics" by Herb Sutter (preferably an updated version). |
| ram@zedat.fu-berlin.de (Stefan Ram): Nov 09 08:25PM >0, 0+1, 0+1, 0+2, 0+1, 0+1+1, 0+1+1, 0+1+2, 0+1, 0+1+1, 0+1+1, 0+1+2, 0 Yes. But only with Python, one can really see: main.py src=''' 0, 0+1, 0+1, 0+2, 0+1, 0+1+1, 0+1+1, 0+1+2, 0+1, 0+1+1, 0+1+1, 0+1+2, 0= +2, 0+2+1, 0+2+1, 0+2+2, 0+1, 0+1+1, 0+1+1, 0+1+2, 0+1+1, 0+1+1+1, 0+1+1+1,= 0+1+1+2, 0+1+1, 0+1+1+1, 0+1+1+1, 0+1+1+2, 0+1+2, 0+1+2+1, 0+1+2+1, 0+1+2+= 2, 0+1, 0+1+1, 0+1+1, 0+1+2, 0+1+1, 0+1+1+1, 0+1+1+1, 0+1+1+2, 0+1+1, 0+1+1= +1, 0+1+1+1, 0+1+1+2, 0+1+2, 0+1+2+1, 0+1+2+1, 0+1+2+2, 0+2, 0+2+1, 0+2+1, = 0+2+2, 0+2+1, 0+2+1+1, 0+2+1+1, 0+2+1+2, 0+2+1, 0+2+1+1, 0+2+1+1, 0+2+1+2, = 0+2+2, 0+2+2+1, 0+2+2+1, 0+2+2+2, 1, 1+1, 1+1, 1+2, 1+1, 1+1+1, 1+1+1, 1+1+= 2, 1+1, 1+1+1, 1+1+1, 1+1+2, 1+2, 1+2+1, 1+2+1, 1+2+2, 1+1, 1+1+1, 1+1+1, 1= +1+2, 1+1+1, 1+1+1+1, 1+1+1+1, 1+1+1+2, 1+1+1, 1+1+1+1, 1+1+1+1, 1+1+1+2, 1= +1+2, 1+1+2+1, 1+1+2+1, 1+1+2+2, 1+1, 1+1+1, 1+1+1, 1+1+2, 1+1+1, 1+1+1+1, = 1+1+1+1, 1+1+1+2, 1+1+1, 1+1+1+1, 1+1+1+1, 1+1+1+2, 1+1+2, 1+1+2+1, 1+1+2+1= , 1+1+2+2, 1+2, 1+2+1, 1+2+1, 1+2+2, 1+2+1, 1+2+1+1, 1+2+1+1, 1+2+1+2, 1+2+= 1, 1+2+1+1, 1+2+1+1, 1+2+1+2, 1+2+2, 1+2+2+1, 1+2+2+1, 1+2+2+2, 1, 1+1, 1+1= , 1+2, 1+1, 1+1+1, 1+1+1, 1+1+2, 1+1, 1+1+1, 1+1+1, 1+1+2, 1+2, 1+2+1, 1+2+= 1, 1+2+2, 1+1, 1+1+1, 1+1+1, 1+1+2, 1+1+1, 1+1+1+1, 1+1+1+1, 1+1+1+2, 1+1+1= , 1+1+1+1, 1+1+1+1, 1+1+1+2, 1+1+2, 1+1+2+1, 1+1+2+1, 1+1+2+2, 1+1, 1+1+1, = 1+1+1, 1+1+2, 1+1+1, 1+1+1+1, 1+1+1+1, 1+1+1+2, 1+1+1, 1+1+1+1, 1+1+1+1, 1+= 1+1+2, 1+1+2, 1+1+2+1, 1+1+2+1, 1+1+2+2, 1+2, 1+2+1, 1+2+1, 1+2+2, 1+2+1, 1= +2+1+1, 1+2+1+1, 1+2+1+2, 1+2+1, 1+2+1+1, 1+2+1+1, 1+2+1+2, 1+2+2, 1+2+2+1,= 1+2+2+1, 1+2+2+2, 2, 2+1, 2+1, 2+2, 2+1, 2+1+1, 2+1+1, 2+1+2, 2+1, 2+1+1, = 2+1+1, 2+1+2, 2+2, 2+2+1, 2+2+1, 2+2+2, 2+1, 2+1+1, 2+1+1, 2+1+2, 2+1+1, 2+= 1+1+1, 2+1+1+1, 2+1+1+2, 2+1+1, 2+1+1+1, 2+1+1+1, 2+1+1+2, 2+1+2, 2+1+2+1, = 2+1+2+1, 2+1+2+2, 2+1, 2+1+1, 2+1+1, 2+1+2, 2+1+1, 2+1+1+1, 2+1+1+1, 2+1+1+= 2, 2+1+1, 2+1+1+1, 2+1+1+1, 2+1+1+2, 2+1+2, 2+1+2+1, 2+1+2+1, 2+1+2+2, 2+2,= 2+2+1, 2+2+1, 2+2+2, 2+2+1, 2+2+1+1, 2+2+1+1, 2+2+1+2, 2+2+1, 2+2+1+1, 2+2= +1+1, 2+2+1+2, 2+2+2, 2+2+2+1, 2+2+2+1, 2+2+2+2=20 };=20''' import re x=r'\1' src=re.sub( chr( 10 ), r'', src ) src=re.sub( '=20', r'', src ) src=re.sub( '=', r'', src ) re.sub( r'(\+?[0-2](?:\+[0-2])*)', lambda x:print("{0:04b}".format(eval(x.group(0)))), src ) transcript 0000 0001 0001 0010 0001 0010 0010 0011 0001 0010 0010 0011 0010 0011 0011 0100 0001 0010 0010 0011 0010 0011 0011 0100 0010 0011 0011 0100 0011 0100 0100 0101 0001 0010 0010 0011 0010 0011 0011 0100 0010 0011 0011 0100 0011 0100 0100 0101 0010 0011 0011 0100 0011 0100 0100 0101 0011 0100 0100 0101 0100 0101 0101 0110 0001 0010 0010 0011 0010 0011 0011 0100 0010 0011 0011 0100 0011 0100 0100 0101 0010 0011 0011 0100 0011 0100 0100 0101 0011 0100 0100 0101 0100 0101 0101 0110 0010 0011 0011 0100 0011 0100 0100 0101 0011 0100 0100 0101 0100 0101 0101 0110 0011 0100 0100 0101 0100 0101 0101 0110 0100 0101 0101 0110 0101 0110 0110 0111 0001 0010 0010 0011 0010 0011 0011 0100 0010 0011 0011 0100 0011 0100 0100 0101 0010 0011 0011 0100 0011 0100 0100 0101 0011 0100 0100 0101 0100 0101 0101 0110 0010 0011 0011 0100 0011 0100 0100 0101 0011 0100 0100 0101 0100 0101 0101 0110 0011 0100 0100 0101 0100 0101 0101 0110 0100 0101 0101 0110 0101 0110 0110 0111 0010 0011 0011 0100 0011 0100 0100 0101 0011 0100 0100 0101 0100 0101 0101 0110 0011 0100 0100 0101 0100 0101 0101 0110 0100 0101 0101 0110 0101 0110 0110 0111 0011 0100 0100 0101 0100 0101 0101 0110 0100 0101 0101 0110 0101 0110 0110 0111 0100 0101 0101 0110 0101 0110 0110 0111 0101 0110 0110 0111 0110 0111 0111 1000 |
| ram@zedat.fu-berlin.de (Stefan Ram): Nov 09 08:38PM >Yes. But only with Python one can really see: (I was assuming that the bit patterns of the values did matter.) |
| Paul <pepstein5@gmail.com>: Nov 09 09:12AM -0800 Below is part of some code for counting how many bits of an integer are set, using a lookup table. I don't understand at all the way that #define is being used. I'm fine with the static const unsigned char BitsSetTable256[256] declaration but I don't get how we can populate an array with #define statements. It does compile though with gcc. I'd be very grateful if anyone can explain it to me. Thank you, Paul static const unsigned char BitsSetTable256[256] = { # define B2(n) n, n+1, n+1, n+2 # define B4(n) B2(n), B2(n+1), B2(n+1), B2(n+2) # define B6(n) B4(n), B4(n+1), B4(n+1), B4(n+2) B6(0), B6(1), B6(1), B6(2) }; |
| Thiago Adams <thiago.adams@gmail.com>: Nov 09 09:43AM -0800 On Friday, November 9, 2018 at 3:12:28 PM UTC-2, Paul wrote: > # define B6(n) B4(n), B4(n+1), B4(n+1), B4(n+2) > B6(0), B6(1), B6(1), B6(2) > }; The preprocessor is an separated step and doesn't matter where you use #define. The expansion is here B6(0), B6(1), B6(1), B6(2) After expansion, what the compiler will see is this: static const unsigned char BitsSetTable256[256] = { 0, 0+1, 0+1, 0+2, 0+1, 0+1+1, 0+1+1, 0+1+2, 0+1, 0+1+1, 0+1+1, 0+1+2, 0+2, 0+2+1, 0+2+1, 0+2+2, 0+1, 0+1+1, 0+1+1, 0+1+2, 0+1+1, 0+1+1+1, 0+1+1+1, 0+1+1+2, 0+1+1, 0+1+1+1, 0+1+1+1, 0+1+1+2, 0+1+2, 0+1+2+1, 0+1+2+1, 0+1+2+2, 0+1, 0+1+1, 0+1+1, 0+1+2, 0+1+1, 0+1+1+1, 0+1+1+1, 0+1+1+2, 0+1+1, 0+1+1+1, 0+1+1+1, 0+1+1+2, 0+1+2, 0+1+2+1, 0+1+2+1, 0+1+2+2, 0+2, 0+2+1, 0+2+1, 0+2+2, 0+2+1, 0+2+1+1, 0+2+1+1, 0+2+1+2, 0+2+1, 0+2+1+1, 0+2+1+1, 0+2+1+2, 0+2+2, 0+2+2+1, 0+2+2+1, 0+2+2+2, 1, 1+1, 1+1, 1+2, 1+1, 1+1+1, 1+1+1, 1+1+2, 1+1, 1+1+1, 1+1+1, 1+1+2, 1+2, 1+2+1, 1+2+1, 1+2+2, 1+1, 1+1+1, 1+1+1, 1+1+2, 1+1+1, 1+1+1+1, 1+1+1+1, 1+1+1+2, 1+1+1, 1+1+1+1, 1+1+1+1, 1+1+1+2, 1+1+2, 1+1+2+1, 1+1+2+1, 1+1+2+2, 1+1, 1+1+1, 1+1+1, 1+1+2, 1+1+1, 1+1+1+1, 1+1+1+1, 1+1+1+2, 1+1+1, 1+1+1+1, 1+1+1+1, 1+1+1+2, 1+1+2, 1+1+2+1, 1+1+2+1, 1+1+2+2, 1+2, 1+2+1, 1+2+1, 1+2+2, 1+2+1, 1+2+1+1, 1+2+1+1, 1+2+1+2, 1+2+1, 1+2+1+1, 1+2+1+1, 1+2+1+2, 1+2+2, 1+2+2+1, 1+2+2+1, 1+2+2+2, 1, 1+1, 1+1, 1+2, 1+1, 1+1+1, 1+1+1, 1+1+2, 1+1, 1+1+1, 1+1+1, 1+1+2, 1+2, 1+2+1, 1+2+1, 1+2+2, 1+1, 1+1+1, 1+1+1, 1+1+2, 1+1+1, 1+1+1+1, 1+1+1+1, 1+1+1+2, 1+1+1, 1+1+1+1, 1+1+1+1, 1+1+1+2, 1+1+2, 1+1+2+1, 1+1+2+1, 1+1+2+2, 1+1, 1+1+1, 1+1+1, 1+1+2, 1+1+1, 1+1+1+1, 1+1+1+1, 1+1+1+2, 1+1+1, 1+1+1+1, 1+1+1+1, 1+1+1+2, 1+1+2, 1+1+2+1, 1+1+2+1, 1+1+2+2, 1+2, 1+2+1, 1+2+1, 1+2+2, 1+2+1, 1+2+1+1, 1+2+1+1, 1+2+1+2, 1+2+1, 1+2+1+1, 1+2+1+1, 1+2+1+2, 1+2+2, 1+2+2+1, 1+2+2+1, 1+2+2+2, 2, 2+1, 2+1, 2+2, 2+1, 2+1+1, 2+1+1, 2+1+2, 2+1, 2+1+1, 2+1+1, 2+1+2, 2+2, 2+2+1, 2+2+1, 2+2+2, 2+1, 2+1+1, 2+1+1, 2+1+2, 2+1+1, 2+1+1+1, 2+1+1+1, 2+1+1+2, 2+1+1, 2+1+1+1, 2+1+1+1, 2+1+1+2, 2+1+2, 2+1+2+1, 2+1+2+1, 2+1+2+2, 2+1, 2+1+1, 2+1+1, 2+1+2, 2+1+1, 2+1+1+1, 2+1+1+1, 2+1+1+2, 2+1+1, 2+1+1+1, 2+1+1+1, 2+1+1+2, 2+1+2, 2+1+2+1, 2+1+2+1, 2+1+2+2, 2+2, 2+2+1, 2+2+1, 2+2+2, 2+2+1, 2+2+1+1, 2+2+1+1, 2+2+1+2, 2+2+1, 2+2+1+1, 2+2+1+1, 2+2+1+2, 2+2+2, 2+2+2+1, 2+2+2+1, 2+2+2+2 }; |
| jameskuyper@alumni.caltech.edu: Nov 09 09:57AM -0800 On Friday, November 9, 2018 at 12:12:28 PM UTC-5, Paul wrote: > # define B6(n) B4(n), B4(n+1), B4(n+1), B4(n+2) > B6(0), B6(1), B6(1), B6(2) > }; It's not populating the array with #define statements. That code would work exactly the same if the #defines were moved well ahead of the array declaration: # define B2(n) n, n+1, n+1, n+2 # define B4(n) B2(n), B2(n+1), B2(n+1), B2(n+2) # define B6(n) B4(n), B4(n+1), B4(n+1), B4(n+2) static const unsigned char BitsSetTable256[256] = { B6(0), B6(1), B6(1), B6(2) }; The key thing you need to understand is that #definition of a macro causes subsequent occurrences of that macro to be replaced by it's replacement list. This can be a multi-pass process, and that is the case here. The first pass causes the declaration to be re-written as follows: static const unsigned char BitsSetTable256[256] = { B4(0), B4(0+1), B4(0+1), B4(0+2), B4(1), B4(1+1), B4(1+1), B4(1+2), B4(1), B4(1+1), B4(1+1), B4(1+2), B4(2), B4(2+1), B4(2+1), B4(2+2) }; The next pass replaces every occurrence of B4() with four occurrences of B2(). For instance, "B4(1+1)" gets replaced by "B2(1+1), B2(1+1+1), B2(1+1+1), B2(1+1+2)". The final pass replaces every occurrence of B2() with a list of four individual expressions. For instance, "B2(1+1+1)" gets replaced by "1+1+1, 1+1+1+1, 1+1+1+1, 1+1+1+2". Does that make it clearer? |
| Paul <pepstein5@gmail.com>: Nov 09 12:25PM -0800 > with a list of four individual expressions. For instance, "B2(1+1+1)" > gets replaced by "1+1+1, 1+1+1+1, 1+1+1+1, 1+1+1+2". > Does that make it clearer? Yes, my question has been answered. The result is apparently that, for 0 <= k <=255, BitsSetTable[k] = number of bits set in the binary expansion of k. No clue why this works, though. It's neat. Paul |
| Paavo Helde <myfirstname@osa.pri.ee>: Nov 06 07:57PM +0200 On 6.11.2018 19:11, Steve Keller wrote: > std::string toString() const { > However, I prefer to implement functions that print to std::ostream > directly, The stream approach is architecturally more sound, more flexible and more customizable. For example, if your object "stringification" involves floating-point numbers then the toString() function has to decide how to format the decimal point: by the current locale, always as '.', etc. When using the stream approach, the client code is assumed to know what it wants and to imbue the needed locale to the stream. At least this is the intention. In practice the customization possibilities provided by locales are often far too few and too little to provide anything better than inconsistencies and grammar errors, so I'm not sure if they do more good than harm. The strings approach typically avoids all this flexibility and customizations. This means the result is always in fixed format and the performance is usually better (string+= won up to 2x in my measurements, compared to ostringstream<<). So the answer depends on your needs and preferences. Is the printout meant for humans or for other software? If for humans, is it for a single person or for many? Is the speed important? Is fixed format important? Etc. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Nov 06 07:48PM On Tue, 2018-11-06, Steve Keller wrote: > s << "{..." << /* more items */ << "}"; > return s.str(); > }; ... > However, I prefer to implement functions that print to std::ostream > directly, instead of writing to std::stringstream, then creating a > string, and then printing the string to an ostream: ... > Since I see the first method so often I wonder if there is something wrong > with my solution. Does the above approach have any advantages I don't see? I suspect the first approach is a Java/whatever other language influence. To me it means working against the intention of the language (but I don't see it much). /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| red floyd <dont.bother@its.invalid>: Nov 06 02:09PM -0800 On 11/6/2018 12:33 PM, Alf P. Steinbach wrote: > On 06.11.2018 18:11, Steve Keller wrote: ------------ > static const Type_<const char*> names[] = {"A", "B", C"}; > return names[e]; > } In this individual case, yes, an array works. But remember, enums do not need to be consecutive, in which case some other mechanism is required. One size does not fit all. |
| Juha Nieminen <nospam@thanks.invalid>: Nov 06 01:37PM > When it is "extremely simple" (just implementation dependent) then there > must be is a standard compliant way to static assert that we got the layout > that we wanted. Is there such a way? There aren't always ways to static_assert such things. For example, there is no standard-compliant way to static_assert that we are compiling for a little-endian system, for instance. (This might be on purpose.) |
| David Brown <david.brown@hesbynett.no>: Nov 06 04:08PM +0100 On 06/11/18 15:49, Rick C. Hodgin wrote: > size in bytes, and the bitsizeof() to return the size in bits, and > that will be globally, not just on bitfield structs or members. > Good day, David. Adding a "bitsizeof" operator for bit-fields seems reasonable enough. I don't see a lot of potential use for it, but I know we have very different opinions on that sort of thing (I want to know a feature is very useful before adding it, you prefer to add early and let the user decide if they want to use it). |
| David Brown <david.brown@hesbynett.no>: Nov 06 03:40PM +0100 On 06/11/18 15:08, Rick C. Hodgin wrote: >>> be rounded to the nearest larger byte. >> You write that as though it was some sort of indisputable fact. > It is. This is like arguing with a wall. Look, your opinion does not match that of compiler writers, ABI designers, language designers or programmers. These folks have come to different conclusions about the best way to implement bit-fields - not always to the same conclusions, but often different from yours. You are not smarter than these folks. You are not able to see something that they are missing. You are not able to divine some sort of "fundamental" issue to which they are blind. You are simply a developer with an opinion (which is fine), and an over-inflated sense of the value of that opinion (which is not fine). > in the bitfield, compared to the sizeof() the type it represents, > compared to the sizeof() the entire bitfield struct, compared to > the size of the entire structure expanded to its expressed types. You can't - not with standard C or C++, and not with any existing extensions I am aware of. People have programmed in C for 40 years without such features, so I don't think the need of them is particularly pressing. But if you feel they would be useful, put them into your own language. (I have often felt that a bit more introspection capabilities in C and C++ would be nice, though I have never felt the need of it for bit-fields.) (There is a proposal for adding introspection to C++, but that is going to be a much bigger feature.) > I think bitfield structs are not yet completely cooked in the > existing compilers. Just enough to get it close, but they didn't > bring it to a close. Bit-fields certainly have their limitations, and their loose implementation-defined nature makes them difficult for portability. With appropriate care, they have their place in programming, and many people use them. But when designing a new language with different requirements than C, it may make sense to create an alternative with much stricter rules. |
| Juha Nieminen <nospam@thanks.invalid>: Nov 06 01:33PM > I think it is fair to say that if your code would ever be running on > something that has CHAR_BIT not equal to 8, you would know it. That being said, the way I presented the solution would still work even if CHAR_BIT is larger than 8. (Every element of the vector is handled as it if were 8 bits in size, but there's nothing that would break if it were larger.) It would only malfunction if CHAR_BIT is less than 8. The assumption I made in the solution I presented is that chars are *at least* 8 bits in size. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Nov 06 12:27PM +0100 On 05.11.2018 21:21, Juha Nieminen wrote: >> Are you sure that CHAR_BIT, the number of bits per byte, equals 8? > Does any computer system where CHAR_BIT isn't 8 even running > anymore? Embedded computing stuff. E.g. Texas Instruments digital signal processors. Cheers!, - Alf |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Nov 06 06:24PM On 6 Nov 2018 01:50:02 GMT > | ^~~~~~~~~~~~~ > Does this warning make sense for a /non-member/ function? > Also feel free to suggest any improvements to my code! [snip] This warning seems to be concerned with gcc function attributes rather than the C and C++ keyword 'const'. If so, it signifies that the function does not read any global data and only depends on its arguments: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes It looks as if you have specifically asked for this "warning" (it isn't really a warning) with the -Wsuggest-attribute=const compiler flag. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Nov 09 12:32AM On 08/11/2018 19:32, Rick C. Hodgin wrote: [snip] > I post this information to give you some inspiration, Leigh. A lot > of features packed into fox-toolkit, and they're free. You post this information for no other reason than to troll my thread. I don't need inspiration from the likes of you and I don't need to research other GUI libraries to be able to implement one myself: I have been using GUIs for the past thirty years and already have a clear idea in my mind as to what I want to achieve. [snip] /Flibble -- "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Nov 08 05:08PM -0800 On Thursday, November 8, 2018 at 7:32:55 PM UTC-5, Mr Flibble wrote: > other GUI libraries to be able to implement one myself: I have been using > GUIs for the past thirty years and already have a clear idea in my mind as > to what I want to achieve. People need advisors. The enemy (the one you say doesn't exist (Satan)) works very hard to get people into isolation so they can be more and more deceived by his guidance, and less and less guided by the influence of God at work in others. https://www.biblegateway.com/passage/?search=Proverbs+15%3A22&version=KJV 22 Without counsel purposes are disappointed: but in the multitude of counsellors they are established. I do not troll your thread. But I do want you to see what you are up against. There are alternative free and open options people and businesses can use, whereby they also receive the full source code to make any adaptations they need, and all under the GNU Lesser license so they can link to the binaries, and not have to reveal their own source code, meaning proprie- tary business models. It's something to consider. I've been testing FOX Toolkit and it is very capable. A few wrapper classes and a full business app capable suite can be created, and in just a few days. It's rather exciting for me to have found it actually. -- Rick C. Hodgin |
| "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Nov 08 10:29PM -0800 On 10/19/2018 10:42 AM, Mr Flibble wrote: > multi-threaded support so that different ECS systems can run in > different threads. > https://github.com/i42output/neoGFX Can one introduce their own custom GLSL shader code into the mix? |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Nov 09 02:15PM On 09/11/2018 06:29, Chris M. Thomasson wrote: >> different threads. >> https://github.com/i42output/neoGFX > Can one introduce their own custom GLSL shader code into the mix? Of course. /Flibble -- "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Nov 09 02:18PM On 09/11/2018 01:08, Rick C. Hodgin wrote: [snip] > People need advisors. The enemy (the one you say doesn't exist And Satan invented fossils, yes? > It's something to consider. I've been testing FOX Toolkit and It isn't something that I want to consider; now, bigoted Christian, please fuck off. /Flibble -- "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| Manfred <noname@add.invalid>: Nov 09 02:09PM +0100 On 11/8/2018 11:35 PM, Queequeg wrote: >> } > Yes, with printfs it's simple, but how would you do it with write(), which > expects an area of memory and its size (that's why fn1() expects the same)? #include <cstdio> void f1(void *p) { int fd = ...; printf("f1: address is %p\n", p); write(fd, &p, sizeof(p)); } int main() { int i; f1(&i); } |
| Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Nov 09 12:11AM -0500 JiiPee wrote: > windows as well. or not? > CView is only one type of window, there are like 20 other windows where you > could also draw opengl... at least in theory This is probably correct more often than not, but still not always. An example where it might not be that straighforward: if whatever you want to draw using openGL requires data from your CDocument, you won't have that in CDialog. Obviously, a particular kind of document may be displayed in more than one kind of view -- but even then some parameters of the view can alter how the information from the document is displayed. You can certainly try to extract these parameters from a view and feed your renderer with these parameters and information from that document -- but this logic, in combination with drawing code, will most certainly take more than 20 lines of code. Or, if what you are creating is some small custom reusable cool visual component (say, a custom button, whose document is, for example, some very special combination of text some graphics and animation, specific to that component, possibly dynamic i.e. changing with time), it is highly unlikely that you need another view with exactly same drawing + interaction logic -- and view is good for wiring in all the data and user-interaction events (if any); then you might appreciate packing this all in a single class. Your desired rendering may need to rely on more view-specific data (I do not mean document, but, say, even CWnd and parent CWnd parameters and events) than you initially planned and you might find yourself busy programming wiring from those to your openGL renderer instead of working on actual drawing. On the other hand, if you want to provide two ways of rendering: one basic with GDI and another, advanced, with OpenGL, you will have to decompose your data flows anyway. But even then it might turn out easier to just create two parallel views, basic and advanced -- because a view essentially is not much more than wiring connecting rendering to document data, events and window system state. Also, event handling might want some information back from the renderer for usability -- think of clicking on animated object. Where you might really appreciate a separate renderer and data flow decomposition is in porting your app or component away from MFC to another platform allowing OpenGL. Just remember that work on portable/multi-platform components and that decomposition will take your valuable time, so I would not do it just because it is "the right thing". Long story short -- optimal design depends on what you are doing, what data the renderer will eventually need and the feedback the view might need from the renderer. |
| JiiPee <no@notvalid.com>: Nov 09 08:44AM On 09/11/2018 05:11, Pavel wrote: > An example where it might not be that straighforward: if whatever you want to > draw using openGL requires data from your CDocument, you won't have that in > CDialog. 1) Does the opengl data need to be defined in CDocument? Can we do this: class MyOpenGLData { // data for opengl } class CMyDocument : CDocument { MyOpenGLData m_openglData; } And thus CMyDocument would only have non-opengl data. This way Renderer and OpenglDAta are both isolated from the MFC view/documen/frame system 2) How about doing this only for those windows/views which uses CDocument, like ScrollView, FormView. So then would be easy to re-use it in those views, and if needs to use it in CDialog then could do it in a different way there. I am not sure if CDocument can be used with CDialog/CWnd. So it cannot be used with them? |
| JiiPee <no@notvalid.com>: Nov 09 09:09AM On 09/11/2018 05:11, Pavel wrote: > and parent CWnd parameters and events) than you initially planned and you might > find yourself busy programming wiring from those to your openGL renderer instead > of working on actual drawing. You mean that all future Views/Windows would have totally different drawing needs, thus renderer would not be a good way to handle them all as the windows have totally different drawing needs? In my project this is not really the case as all windows will be drawing simple graphics like shapes, boxes, x,y,z axis, wireframes etc. Things normally drawn in 3D modelling. > On the other hand, if you want to provide two ways of rendering: one basic with > GDI and another, advanced, with OpenGL, No, this is not a plan. Only opengl. Also that seems alot of work to separate them. Only if needed in the future then would do that. But not if there is no immediate need. > platform allowing OpenGL. Just remember that work on portable/multi-platform > components and that decomposition will take your valuable time, so I would not > do it just because it is "the right thing". I am not planning it to be portable like this. > Long story short -- optimal design depends on what you are doing, what data the > renderer will eventually need and the feedback the view might need from the > renderer. The drawing will be simple OpenGL drawing modelling 3D objects (like tools, table, etc... like the 3D modelling programs.). rotating them, zooming etc... all basic functionalities. |
| 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