Thread: Is there a standard way to check if struct member is uninitialized?

  1. #31
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    If your library is going to be in a separate DLL file, make sure you don't throw an exception out of the DLL. Catch the exceptions in your public functions and convert them to standard error codes.
    "I am probably the laziest programmer on the planet, a fact with which anyone who has ever seen my code will agree." - esbo, 11/15/2008

    "the internet is a scary place to be thats why i dont use it much." - billet, 03/17/2010

  2. #32
    Registered User
    Join Date
    Aug 2010
    Location
    Poland
    Posts
    733
    Quote Originally Posted by cpjust View Post
    If your library is going to be in a separate DLL file, make sure you don't throw an exception out of the DLL. Catch the exceptions in your public functions and convert them to standard error codes.
    When creating any DLL, I'm trying to follow approach met in some libraries like DirectX:
    Functions (with some exceptions like some getters) return an error code. If I want to return any value, struct, or interface, I simply pass it as a pointer. Exceptions contain error codes and are caught in the exported functions. When an exception is caught, its error code is returned.

  3. #33
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Quote Originally Posted by Programmer_P View Post
    Would it be considered bad coding style to throw and catch the object's own exceptions inside the object's member functions anyway? That way, int main() does not have to catch any exceptions (or at least, not from my library)?
    You should not, unless it is something your library can handle.
    If you need something cleaned up, make sure that that which needs cleaning up resides inside a class whose destructor will clean it up.
    Exceptions should get propagated, so usually there is no need to catch them unless you need to handle them there and them.
    And your library should not terminate your program, in any circumstances. It should propagate the error and your programer, the caller, the user, should handle them and gracefully exit if something goes wrong.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  4. #34
    Programming Ninja In-T...
    Join Date
    May 2009
    Posts
    827
    Quote Originally Posted by cpjust View Post
    If your library is going to be in a separate DLL file, make sure you don't throw an exception out of the DLL. Catch the exceptions in your public functions and convert them to standard error codes.
    Quote Originally Posted by kmdv View Post
    When creating any DLL, I'm trying to follow approach met in some libraries like DirectX:
    Functions (with some exceptions like some getters) return an error code. If I want to return any value, struct, or interface, I simply pass it as a pointer. Exceptions contain error codes and are caught in the exported functions. When an exception is caught, its error code is returned.
    Isn't DLL a Windows library?
    I was planning to make mine a cross-platform, if possible.

    Also, my class functions all return const references, at this time, not pointers.
    Quote Originally Posted by Elysia View Post
    You should not, unless it is something your library can handle.
    Well, I would say it say it is.
    If you need something cleaned up, make sure that that which needs cleaning up resides inside a class whose destructor will clean it up.
    Exceptions should get propagated, so usually there is no need to catch them unless you need to handle them there and them.
    And your library should not terminate your program, in any circumstances. It should propagate the error and your programer, the caller, the user, should handle them and gracefully exit if something goes wrong.
    Yeah, I decided last night I'm not going to catch them inside my class functions. Instead, I'll just throw them, and leave them up to the user to catch. I also came to the conclusion that exiting from the program from my library was a really bad idea too.

    So I'm just going to throw all exceptions of C_html4_attributes to the user function to catch and deal with, the reason being that the user may want to retry calling one of the functions if he called it improperly the first time. So I can catch the exception(s) in the caller function, maybe inside of a loop, so that if an exception is thrown, I can just output its error, but keep going and keep retrying until the function is called correctly.

    I'll do the same thing with the related classes C_html4_tags and C_html4_elements.
    Last edited by Programmer_P; 02-27-2011 at 09:11 AM.
    I'm an alien from another world. Planet Earth is only my vacation home, and I'm not liking it.

  5. #35
    Registered User
    Join Date
    Aug 2010
    Location
    Poland
    Posts
    733
    It does not matter whether it is DLL or shared object. If it is compiled with a different compiler or just different compiler version it must be separated. It also applies to static libraries.

    You should not return references too. Return pointers and only to POD types.
    References can be implemented in different ways.

  6. #36
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Or just let the compiler compile the library. Throw in the source files / header files into the project and away you go.
    It's really the only way to create modern, safe C++ code. DLL and other stuff are old technologies and the C++ standard is too vague on a lot of things to make such things possible.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  7. #37
    Registered User
    Join Date
    Aug 2010
    Location
    Poland
    Posts
    733
    I can't imagine a modern operating system without a possibility to produce code portable across languages and environments.

    DLLs are simple and enable you to use your low level C code together with heavy and interpreted object-oriented scripts as well as with low level assembly procedural code. They were invited long time ago but they will also be present for a very long time. Knowing how to use C++ in a smart way can make writing external libraries much easier and much faster.

    Anyway, I wouldn't throw sources into the project, I would create a static library instead.

  8. #38
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    DLLs are suited for C & co, but not C++. That's the whole point.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Converting from C to C++
    By Taka in forum C++ Programming
    Replies: 5
    Last Post: 04-08-2009, 02:16 AM
  2. memory issue
    By t014y in forum C Programming
    Replies: 2
    Last Post: 02-21-2009, 12:37 AM
  3. Replies: 2
    Last Post: 04-19-2008, 12:06 AM
  4. Binary Search Trees Part III
    By Prelude in forum A Brief History of Cprogramming.com
    Replies: 16
    Last Post: 10-02-2004, 03:00 PM
  5. Request for comments
    By Prelude in forum A Brief History of Cprogramming.com
    Replies: 15
    Last Post: 01-02-2004, 10:33 AM