Thread: not enjoying it

  1. #31
    Registered User
    Join Date
    Sep 2004
    Location
    California
    Posts
    3,268
    Quote Originally Posted by cyberfish View Post
    Which version of Windows run on something other than x86, x86-64, and Itanium?
    Well it looks like Windows CE is supported on x86, MIPS, ARM, and SuperH processors, but it does not support the full Windows API. Windows XP embedded edition supports the full Windows API, but it only runs on x86, and the P-200 microprocessor (from what I can tell at least).

    EDIT: It looks like the P-200 microprocessor uses the x86 architecture, so I was being a little redundant there.
    Last edited by bithub; 08-17-2009 at 07:21 PM.
    bit∙hub [bit-huhb] n. A source and destination for information.

  2. #32
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,195
    Quote Originally Posted by cyberfish View Post
    Which version of Windows run on something other than x86, x86-64, and Itanium?
    Don't forget Windows Mobile which runs on ARM and others
    Windows Embedded CE (different from CE) which runs on embedded systems.

  3. #33
    Registered User
    Join Date
    Dec 2006
    Location
    Canada
    Posts
    3,229
    hmm I thought Windows CE/Mobile don't use the same WinAPI as desktop WIndows'. Am I mistaken?

  4. #34
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,195
    Quote Originally Posted by cyberfish View Post
    hmm I thought Windows CE/Mobile don't use the same WinAPI as desktop WIndows'. Am I mistaken?
    It uses a subset of the full API. It generally doesn't implement things like Direct3D etc that would have no meaning in the context of embedded systems.

    Quote Originally Posted by MSDN edited for clarity
    Microsoft Windows CE 3.0
    API Considerations

    When you are porting an application from a Windows-based desktop computer to a Windows CE-based platform you need to consider the difference in APIs that are supported by each platform. Although Windows CE is based on the Win32 APIs, there are some important differences between the Windows CE API set and the Win32 API set:

    - Windows CE supports a subset of the Win32 API set. Some Win32 functions are not supported at all — and no 16-bit Windows functions are supported. You must replace the unsupported functions with alternative functions, if available, or create a work-around. For example, Windows CE does not support the MoveTo and LineTo drawing functions, but you can use the PolyLine function as an alternative.

    - Some of the APIs that are supported have a reduced feature set — fewer supported window styles, for example, and more limited support for colors and fonts. Some APIs have one or more parameters completely disabled. Others have parameters with a reduced range of options. For example, while both the CreateWindow and CreateWindowEx functions are supported, Windows CE only supports only a subset of the Win32 window styles.

    - The Windows CE API set contains a number of Windows CE–specific extensions. Many of these — including the touch screen and notification — support the hardware capabilities of the various devices

    - Some Win32 functions have been replaced by Windows CE equivalents. For example, tool and menu bars have been combined into a single Command Bar, which has a new API.

    - You might have to modify some of the supported data types. Windows CE supports all necessary Win32 structures, but a Windows CE-based platform might not use all members of a structure. Other structures might not accept the full range of options.

    - Some messages, for example many WM_* and EM_* messages, are not supported in Windows CE. Some supported messages have been modified for Windows CE, so that their might differ from the desktop counterpart. Windows CE also features some CE-specific messages, such as WM_HIBERNATE.

    - There are limitations on the use of exception handling. While there is support for Win32-structured exception handling, Windows CE does not support C++ exception
    Last edited by abachler; 08-17-2009 at 08:31 PM.

  5. #35
    Registered User
    Join Date
    Dec 2006
    Location
    Canada
    Posts
    3,229
    Ah I see. So it's like Java SE and Java ME.

  6. #36
    Registered User
    Join Date
    Jan 2007
    Posts
    330
    to get back to Win32 API and boost. You can use boost::shared_ptr with Win32API structures just fine and once you start using shared_ptr, which is a very handy class, boost::mem_fn and many more stuff becomes handy quickly

    Code:
    std::for_each(m_List.begin(),  m_List.end(),  boost::mem_fn(&CMyClass::Go));
    
    void CMyClass::Go()
    {
      CreateWindow();
      // call other windows API functions
    }
    So I dont see why you cant use boost anymore when you already use Win32API. They dont rule each other out

  7. #37
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,195
    Quote Originally Posted by KIBO View Post

    So I dont see why you cant use boost anymore when you already use Win32API. They dont rule each other out
    No, but WinAPI does sort of make Boost redundant, which falls back on my original position, that since you have to learn WinAPI anyway for windows development, Boost doesn't bring anything (much) to the table.

    personally I don't LIKE shared_ptr. I cut my teeth on 'dumb' pointers and don't have any issues with remembering to deallocate memory/objects. I understand that a lot of kids nowadays have problems grasping the concept of allocation/deallocation and need a crutch, I don't, that doesn't make my method 'old and in the way'.

    Aside from that, the major developers of the Boost library are also the people on the committee voting whether to add it to the standard. Am I the only one that sees just a really huge conflict of interest there? Hey boost is good, I get it, a lot of people like it, great. It doesn't need to be part of the standard because its not a bleeping language extension, its a bleeping library. If we are going to start adding arbitrarily useful code to the standard then hell lets add every open source project on the planet to the standard.

    Things that need to be added to the standard are things that will break portability if they are implemented more than one way. Implementing smart pointers 1000 different ways in 1000 different template libraries will not break portability, therefor its not IMO an appropriate candidate for inclusion in the standard. Neither is OpenMP, and I like OpenMP. It seems to me that the committee are scared that their pet project will eventually be superseded by some better template library and they want to cement their place in history by shoving it down everyones throat (even the willing ones).
    Last edited by abachler; 08-18-2009 at 09:08 AM.

  8. #38
    Registered User
    Join Date
    Jan 2007
    Posts
    330
    I share that opinion *if and only if* you have your own personal space to work in. When I created my own software systems with raw pointers and allocating/deallocating in the past I rarely (actually I cant remember even one) had memory leaks. But when I got moved to other projects and other people who didnt have the full mental image of my software had to restructure the code they introduced memory leaks easy. That wasnt their fault, its the fault of using raw pointers. So I would say in general its better to use something like shared_ptr to get more maintainable software.
    But I can see how one can get the opinion that raw pointers are easy enough to work with when you are the only one working on the software

  9. #39
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,195
    Quote Originally Posted by KIBO View Post
    But I can see how one can get the opinion that raw pointers are easy enough to work with when you are the only one working on the software
    So they were copying and pasting code without actually understanding what they were doing? I don't suppose you can provide an example because I'm having a hard time visualizing this random copy/paste mentality.

    The pointer is either global or its local.

    If its global it needs to be deallocated/deconstructed at the end of main() (pedantically). Windows and Linux both actually do this automagically when they terminate the process.
    If its local it needs to be deallocated at the end of the function.
    If its locally allocated as a global object then it needs to be explicitly deallocated when it is no longer useful and it must remain in scope until that point. if its accidentally taken out of scope then you end up with a GPF or the equivalent.

    So basically boost helps in the singular case where noobs fail to deallocated a local object or where your theoretical noob is copy/pasting partial functions without copying the deallocation part at the end, but then they must be explicitly leaving it out because they are obviously getting the part before deallocation and the return line, so they must be making a special effort to leave out the deallocation code.

    Again, I don't see the problem, other than a complete lack of understanding of allocation/deallocation, which is covered in first year IIRC. So how is it these people are landing professional programming positions or even getting a degree?

  10. #40
    Registered User
    Join Date
    Sep 2004
    Location
    California
    Posts
    3,268
    So basically boost helps in the singular case where noobs fail to deallocated a local object or where your theoretical noob is copy/pasting partial functions without copying the deallocation part at the end
    I must be a programming noob then, because I find it non-trivial to ensure applications with over a million lines of source code do not have memory leaks (when smart pointers are not used).

    Your point about pointers being either global or local works in very simple applications, but absolutely fails in complex applications where memory is shared amongst multiple modules and threads. When a single object is shared, who is responsible for deleting it? Well, the last class to use the object needs to delete it, but how do you know who the last class is? How do you easily write exception safe code without smart pointers? I'll let the non-noob programmers answer those questions, and I'll just continue to use smart pointers.
    bit∙hub [bit-huhb] n. A source and destination for information.

  11. #41
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,195
    Quote Originally Posted by bithub View Post
    I must be a programming noob then, because I find it non-trivial to ensure applications with over a million lines of source code do not have memory leaks (when smart pointers are not used).

    Your point about pointers being either global or local works in very simple applications, but absolutely fails in complex applications where memory is shared amongst multiple modules and threads. When a single object is shared, who is responsible for deleting it? Well, the last class to use the object needs to delete it, but how do you know who the last class is? How do you easily write exception safe code without smart pointers? I'll let the non-noob programmers answer those questions, and I'll just continue to use smart pointers.
    Those are engineering decisions that you need to make regardless of whether you use smart pointers or not. Properly written code will not generate exceptions because it will check before it tries to access null pointers, and it will not be using dangling pointers because 'smart' pointers decided that an object was out of scope and deleted it because a programmer didn't realize they no longer had a reference tot he object. So you end up with the same problems, except now you have no idea where the object is being deleted. Good luck tracking that one down in your bazillion lines of code. Ill stick with dumb pointers, where at least I can use a simple search to find all instances where something is being allocated/deallocated. ESPECIALLY helpful in gazillion line projects. You also wont have it re instantiating objects and using blank objects, causing data errors. At least if the object is out of scope it will crash and a debug run will show you exactly where it is trying to access an object that is no longer in scope, so you can fix the problem. Tracking down data errors is much more of a problem, especially when you get no crashes.

  12. #42
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,412
    Quote Originally Posted by abachler
    I cut my teeth on 'dumb' pointers and don't have any issues with remembering to deallocate memory/objects. I understand that a lot of kids nowadays have problems grasping the concept of allocation/deallocation and need a crutch, I don't
    I agree with KIBO. One can be careful to ensure that between the point of allocating and point of deallocation that no exceptions can be thrown without being caught, and control will not return before appropriate deallocation, but under maintenance of some function that you call, the situation may change, or the maintenance of that piece of code itself by a developer unfamiliar with it (or simply tired or careless) may result in a mistake that leads to a memory leak. These problems could be mitigated with code reviews (or even pair programming), but it is sensible to use RAII to better avoid them in the first place.

    Quote Originally Posted by abachler
    Aside from that, the major developers of the Boost library are also the people on the committee voting whether to add it to the standard. Am I the only one that sees just a really huge conflict of interest there?
    I am not sure how it is a conflict of interest: the people you speak of started Boost because they were looking to develop ideas for future extensions to the standard library.

    Quote Originally Posted by abachler
    It doesn't need to be part of the standard because its not a bleeping language extension, its a bleeping library. If we are going to start adding arbitrarily useful code to the standard then hell lets add every open source project on the planet to the standard.
    From what I understand the inclusion of new libraries into the standard library has as consideration how well it can fit into the existing standard library. Consequently, it is not just "arbitrarily useful code" that is added.

    Quote Originally Posted by abachler
    Things that need to be added to the standard are things that will break portability if they are implemented more than one way. Implementing smart pointers 1000 different ways in 1000 different template libraries will not break portability, therefor its not IMO an appropriate candidate for inclusion in the standard.
    I can see where you are coming from, but having added a (poorly designed) string library into the standard library, and having added the STL into the standard library, it seems that completing (if it is even possible) what the STL offers is the route that the standard is taking.

    EDIT:
    Quote Originally Posted by abachler
    Properly written code will not generate exceptions because it will check before it tries to access null pointers
    Sorry, but dereferencing a null pointer results in undefined behaviour, not an exception. The problem is when an exception thrown by some intervening function prevents deallocation from happening.
    Last edited by laserlight; 08-18-2009 at 10:12 AM.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  13. #43
    Registered User
    Join Date
    Sep 2004
    Location
    California
    Posts
    3,268
    Properly written code will not generate exceptions because it will check before it tries to access null pointers...
    What? Do you even know what an exception is? What does accessing a null pointer have to do with an exception? How can you say properly written code will not generate exceptions?

    it will not be using dangling pointers because 'smart' pointers decided that an object was out of scope and deleted it because a programmer didn't realize they no longer had a reference tot he object. So you end up with the same problems, except now you have no idea where the object is being deleted.
    I'm going to assume that statement comes from the fact you have little to no experience using smart pointers.

    where at least I can use a simple search to find all instances where something is being allocated/deallocated.
    So you are just going to search for "new" and "delete" in a large project to track down memory leaks? Just for amusement I did this in my current project to see what kind of numbers we are looking at:
    Instances where "new" is called: 5411 times
    Instances where "delete" is called: 1378 times.
    And this is a project that has slowly made the migration from "dumb" pointers to "smart" pointers over the last year. It used to be a lot worse than that.

    You also wont have it re instantiating objects and using blank objects, causing data errors.
    Again, another statement that comes from having no clue how a smart pointer works. What smart pointer "re instantiates" objects? How do you use a "blank object"?
    bit∙hub [bit-huhb] n. A source and destination for information.

  14. #44
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,195
    Quote Originally Posted by bithub View Post
    What? Do you even know what an exception is? What does accessing a null pointer have to do with an exception? How can you say properly written code will not generate exceptions?

    I'm going to assume that statement comes from the fact you have little to no experience using smart pointers.
    You misunderstand what an exception is. Here, since you should read these before making further comments about my level of knowledge.

    Intel® 64 and IA-32 Architectures Software Developer's Manuals
    http://www.intel.com/Assets/PDF/manual/318148.pdf
    http://www.intel.com/Assets/PDF/manual/252046.pdf
    http://www.intel.com/Assets/PDF/manual/253665.pdf
    http://www.intel.com/Assets/PDF/manual/253666.pdf
    http://www.intel.com/Assets/PDF/manual/253667.pdf
    http://www.intel.com/Assets/PDF/manual/253668.pdf
    http://www.intel.com/Assets/PDF/manual/253669.pdf

  15. #45
    Registered User
    Join Date
    Sep 2004
    Location
    California
    Posts
    3,268
    bit∙hub [bit-huhb] n. A source and destination for information.

Popular pages Recent additions subscribe to a feed