C++ Exercises

This is a discussion on C++ Exercises within the C++ Programming forums, part of the General Programming Boards category; Do you know if there are any good exercises out there on the net? Everything i found so far is ...

  1. #1
    Programming Wraith GReaper's Avatar
    Join Date
    Apr 2009
    Location
    Greece
    Posts
    1,624

    C++ Exercises

    Do you know if there are any good exercises out there on the net? Everything i found so far is either too easy or too small!!! I try to challenge myself in learning more, and i think only practise, exercises, will aid me!
    Devoted my life to programming...

  2. #2
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,231
    This is something I've been working on for some students.

    Let me know if you want more information.

    Soma

    Our “Group 3735928495” programmers need a secure, clean, and consistent API to examine, modify, and produce “Awesome Virtual File System” formatted image files in order to merge support for our legacy tools into our exciting new productivity suite.

    Our new productivity suite utilizes our new and improved “AVFS Blue” file format, but we can't very well forgot our legacy customers! You will need to support our classic “AVFS” files for embedded system, our “AVFS” modern versions from the earliest publicly released variant “1.3” to last years “3.0”, and the now irresistible “Blue”.

    Your job, should you choose to accept it, is to provide a modern C++ API to process the “Awesome Virtual File System” file formats and produce a range of developer tools facilitating customer migration to our exciting new productivity suite.



    We expect the following general functionality:

    “Endian Agnostic” Target Source
    “Version Independent” File/Directory Access
    “Version Independent” File/Directory Name Searching
    “Version Independent” File/Directory Contents Searching
    “Version Reduction Tagging” (Invalid Version/STATUS Combinations)
    “Version Reduction Adapters” (NAME/STATUS/BLOCK Adapters)
    “Version Mirroring” (Version Combined Images)
    “Automatic Extended Field Updates”



    We expect the following additional functionality for “AVFS Embedded” (Version 0.9):

    “Endian Agnostic” File IO

    We expect the following additional functionality for “AVFS Classic” (Version 1.3):

    “STATUS” Set/Clear (Hidden/System/Archival)
    “Reserve” Set/Clear (Block Reserve)
    “Owner ID” Set/Clear (String)

    We expect the following additional functionality for “AVFS Modern” (Version 2.0):

    “File Optimizing” (Mirror File/Encode Once)
    “Group ID” Set/Clear (String)

    We expect the following additional functionality for “AVFS Ultimate” (Version 3.0):

    “File Patching” (Override Blocks)
    “Block Optimizing” (Mirror Blocks/Encode Once)

    We expect the following additional functionality for “AVFS Blue” (Version 4.0):

    “File Versioning” (Override Version Stack)
    “File Tagging” (Thumbnail/Terms/Version)
    “File MTSID” (String Field ID)



    We expect the following tools:

    “Endian Conversion” (“AVFS Embedded”)
    “File Optimizing” (“AVFS Modern”)
    “Block Optimizing” (“AVFS Ultimate”)
    “Set Owner” (“AVFS Classic”)
    “Set Group” (“AVFS Modern”)
    “Set Thumbnail” (“AVFS Blue”)
    “Set Terms” (“AVFS Blue”)
    “Set Version” (“AVFS Blue”)
    “Set Field” (“AVFS Blue”)
    “Remove Extended Fields” (“AVFS Blue”)
    “File/Directory Name Search Optimizing” (“AVFS Classic”)
    “Terms Search Optimizing” (“AVFS Blue”)
    Add “Term Search” File (“AVFS Blue”)
    Arbitrary Conversion Between “AVFS” Images (General)
    Produce Directory From Image (General)
    Produce Image From Directory (General)
    Format Image (General)
    Add File (General)
    Erase File (General)
    Add Directory (General)
    Erase Directory (General)

  3. #3
    Programming Wraith GReaper's Avatar
    Join Date
    Apr 2009
    Location
    Greece
    Posts
    1,624
    That is actually very interesting! Can you tell me more about it?
    Devoted my life to programming...

  4. #4
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,231
    *shrug*

    Yea.

    I've been sick for awhile now. I've not gotten nearly far along as I'd have liked.

    I haven't had time to polish the format descriptions. I've not even finalized the "Blue" format. I can give you the notes for "AVFS Embedded". It has everything you need to write the API and tools for that version.

    "AVFS Embedded" is a very simple file format. Despite the fact I called it "AVFS Embedded" in the project description, it isn't at all suited for that task. It is grossly underdeveloped and unsophisticated. It is designed solely for simplicity and high redundancy.

    I originally intended to require a reasonable "undeleter" for the "AVFS Embedded" images which should explain the redundancy. (A reasonable "undeleter" for the other versions would be far too complicated for an intermediate project.) Unfortunately the "beta test" revealed that the process of "deleting" as generally interpreted prevents simple "undeletion".

    I've intentionally left a little wiggle room in the file format descriptor for the header and potential "meta-information". I was going to "allow" the developers to use this potential to extend the "AVFS Embedded" images to support faster seeking and searching. This became too complicated. The openness means that I couldn't write code to test their work. I moved this idea to what is now "AVFS Classic" by splitting my intended "AVFS Modern" into "AVFS Classic" and "AVFS Modern". You should just ignore the "Reserved" bytes in the header.

    [Edit]
    I added a few examples and fully duplicated the markup for clarity.
    [/Edit]

    [Edit]
    I removed a few markers that would only serve as implementation hints.
    [/Edit]

    [Edit]
    I removed too many of my meandering notes. This list should "fix" the omission without providing too many hints.

    1) Only the root directory may contain subdirectories.
    2) Every entry in the root directory is treated as a directory.
    3) The directory '.' ("?.") is special as the files in this directory are treated as files in the root directory.
    [/Edit]

    Soma

    Code:
    General:
    
    Parity Bit [Highest Bit]
    32764 Block Maximum [15 Bit Offset] {32767 - EOFBlock - BootRecord - Header}
    String [7 Bit ASCII]
    Title [ALPHANUM String & '.' & '!' & '?' & NULL)
    BYTE [8 Bit: 7 Bit Values With Parity]
    WORD [16 Bit: 15 Bit Values With Parity]
    DWRD [32 Bit: 31 Bit Values With Parity]
    RAW! [8 Bit: 8 Bit Values Without Parity]
    EOFBlock (WORD) [Value: 0xFFFF] EOF Sentinel
    NULL (BYTE) [Value: 0] Unused Sentinel
    
    
    
    7.3 Modified Format (Case Agnostic):
    
    !$$$$$$@@@
    ! (BYTE) [Modifier] ALPHANUM String | '.' | '!' | '?' | NULL
    $ (BYTE) [Name] ALPHANUM String | '.' | '!'
    @ (BYTE) [Extension] ALPHANUM String | '.' | '!'
    
    7.3 Modified Format Examples (Using 0 as NULL):
    
    Name With Extension: "Happy!0BmP" -> "Happy!.BmP"
    Name With Extension And Leading Dot: ".Go0000PNG" -> ".Go.PNG"
    Name Without Extension: "?Directory" -> "Directory"
    Name Without Extension And Leading Dot: "?.Test0000" -> ".Test"
    
    
    
    Directory Entry Layout (16 Bytes):
    
    Directory Name [10 Bytes] (Title) 7.3 Modified Format
    Size [4 Bytes] (DWRD) Total Number Of File Record Entries
    Offset [2 Bytes] (WORD) First Block Of Directory Table
    
    Directory Table Layout (512 Bytes):
    
    Directory Name [10 Bytes] (Title) 7.3 Modified Format
    Size [4 Bytes] (DWRD) Total Number Of File Record Entries
    Offset [2 Bytes] (WORD) Next Block Of Directory Table
    File Record Array [496 Bytes | 31 Entries]
    
    File Record Layout (16 Bytes):
    
    File Name [10 Bytes] (Title) 7.3 Modified Format
    Size [4 Bytes] (DWRD) Total Size Of File In Bytes
    Offset [2 Bytes] (WORD) First Block Of Data Table
    
    Data Table Layout (512 Bytes):
    
    File Name [10 Bytes] (Title) 7.3 Modified Format
    Size [4 Bytes] (DWRD) Total Size Of File In Bytes
    Offset [2 Bytes] (WORD) Next Block Of Data Table
    File Data Array [496 Bytes (RAW!)]
    
    
    
    BootRecord [@0]:
    Unknown If Present
    
    
    
    Header [@0 | @512] (16 Bytes):
    
    Signature [4 Bytes] (String) LE=AVFS | BE=VASF
    Reserved [6 Bytes] UNKNOWN
    Size [4 Bytes] (DWRD) Total Number Of File Record Entries
    Offset [2 Bytes] (WORD) First Block Of Root Directory Table
    Last edited by phantomotap; 07-12-2010 at 03:52 PM. Reason: none of your business

  5. #5
    Programming Wraith GReaper's Avatar
    Join Date
    Apr 2009
    Location
    Greece
    Posts
    1,624
    Fairly complex and large project i'd say. I'll study the info a bit and see what i can do. Don't hesitate to send me more about it if you have.
    Devoted my life to programming...

  6. #6
    Programming Wraith GReaper's Avatar
    Join Date
    Apr 2009
    Location
    Greece
    Posts
    1,624
    I don't get two things:
    (1) Which are the file formats you're talking about?
    (2) The information in that code quote at your last post, what does it represent?

    Don't get me wrong, i just want to know what i don't understand, and learn it.

    I googled a little. Does AVFS have anything to do with this ?
    Devoted my life to programming...

  7. #7
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,231
    Fairly complex and large project i'd say.
    O_o

    No. It really isn't. It is fairly complex but rather small. My aim is project that would take a novice designer with an intermediate level C++ programming knowledge around 255 hours over four months.* I've been trying to tweak the requirements, format, and "landmarks" to accommodate that target.

    I'll study the info a bit and see what i can do.
    Enjoy, but realize that this is solely a tutorial project. It has nothing to do with any "real world" project.** Consider the group name: "3735928495" is "0xDeadBeaf".

    I'll spare the details, but you may consider me acting as a "private tutor" and this tutorial project a significant tool I'm using in that role.

    Don't hesitate to send me more about it if you have.
    I have everything. I'm designing it! I just haven't finalized a few details and polished my notes for public consumption.

    Which are the file formats you're talking about?
    There are five distinct file formats corresponding to the five major "AVFS" versions. You may consider these formats virtual file systems in the like of "ISO9660" images. (This the standard format of CD and many DVD discs.)

    Let '*' be a null byte marker.
    Let '$' be a null "octaword" (16 byte) marker.
    Let '[??]' be a "double word" "little endian" value where '?' is a digit.
    Let '!?' be a "word" "little endian" value where '?' is a digit.
    Let '!!' be a "word" "little endian" value of "0xFFFF".

    Let us assume we have a file system with one file in the root directory named "Test.txt" having the contents "Hello, World!".

    Take a moment to consider the following fake binary file:

    Code:
    (Image Header [Block: 0])
    AVFS******[01]!1 (Image Block Header)
    $$$$$$$$$$$$$$$$ (Unused/Reserved)
    $$$$$$$$$$$$$$$  (Unused/Reserved)
    
    (Directory Table {Root} [Block: 1])
    AVFS******[01]!! (Directory Block Header)
    ?.********[01]!2 (Directory Entry)
    $$$$$$$$$$$$$$$$ (Unused Directory Entry Area)
    $$$$$$$$$$$$$$   (Unused Directory Entry Area)
    
    (Directory Table {Special '.' Directory} [Block: 2])
    ?.********[01]!! (Directory Block Header)
    Test***txt[13]!3 (File Entry)
    $$$$$$$$$$$$$$$$ (Unused File Entry Area)
    $$$$$$$$$$$$$$   (Unused File Entry Area)
    
    (Data Table {Test.txt} [Block: 3])
    Test***txt[13]!! (File Entry Header)
    Hello, World!*** (File Data Storage Area)
    $$$$$$$$$$$$$$$$ (Unused File Data Storage Area)
    $$$$$$$$$$$$$$   (Unused File Data Storage Area)
    The information in that code quote at your last post, what does it represent?
    Except for the fact that I removed too many of my meandering notes, the post represents all you need to write a tool capable or reading, modifying, and producing "AVFS Embedded" files (images). The description hasn't been polished.

    The version I posted is modified form my original notes of the first version. I modified it, as I said, because the "bonus" tool set (the "undeleter" and seek optimizing) became complicated enough that I could do no standard testing from within my own code. (The modifications are trivial, but not required to fit a specific representation.)

    Does AVFS have anything to do with this?
    No. This tutorial project has nothing to do with that project. The shared acronym is purely coincidence.

    Soma

    * 255 = 17(Weeks) * 5(Days/Week) * 3(Hours/Day)

    ** Each file format introduces certain techniques commonly used in a wide variety or real world formats. These shared techniques are the only thing this tutorial project has in common with "real world" projects.

  8. #8
    Programming Wraith GReaper's Avatar
    Join Date
    Apr 2009
    Location
    Greece
    Posts
    1,624
    I have a few more questions:
    Why every Title has to be 10 bytes long?
    Why every block has to be 512 bytes in size?
    The way you describe for the file system's image, block indexing, i believe it is very hard to maintain. How can i apply change or delete techniques without loading the whole image on memory ( which would be next to impossible in the case of a large image file ) ?

    I think that's it for now...
    Devoted my life to programming...

  9. #9
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,231
    Every file format from the tutorial project introduces "real world" issues, techniques, and tools.



    Why every Title has to be 10 bytes long?
    In this case, I intend to introduce fixed formats common to some file systems.

    This is a modification to "FAT" and the classic "8.3" naming scheme.



    Why every block has to be 512 bytes in size?
    It is common for many file systems to operate on fixed sized "chunks" whether it be sectors, pages, extents, or something else entirely. The size of the "chunks" are generally chosen at the time of format and never again changed.

    Using 512 byte blocks as the smallest and largest operating unit simplifies this introductory material.



    The way you describe for the file system's image, block indexing, i believe it is very hard to maintain.
    ^_^

    You should see the variable sized extent pools I'm targeting for the "AVFS Blue" format.

    Direct indexing of fixed size blocks is the simplest form of addressing. The form of addressing and indirection you are used to operating on from C++ pointers and references do the same thing for memory as the file format does for image blocks.

    It isn't "hard to maintain", but some operations can be expensive. Consider the "trade offs" of arrays versus linked lists versus binary trees.



    How can i apply change or delete techniques without loading the whole image on memory ( which would be next to impossible in the case of a large image file ) ?
    O_o

    That would be something you are supposed to "discover" for yourself. I can't very well just tell you exactly what to do.

    What specifically are you having trouble with? Why do you think it would be necessary to load the entire file in memory?

    As with most anything, some level of caching improves performance, but you absolutely do not need to have the entire image in memory to create, modify, or delete files.

    Consider these questions as they may provide some insight into a potential implementation:

    What is the least number of bytes necessary to record only the meta-information necessary for "ready processing" of any one file in the largest valid "AVFS Embedded" image?

    What is the least number of bytes necessary to record only the meta-information necessary for "ready processing" of every file in the largest valid "AVFS Embedded" image?

    What is the least number of bytes necessary to record the complete meta-information of any one file in the largest valid "AVFS Embedded" image?

    What is the least number of bytes necessary to record the complete meta-information of every file in the largest valid "AVFS Embedded" image?

    For the purposes of these questions you may consider "ready processing" as having "just obtained" a pointer to a valid and fully constructed `std::fstream' object targeting a specific file in the "AVFS Embedded" image.

    Enjoy.

    Soma

  10. #10
    Programming Wraith GReaper's Avatar
    Join Date
    Apr 2009
    Location
    Greece
    Posts
    1,624
    So with all that, are you telling me to consider an image as RAM, where its size stays fixed and i "allocate" and "free" it? Because i've been thinking of a way to reduce its size when deleting, which is very difficult do to the fact that i should iterate all entries and change their indexing.
    I think i pretty much understand what you say, therefore my previous questions are answered, thanks!
    Devoted my life to programming...

  11. #11
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,231
    So with all that, are you telling me to consider an image as RAM, where its size stays fixed and i "allocate" and "free" it?
    No. I'm not telling you to consider the image as RAM. I'm telling you to consider the problem of operating on these files as being similar to the problem of operating on mutually linked structures.



    Because i've been thinking of a way to reduce its size when deleting, which is very difficult do to the fact that i should iterate all entries and change their indexing.
    O_o

    It seems very likely that you are missing some potential. I strongly advise you to discuss the approach you intend with me before you continue.

    That can't be done in public. (I don't like cheaters.) If you want counsel at this level for this issue send me a private message describing your "delete with space optimization" mechanism. I will not tell you what to do, but I may be able to guide you to some aspects of the image format you may have missed. If you do send me this message, please attempt to answer the four questions I asked in my last post. Your answers will help me gauge your understanding of the file format and the usefulness of those questions to others.

    That said, in the "real world", tools that operate on virtual file system images will almost always separate the duties of file removal and space optimization. Such tools will essentially perform two passes when performing in an "delete with space optimization" mode. There are some really good reasons for this approach.

    Soma

  12. #12
    Programming Wraith GReaper's Avatar
    Join Date
    Apr 2009
    Location
    Greece
    Posts
    1,624
    Sorry i sent it to you in two pieces, but it has 1000 character limit
    Devoted my life to programming...

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. C beginner exercises?
    By Sharke in forum C Programming
    Replies: 1
    Last Post: 02-20-2009, 11:00 PM
  2. Dietel C How to program exercises
    By droseman in forum C Programming
    Replies: 4
    Last Post: 10-02-2008, 09:55 AM
  3. seeking for exercises
    By smoking81 in forum Linux Programming
    Replies: 7
    Last Post: 09-14-2008, 06:46 PM
  4. C programe Exercises?
    By RahulDhanpat in forum C Programming
    Replies: 10
    Last Post: 02-29-2008, 12:26 PM
  5. Exercises
    By blankstare77 in forum C++ Programming
    Replies: 2
    Last Post: 08-31-2005, 05:46 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21