C++ Coding Style
-
- they_are_only_written_like_this_in_K&R_C InC++TheyAreWrittenMoreLikeThis. 2) Dont you hate typing too? 3) Why not give all your variables the same name too, it'll make it so easy to read. 4) C++ has nothing to do with MFC and the WIn32 api. After all, if you cant paint bitmaps on the screen and capture mouse coordinates to make your menus function then you arent much of a C++ coder either. (ever written a mouse, button and menu app in DOS?)
Truth is the subjection of reality to an individuals perception
fat_boy wrote:
(ever written a mouse, button and menu app in DOS?)
Oh yes. And it was fun to write but didn't leave much time for writing the rest of the app.
Michael CP Blog [^] Development Blog [^]
-
- they_are_only_written_like_this_in_K&R_C InC++TheyAreWrittenMoreLikeThis. 2) Dont you hate typing too? 3) Why not give all your variables the same name too, it'll make it so easy to read. 4) C++ has nothing to do with MFC and the WIn32 api. After all, if you cant paint bitmaps on the screen and capture mouse coordinates to make your menus function then you arent much of a C++ coder either. (ever written a mouse, button and menu app in DOS?)
Truth is the subjection of reality to an individuals perception
-
EscapeKey wrote:
Are you sure?
Absolutely. Why walk when you can take a car ? Why write assembler when you can write C++ ? Why use Win32 if you can get the job done in less than half the time with MFC ?
EscapeKey wrote:
but it depends on the technology your are using.
Sure - I said 'without good reason'. MFC should be the default, it's the easiest and best supported C++ approach. But sometimes Win32 is better. I wrote my own windowing framework, which interfaced to Python. I used Win32, why put another framework on top of Win32 when I was writing my own ? There are times when Win32 makes sense, but if you're going to make a general statement, the general truth is than MFC is a better choice.
EscapeKey wrote:
VB was designed for simple in mind
You TOTALLY rock.
EscapeKey wrote:
n contrast, I think the MFC is a relatively thin layer between the win32 api
It is incredibly thin at times. And you get the source code. That's what rocks, once you know MFC, it's easy to step in and see what it's wrapping and how, to learn Win32 after learning MFC ( which many people learn while learning C++ ). Along the way, MFC helps you learn how to do things in an OO way, which Win32 very much can't, as it's a C API.
EscapeKey wrote:
This layer is so thin that you will sooner or later have to use win32 api to solve or work-around a problem.
Absolutely. Again, that's why I advocate the approach I do. Win32 will rear it's head in lots of little ways that you won't even notice until you set out to learn Win32 and realise how often you were already using it.
EscapeKey wrote:
Therefore, I think understanding, or at least, knowing, the win32 api is still essential for working with MFC.
Well, that's not really what you said. If you had said this, I would have agreed, somewhat, in that learning MFC is a small step from learning Win32 at times, and you will learn parts of Win32 while using MFC, by default.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
Christian Graus wrote:
EscapeKey wrote: VB was designed for simple in mind You TOTALLY rock.
:laugh:
"He's got a lot on his mind, and it's not a load-bearing structure." - John Weak
-
I am learning C++ and I have several questions regarding the C++ coding style. 1.) Why most functions are named in lower case? 2.) Why the extensive use of shorts such as printf(),instead of PrintFormat()? 3.) Why do we need something like HWND, HINSTANCE, instead of a simple int? 4.) How could someone possiblily learn and use MFC without learning the win32 api? I see someone who considered themselve as experienced C++ programmer, and they can create a working MFC app, but they can't create a menu without a resource editor. I mean, creating menu is probably the first thing I learn in Windows programming. Is that normal? Thanks in advance.:)
Adding to what others have answered for "Why do we need something like HWND, HINSTANCE, instead of a simple int?": Because it may be a simple int on one platform, but it may very well be a long, a long long, an unsigned long or any of a dozen other data types on another platform. Just ask anyone who has ported code to 64bit.
cheers, Chris Maunder
CodeProject.com : C++ MVP
-
I am learning C++ and I have several questions regarding the C++ coding style. 1.) Why most functions are named in lower case? 2.) Why the extensive use of shorts such as printf(),instead of PrintFormat()? 3.) Why do we need something like HWND, HINSTANCE, instead of a simple int? 4.) How could someone possiblily learn and use MFC without learning the win32 api? I see someone who considered themselve as experienced C++ programmer, and they can create a working MFC app, but they can't create a menu without a resource editor. I mean, creating menu is probably the first thing I learn in Windows programming. Is that normal? Thanks in advance.:)
I am learning C++ and I have several questions regarding the C++ coding style. 1.) Why most functions are named in lower case? this is preference ... C and C++ came around way before we really developed formal coding standards. Also, no intellisense back then ... making everything lower case or all uppercase was easier to remember. Uppercase was used for constants. 2.) Why the extensive use of shorts such as printf(),instead of PrintFormat()? Sharthand is always easier ... less typing .. but also less storage. C and C++ were created during times where a mere 20 MB drive was very expensive. You noobs are used to seeing large storage drive capacity for very little $$$. 3.) Why do we need something like HWND, HINSTANCE, instead of a simple int? As members have already mentioned. You create a a type HWND to denote its function and use. Comments only go so far. Try declaring everything as int ... sooner or later, you'll realize you have extremely hard to trace memory leaks (at best). 4.) How could someone possiblily learn and use MFC without learning the win32 api? I see someone who considered themselve as experienced C++ programmer, and they can create a working MFC app, but they can't create a menu without a resource editor. I mean, creating menu is probably the first thing I learn in Windows programming. Is that normal? Win32 came around before MFC ... naturally everything you can do in MFC can be done in Win32. MFC is an extension of Win32 (not a 100% as noted by other members). MFC does simplify creating applications, much in the same way that printf accomplishes a task in 1 line where as in Assembly requires 8-20 lines. After writing a couple applications, you will greatly appreciate MFC over Win32 Api. Good luck!
-
I am learning C++ and I have several questions regarding the C++ coding style. 1.) Why most functions are named in lower case? 2.) Why the extensive use of shorts such as printf(),instead of PrintFormat()? 3.) Why do we need something like HWND, HINSTANCE, instead of a simple int? 4.) How could someone possiblily learn and use MFC without learning the win32 api? I see someone who considered themselve as experienced C++ programmer, and they can create a working MFC app, but they can't create a menu without a resource editor. I mean, creating menu is probably the first thing I learn in Windows programming. Is that normal? Thanks in advance.:)
1.) Why most functions are named in lower case? Basically, because the keywords in C are in lower case, and it made the standard function look like part of the language. 2.) Why the extensive use of shorts such as printf(),instead of PrintFormat()? I assume you mean "short names". Because when C was from designed, only the first 7 or 8 characters of a name were significant (limitation of the linkers of the day). Also because early C & Unix programmer were incredibly lazy typists. 3.) Why do we need something like HWND, HINSTANCE, instead of a simple int? In case you wanted to change the type of HWND but not HINSTANCE. You'd only have to change it once, in the typedef, instead of everywhere. Also it helps self-document the program. If a function returns a HWND you know it returns a "Handle to a Window". If it returns an int, you don't know what that means. Note that if you define STRICT in MFC (which you always should do), HWND & HINSTANCE *are* defined differently, and if you use one where the other is intended, you'll get an error. 4.) How could someone ..... Why would anyone in their right mind want to create a menu without the resource editor? I've have to do that maybe twice in my career. That's much like saying, how could anyone dress themselves without knowing how to operate a spinning wheel.
Truth, James
-
I am learning C++ and I have several questions regarding the C++ coding style. 1.) Why most functions are named in lower case? 2.) Why the extensive use of shorts such as printf(),instead of PrintFormat()? 3.) Why do we need something like HWND, HINSTANCE, instead of a simple int? 4.) How could someone possiblily learn and use MFC without learning the win32 api? I see someone who considered themselve as experienced C++ programmer, and they can create a working MFC app, but they can't create a menu without a resource editor. I mean, creating menu is probably the first thing I learn in Windows programming. Is that normal? Thanks in advance.:)
1.) Why most functions are named in lower case? Convention of the last 20 years (about). Functions are lower case, DEFINE macros are upper case. Changing case within words make typing slower. Nowadays, some of the programming editors can help You with auomatic completion, but not all. 2.) Why the extensive use of shorts such as printf(),instead of PrintFormat()? PrintFormat looks like a PASCAL or BASIC (I apologise for these rude words in a c++ forum) procedure to configure Your printer. printf is a standard C library function, maybe its older than some programmers. BTW, do You like typing? 3.) Why do we need something like HWND, HINSTANCE, instead of a simple int? Of course, You're right. But please tell this to Microsoft. Because Microsoft prefers their own "programming language", Visual Basic, so they would like to make programmers to hate C++. 4.) How could someone possiblily learn ... See the answer above. You can make your own decision. You can use Microsoft preferred technology, or You can use some open source/commercial libraries to make c++ programming easier. BTW, Microsoft technology to separate resource editing and coding, makes modifying and team working a bit easier. 4,5.) ... without win32 api? If You write a program to run on Windows, You always use win32 api, even if You don't know about it. Sometimes api is simpler or more efficient than using MFC, but only if You know it. I hope, my answers will help You in the way of becoming a C++ master.
-
I am learning C++ and I have several questions regarding the C++ coding style. 1.) Why most functions are named in lower case? 2.) Why the extensive use of shorts such as printf(),instead of PrintFormat()? 3.) Why do we need something like HWND, HINSTANCE, instead of a simple int? 4.) How could someone possiblily learn and use MFC without learning the win32 api? I see someone who considered themselve as experienced C++ programmer, and they can create a working MFC app, but they can't create a menu without a resource editor. I mean, creating menu is probably the first thing I learn in Windows programming. Is that normal? Thanks in advance.:)
-
I am learning C++ and I have several questions regarding the C++ coding style. 1.) Why most functions are named in lower case? 2.) Why the extensive use of shorts such as printf(),instead of PrintFormat()? 3.) Why do we need something like HWND, HINSTANCE, instead of a simple int? 4.) How could someone possiblily learn and use MFC without learning the win32 api? I see someone who considered themselve as experienced C++ programmer, and they can create a working MFC app, but they can't create a menu without a resource editor. I mean, creating menu is probably the first thing I learn in Windows programming. Is that normal? Thanks in advance.:)
C and C++ standards started before Microsoft and a lot of conventions where created UNIX system such as Solaris used strStringName as a standard to define type and name Microsoft used m_MemberName to define members of an object Some other used Camel notation, Hungarian notation (Microsoft mainly) and loads of other conventions. Why so many? Show 2 people the same object and they think different things, well whatever notation you use is less important than site consistency. Most software is developed by teams of analysts and programmer working together, over time the team sheet changes and to allow for change a site convention is used. Of course any new member will learn the site conventions quicker, if the site uses a generally accepted convention such as that employed by Microsoft or Sun. In team development consistency of approach is paramount otherwise it very quickly becomes a Wild West show. NOTATION In object orientated programming we often have objects containing other objects, so to tell if the programmer is using an object or a method of an object we use notation to clarify the situation (make the code more readable). Separation of Logic Best practice for coding suggests that the presentation, business logic layer and storage layer should be separate. What that should give is independent presentation so changes to a screen should not affect the business layer and changes to storage layer should not affect the business logic. Many programmers do not take the time to separate out their design, for small applications this is sometimes can be good approach with regard to time and maintenance, however in lager applications not clearly defining boundaries can be a disaster. Creating your own wrapper class around presentation, business and storage layers can improve maintance of code and scalability of an application. In small scale application this is rarely a problem, however good practice is always good practice no matter what programming language or methodogly is used. Basically make your system changeable and separate out the logical components of your system. No C++ application should be made as non portable. If you use wrapper around you presentation class then if MFC changes or you are asked to port the code to another platform, the task becomes easier and the same applies to business logic (process behavior) plus persistence logic (storage). Factory Patterns Or how to make a program unreadable! Factory pattern is a very useful pattern when used correctly, however overuse
-
>> Only a moron would use Win32 over MFC by default as far as I can see. Are you sure? I think using a high level framework is good in general, but it depends on the technology your are using. If you use VB, you expected it to be a high level language and the lack of understanding on the underlying logics are also expected. VB was designed for simple in mind. The VB runtime act as a very thick layer between VB code and the underlying win32 api. I think the VB runtime was designed to wrap the VB world into a sphere. In contrast, I think the MFC is a relatively thin layer between the win32 api. The MFC doesn't wrap and close the win32 api but instead, more like a thin layer of utilities and wrappers for win32 programmer to shorten their coding time. This layer is so thin that you will sooner or later have to use win32 api to solve or work-around a problem. Therefore, I think understanding, or at least, knowing, the win32 api is still essential for working with MFC. I am a beginner and please correct me if I am wrong.:)
I've moved through Assembler, C, C++ and now to C#; I've played in MFC along the way (and dabbled in Mac & Unix too :). Of the Win32 stuff - I know about messages, messages, messages. And some about handles. And that's it. I'd say that knowing the whole Win32 API is probably wasted effort; knowing parts of it, however, would be valuable. There are two topics I'd suggest getting clear about: 1. Learn about messages and the message pump - how messages get generated & how windows process them. Learn about the different types of messages that get passed to / from windows - when they happen & why. Learn about the order in which messages get generated, and the order in which parent/child relationships of windows get the opportunity to handle them. 2. Learn about resources and handles. Handles are the key to referring to windows, fonts, etc. - things that Windows manages for you. Learning about handles and about how they get created / destroyed will give you background knowledge that will support your understanding of MFC. Is (learning - from a book?) any of that _essential_ for working with MFC? Probably not. You'll have other programmers around you who can answer questions - or tell you exactly what to research. You could call this the 'learn it when you need it' approach; it also has the benefit of not using time on learning things you don't need. HTH Chris