- how/why it is written ... int &numberRef; vs int& numberRef; - 4 Updates
- main2(), kernel_main (c/c++) - 8 Updates
- WxWidgets events question - 7 Updates
- #define - 3 Updates
- My updated "C++ coding style" page now is also in English - 2 Updates
| G G <gdotone@gmail.com>: Jul 12 03:12PM -0700 i know that is the same thing but i would ask the group to discuss the reasoning, their thoughts, as to why int& numberRef; is a better or more understandable way in their mind set for those thinking that way along with, int* aPointer; my question is why associate the *, or & the the type instead of the name? i do understand it is a preference. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jul 12 11:16PM +0100 On 12/07/2019 23:12, G G wrote: > along with, int* aPointer; > my question is why associate the *, or & the the type instead of the > name? i do understand it is a preference. OMFG not this again, pls. /Flibble -- "Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin "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." |
| G G <gdotone@gmail.com>: Jul 12 03:21PM -0700 On Friday, July 12, 2019 at 6:17:08 PM UTC-4, Mr Flibble wrote: > OMFG not this again, pls. > /Flibble no wars please... just a thought or two as to the thinking. the book i'm reading does not suggest one over the other |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Jul 12 06:55PM -0400 On 7/12/19 6:12 PM, G G wrote: > along with, int* aPointer; > my question is why associate the *, or & the the type instead of the > name? i do understand it is a preference. A simple declaration consists of a decl-specifier-seq followed by an init-declarator-list (10.1p1). In this case, int is the decl-specifier-seq (10.1.7.2p1) and *aPointer or &numberRef are the only declarators in their respective init-declarator-lists (11.1p4). That distinction doesn't matter if the init-declarator-list only contains one declarator. However, if it contains two or more declarators, I consider it helpful to keep track of the fact that & and * only apply to the immediately following declarators, and not to any of the other declarators in the same list. I find it easier to do so if I keep a space between the decl-specifier-seq and the init-declarator-list, and if I don't insert a space between the * or & and the rest of the declartor that it is part of: int *aPointer, &numberRef; * applies only to aPointer, and & applies only to numberRef. If I wrote something like int* aPointer, aFunc(void); a newbie might easily make the mistake of thinking that aFunc() returns an int*, rather than an int. It's a minor advantage, and many people prefer not to declare more than one declator per declaration, so for them it's no advantage at all. |
| scott@slp53.sl.home (Scott Lurndal): Jul 12 02:17PM >> and M68000 assembly language. >The m68k ISA is a really nice design. The original 68000 was very >forward-looking Personally, I find the PDP-11 to be a nice design. 68000 had differentiated registers (A0-A6, D0-D7) while on the PDP-11 any register could contain data or an address. For that matter, modern x86_64 is actually no so bad (the biggest warts with the original 8086/80286 were related to segmented memory). |
| David Brown <david.brown@hesbynett.no>: Jul 12 05:21PM +0200 On 12/07/2019 16:17, Scott Lurndal wrote: > Personally, I find the PDP-11 to be a nice design. 68000 had > differentiated registers (A0-A6, D0-D7) while on the PDP-11 any > register could contain data or an address. I haven't used the PDP-11, but I have used the msp430 microcontrollers which have a very similar ISA. And they too are very pleasant cpus to work with in assembly language or C. > For that matter, modern x86_64 is actually no so bad (the biggest > warts with the original 8086/80286 were related to segmented memory). Certainly it seems to be a lot better than older x86 - more registers and fewer register specific instructions helps. |
| Bart <bc@freeuk.com>: Jul 12 05:36PM +0100 On 12/07/2019 15:17, Scott Lurndal wrote: > Personally, I find the PDP-11 to be a nice design. 68000 had > differentiated registers (A0-A6, D0-D7) while on the PDP-11 any > register could contain data or an address. You had to look at it in more detail to find out it wasn't as orthogonal as it appeared at first, and actually wasn't that much better in that regard than x86. Those two kinds of registers are a prime example, if your job is to write a compiler for it (does a function returning int* return it in A0 or D0?). Much better from that era, but eclipsed by x86 and 68k, were Z8000/0 and NatSemi 32032 family. > For that matter, modern x86_64 is actually no so bad (the biggest > warts with the original 8086/80286 were related to segmented memory). You need to have written both a disassembler for x64 machine code, and an assembler that generates that code, to see what a ghastly mess the instruction encoding is. The underlying instruction set still has largely the same design as for the 8086, with 3 bits to specify /16/ registers, and 1 bit to specify /4/ operand sizes, requiring various instruction prefix overrides, or prefix bytes containing the missing bits. On top of prefix bytes to extend the number of opcodes. |
| red floyd <dont.bother@its.invalid>: Jul 12 10:44AM -0700 On 7/12/2019 7:17 AM, Scott Lurndal wrote: > register could contain data or an address. > For that matter, modern x86_64 is actually no so bad (the biggest > warts with the original 8086/80286 were related to segmented memory). Z8000, anyone? Similar to 68K, but the registers were all general, no differentiation. Z8000 was 16 bit registers, but could be subdivided into upper/lower half for bytes, and combined with an adjacent register for 32-bit registers (e.g. RR0 was R0 and R1 combined). Z80000 was the 32-bit version, doubled the number of registers, and allowed 64-bit "quad" registers. |
| scott@slp53.sl.home (Scott Lurndal): Jul 12 05:53PM >You need to have written both a disassembler for x64 machine code, and >an assembler that generates that code, to see what a ghastly mess the >instruction encoding is. So two programmers in the entire world care about the instruction encoding; The instruction encoding is not relevent to anyone else. (actually, make that three, for those of us who write processor simulators for a living, we need to decode (and execute) the instruction set). Take a look at Aarch32/Thumb or Aarch64 if you want interesting instruction set encodings. Take a look at Burroughs Medium Systems mainframes for a very simple encoding. http://vseries.lurndal.org/doku.php?id=architecture#instruction_representation http://vseries.lurndal.org/doku.php?id=instructions >/4/ operand sizes, requiring various instruction prefix overrides, or >prefix bytes containing the missing bits. On top of prefix bytes to >extend the number of opcodes. That's to be expected from such a venerable architecture. And it isn't relevent to more than a handful of programmers world-wide who happen to write new assemblers for an architecture with a dozen or more existing production quality assemblers, most in the public domain. |
| scott@slp53.sl.home (Scott Lurndal): Jul 12 06:35PM >(actually, make that three, for those of us who write processor >simulators for a living, we need to decode (and execute) the instruction >set). Ah, make that four - our hypervisor did have to simulate a handful of instructions when trapping guest accesses to virtual PCI I/O devices. e.g. // Decode the instruction. c_instr_iterator iter((void *)instr, rip); len = get_operand_length(&iter); // Interpret the instruction. switch (iter.get_opcode()) { case 0xb60f: // movzb mem, reg value = trace->mem_read(addr, BYTE); value >>= ((addr & 0x3) * BITS_PER_BYTE); value &= (1UL << 8 * BYTE) - 1; set_reg_value(regs, iter.get_modRM(REG), value, len); break; case 0xb70f: // movzw mem, reg value = trace->mem_read(addr, WORD); value >>= ((addr & 0x3) * BITS_PER_BYTE); value &= (1UL << 8 * WORD) - 1; set_reg_value(regs, iter.get_modRM(REG), value, len); break; ...etc for most other instructions that access memory. But it is still very rare for anyone else to care about the instruction encoding. |
| Bart <bc@freeuk.com>: Jul 12 08:14PM +0100 On 12/07/2019 18:53, Scott Lurndal wrote: > Take a look at Burroughs Medium Systems mainframes for a very simple encoding. > http://vseries.lurndal.org/doku.php?id=architecture#instruction_representation > http://vseries.lurndal.org/doku.php?id=instructions That's not that simple. Simpler IMO was PDP10 with fixed, not multiple length instuctions. Instruction codes, register specifiers, and immediate data/address operands are contained within one 36-bit word. > it isn't relevent to more than a handful of programmers world-wide > who happen to write new assemblers for an architecture with a dozen > or more existing production quality assemblers, most in the public domain. I think the number is more than that. Look at the numerous resources for online assembly and disassembly. And you have to wonder how the sprawling instructions impact efficiency: how much on-chip area is used up decoding them, how many of the limited number of bytes in an instruction pipeline are holding rex, data, address, escape and other prefix bytes that would otherwise be more compactly contained within the instruction. |
| scott@slp53.sl.home (Scott Lurndal): Jul 12 08:00PM >number of bytes in an instruction pipeline are holding rex, data, >address, escape and other prefix bytes that would otherwise be more >compactly contained within the instruction. I can't speak for x86, but the AArch instruction encoding is baroque specifically to make the hardware design easier. Given the microcoded nature of the x86 processor and given that the majority of frequently used instructions have a single-cycle latency, I don't see that the complexity of the instruction set has impacted performance. It does, to a certain extent, impact the area required, but the vast majority of area on a processor chip is devoted to L1 and L2 caches. |
| Melzzzzz <Melzzzzz@zzzzz.com>: Jul 11 12:29AM > Yes Qt is currently the *least worst* offering as far as a cross platform > C++ GUI library is concerned but I intend to improve on that sorry state > of affairs with neoGFX. Cross platform is not in interrest of M$ and Apple$... -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
| "Öö Tiib" <ootiib@hot.ee>: Jul 10 05:45PM -0700 On Thursday, 11 July 2019 01:56:28 UTC+3, Mr Flibble wrote: > Qt Company's primary product marketing on their website puts QML front and > centre so that is rather telling as to what their primary focus is. My > (neoGFX) scripting support will be entirely optional in the primary work flow. Each IT company of any significance seems to push some java, csharp, actionscript, golang, swift, qml etc. instead of C++. Microsoft has even second level distraction language managedc++cli. Such distract dummies to program in some kind of "C++ for dummies" and that is good ... less dummies in my teams. ;) > Yes Qt is currently the *least worst* offering as far as a cross platform > C++ GUI library is concerned but I intend to improve on that sorry state > of affairs with neoGFX. About your project ... I would concentrate on optimizing it to target asm.js ... Qt kind of works in browser but feels sluggish and that Unreal Engine is even worse. When something runs well in browser then it will run at least 4 times better as native app. Also it is most cheap to demo asm.js stuff in web. ;) |
| Szyk Cech <szykcech@spoko.pl>: Jul 11 05:57AM +0200 W dniu 11.07.2019 o 00:05, Öö Tiib pisze: > Usage of GUI scripting with QML is not anyhow forced by it. Why do you tell this? I wrote that they force to use QML in mobile apps. If you want write mobile apps in C++ then you will see many difficulties: * widgets not prepared for finger (small controls) - QML styled widgets are not exposed to C++ - you will have to create your own styles for widgets for mobile apps. * some widgets behaviour present in QML is not exposed to C++. I talk about animations in GUI. p8mode wants to use QtQuick without QML and talk about this years ago on official Qt forum: https://forum.qt.io/topic/20843/qtquick-without-qml-pure-c-apps-possible/4 The answer was: "While passions run high on this issue and there are good points to be made by all parties involved, the short answer is that a QML-less Qt Quick is not on the immediate Qt roadmap." Up to now seems they change nothing in their minds. |
| "Öö Tiib" <ootiib@hot.ee>: Jul 10 10:16PM -0700 On Thursday, 11 July 2019 06:57:42 UTC+3, Szyk Cech wrote: > W dniu 11.07.2019 o 00:05, Öö Tiib pisze: > > Usage of GUI scripting with QML is not anyhow forced by it. > Why do you tell this? I wrote that they force to use QML in mobile apps. And I wrote they don't. > widgets for mobile apps. > * some widgets behaviour present in QML is not exposed to C++. I talk > about animations in GUI. None of QML is needed at all. > p8mode wants to use QtQuick without QML and talk about this years ago on > official Qt forum: > https://forum.qt.io/topic/20843/qtquick-without-qml-pure-c-apps-possible/4 Weird request, the Qt Quick module is the standard library for writing QML applications. I said that QML is not needed and so also Qt Quick is not needed for writing apps. It is OK for whipping up some quick throw-away prototypes, that is it. > made by all parties involved, the short answer is that a QML-less Qt > Quick is not on the immediate Qt roadmap." > Up to now seems they change nothing in their minds. So you want to use module of Qt for writing QML applications but you don't want to write QML applications? Nonsense. |
| Szyk Cech <szykcech@spoko.pl>: Jul 12 05:35PM +0200 W dniu 11.07.2019 o 07:16, Öö Tiib pisze: > So you want to use module of Qt for writing QML applications but > you don't want to write QML applications? Nonsense. Programmer can't be so lame to tell this! You talk nonsense! Qt Quick classes were written in C++ and exposed to QML exclusively. So there is no technical reasons to not use it in pure C++ apps. Only the Qt vendor lock politics prohibit programmers from this! If you don't know about Qt history, architecture, and politics - don't write. Otherwise you appear as ignorant (which is soft term mean: stupid). |
| "Öö Tiib" <ootiib@hot.ee>: Jul 12 11:17AM -0700 On Friday, 12 July 2019 18:35:51 UTC+3, Szyk Cech wrote: > > So you want to use module of Qt for writing QML applications but > > you don't want to write QML applications? Nonsense. > Programmer can't be so lame to tell this! You talk nonsense! Next you start to use all caps like that false prophet Rick C Hodgin. :D > Qt Quick classes were written in C++ and exposed to QML exclusively. So > there is no technical reasons to not use it in pure C++ apps. Only the > Qt vendor lock politics prohibit programmers from this! You can use all code that is open source in Qt however you please within limits of that LGPL. And LGPL just means that you have to make source code of your hacks of library available to others. Classes designed for one thing are hard to hack to do some other thing (that these were not designed for) and so these may stop functioning and start to crash. That is all that "prohibits" you and makes you to whine about evil conspiracies. All I was saying was that Qt without using that Qt Quick bloat is plenty. > If you don't know about Qt history, architecture, and politics - don't > write. Otherwise you appear as ignorant (which is soft term mean: stupid). Yes, it is responding to blockheads like you that makes me to appear stupid. Remember, you started this thread by demonstrating incapability to read https://docs.wxwidgets.org/trunk/overview_events.html :D |
| Szyk Cech <szykcech@spoko.pl>: Jul 12 08:38PM +0200 W dniu 12.07.2019 o 20:17, Öö Tiib pisze: > That is all that "prohibits" you and makes you to whine about evil > conspiracies. All I was saying was that Qt without using that Qt > Quick bloat is plenty. Actually I have done some thing like hack official sources. But not Qt it self but Qt Creator code. I have few ideas of improvement it. But I hate to do this with every Qt Creator release and after patching few releases I give up! I think it will be the same with hack Qt (beside potentially unstability). So: Qt Quick classes should be usable from C++ out of the box! |
| legalize+jeeves@mail.xmission.com (Richard): Jul 10 04:46PM [Please do not mail me a copy of your followup] G G <gdotone@gmail.com> spake the secret code >#define _PROTOTYPE(function, params) function params >how does this work? Lamely. :-) Seriously, this looks like someone is using a macro to avoid the syntax of the language. Just use the ordinary syntax. I suppose they might have done this because they had scripts parsing a file and wanted to make it easier for a script to extra meta information from the declarations. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://computergraphicsmuseum.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| legalize+jeeves@mail.xmission.com (Richard): Jul 10 04:51PM [Please do not mail me a copy of your followup] gazelle@shell.xmission.com (Kenny McCormack) spake the secret code >>time ago - the first C standard is 30 years old - older than many >>(most?) of the people writing C code. >I seriously doubt that. Aren't more C programmers old farts like us? It depends on the application market segment. While it was routine to write everything in C/C++ from the 80s and into the 90s, other languages have arrived on the scene that have found their niche. Java is dominant in enterprise level applications (with exceptions such as financial trading) where people hate MS, C# is dominant in MS enterprise applications or for Windows desktop applications (with exceptions such as 3D and gaming), Ruby and Python are popular in Web CRUD applications, etc. >Most recruiters these days consider C++ "legacy". C is essentially in the >same category as Cobol. Most recruiters don't know their ass from a hole in the ground. C/C++ is dominant in the embedded space and not much manages to displace it except for CPU specific assembly language and even there, most people only use assembly for small sections of the overall system. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://computergraphicsmuseum.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Jul 10 01:53PM -0400 On 7/10/19 12:46 PM, Richard wrote: > Lamely. :-) > Seriously, this looks like someone is using a macro to avoid the > syntax of the language. Just use the ordinary syntax. They're not using that macro to avoid the syntax of the language, they're using it to deal with the changing syntax of the language. Just using the "ordinary syntax" was not an option - these macros were intended to be useful even with compilers that didn't recognize that syntax. The relevant lines are: #ifdef _ANSI /* Keep everything for ANSI prototypes. */ #define _PROTOTYPE(function, params) function params ... #else /* Throw away the parameters for K&R prototypes. */ #define _PROTOTYPE(function, params) function() ... 
Subscribe to:
Post Comments (Atom)
|
No comments:
Post a Comment